flat assembler
Message board for the users of flat assembler.

Index > Main > Portable Assembler?

Goto page Previous  1, 2
Author
Thread Post new topic Reply to topic
Scott Bell



Joined: 17 Aug 2006
Posts: 1
Scott Bell
What about Forth or MSIL?
Post 14 Sep 2006, 10:17
View user's profile Send private message Reply with quote
DrenThales



Joined: 05 Sep 2006
Posts: 11
DrenThales
kohlrak posted:
Quote:

You, shaolin007, are thinking of a standardization... Which can only be implimented 2 ways... Building processors with all the same instructions (will never happen to begin with, plus it won't do any good for the old processors) or "another level of indirection" which is done by programming for an OS or an extention to another program (which would run on all OSes of all processors) which will be much slower (reminds me of java). Essentually, it's not gonna happen.


"standardization" is often nothing more than a frequently used buzz-word for people who are being too lazy to actually think about anything: hardware interface on a per system basis is, generally, the only real instance of "standardization" that should really be used. This is becasue once you have access to all functional capabilities of a given system of hardware, any and all possible external software interfaces that system may provide to or from other systems are potentially constructable via that hardware.

Some systems may or may not be able to interface with each other, but that's a matter of hardware, ultimately. Software is merely data interpreted by a given hardware system, thus, if you can provide a mechanism for converting from one system's data to another's (to whatever degree applicable), then you have a valid method for converting between various systems.

I think your idea is great, shaolin007. Very Happy
And I think that computer technology would be better served if more people would learn to look fowards, rather than always backwards.
Post 14 Sep 2006, 14:25
View user's profile Send private message Reply with quote
Rookie



Joined: 21 Aug 2003
Posts: 44
Location: Planet Romania
Rookie
Pardon the intrusion, but I have one question: wouldn't this sort of project eventually turn into Bochs, if we reffer to x86, or MAME or any other such platform emulator? Sticking to x86 assembly as an example, to make all the memory an interrupt instructions work, you'd sooner or later end up writing a HAL, in my point of view, so you're basically starting to cook up plans for your very own emulator/virtual machine. Good luck with that! (No pun intended, really... Good luck! if you're gonna take on such a project)
Post 14 Sep 2006, 14:46
View user's profile Send private message Reply with quote
DrenThales



Joined: 05 Sep 2006
Posts: 11
DrenThales
shaolin007 wrote:
I originally posted this at programmersheaven but thought that I would get better feedback here.

I just had a thought on how to make one instruction set more portable to other architectures. Computers are the same, right? This is a fundemental fact. One might be more powerful than the other but, given enough time, they can do the same things. Using emulation techniques, we could convert or translate x86 code to another ISA. You could program in the instruction set that you are familiar with and the assembler would convert the instructions to another ISA. When writing a emulators CPU core for a system, you convert the opcodes of that system into similiar opcodes of the target system. The assembler could have support for different cores and different ISAs you could program in. Of course, you would run into situations where one system had unique instructions and problems writing a translator for that but for the most part you could port over simple instructions like add, sub, mul, div, mov, or, and, nor, not, xor, ect. which most systems have. The initial code generated might not be the fastest and most compact around but it would prove a point. This would throw the whole adage of assembler not being portable out the window. Think of it like the universal translator on Star Trek but in a written form. What do you think?


A number of you are responding with reply posts that evince a missinterpretation of what the thread author is actually talking about.

This thread, from the best that I can discern (ie: I'm not the author, so I can't actually be certain as to intention) is not about makeing an run-time-type "emulator" environment. The author of this thread said emulation techniques, NOT emulation itself.

To clarify: when the thread author said "emulation techniques", what that meant was that the program which would provide the conversion mechanism would systematically understand code of a certain ISA, not run it.

The program would serve to translate machine code from one computer ISA to another, nothing more. It seems prudent, now, to remind you what machine code actually is: numerical data, stored on memory devices, which correasponds to (codes for) certain instructions available via that ISA (system).

For example: the machine code for, say, outputing pixel data, on system A is "03h 70h", followed by specifications, whereas, on a similar system, system B, it might be "01h 34h". Such codes would be related in the sense that, analogically speak, they serve the same purpose.

The program would simply covert machine code of one system to machine code of another's. In the context of the above example, if, say, a user of the program specified to convert machine code from system A to system B, then (in that case) it would merely have to substitute every instance of "03h 70h" with "01h 34h".

Of course, as the thread author even stated in the original post, some convertions would not be possible (most likely because of nonexistant concepts amoung certain systems; ie a hardware system with no monitor interface whatsoever obviously cannot accept a conversion pertaining to monitors from another system into its own system, the translation simply wouldn't exist).

For some info on what "ISA" means, you can look at http://en.wikipedia.org/wiki/Instruction_set
Post 15 Sep 2006, 02:22
View user's profile Send private message Reply with quote
Goplat



Joined: 15 Sep 2006
Posts: 181
Goplat
I don't see how this would be useful. Why do people use assembly? Mostly because they want to do
1)make code as fast as possible
2)make code as small as possible
3)access hardware (eg. in OSes, drivers, and DOS programs)
4)learn more about how the CPU works

A portable assembler couldn't do any of these. It would just be like a harder to use version of C.
Post 15 Sep 2006, 17:30
View user's profile Send private message Reply with quote
DrenThales



Joined: 05 Sep 2006
Posts: 11
DrenThales
I suppose so. (C / C++ is an excellent programming language, I agree)

Also, seeing as x86-64 is basically a transitional processor architecture, ie because we'll progress away from it eventually, it seems decently acceptable, in hindsight, to continue to relie on C / C++, for the time being...

However, bear in mind that I only say that out of assumption / hope that CPU manufacturers will eventually find an acceptable way to change to either RISC-based processors (because, for example, RISC does not have implicit register use), or some at least equally effective processor design.

Implicit register use has always been an abomination in my view: because on CISC, in some cases, because certain instructions only allow use of certain registers or only store results in certain registers, CPU register capacity will, in effect, be reduced to a mere fraction of the number of available registers, in those cases. Suppose, for example, that a program performs a large number of exactly the same instructions over and over. Suppose those insturctions force the implicit use of only 2 of the 16 registers. Suppose a program will execute that instruction, say, over 2 million times in a row (an instruction similar to data reading, perhaps). This means that for the next 2 million instructions, the CPU will perform as though it only has 2 registers, in effect.

In whatever case, once the archtecture itself is improved, it will eventually be worth the effort involved in re-esablishing a software base (thus I suppose that a clean assembly base effort might be better merited for then rather than now).

(and yes, I know I "went off on a little bit of a tangent"... but it's related to the matter, so it was merited to do so)
(also, as a note: "RISC" meaning "reduced instruction set computer", "CISC" meaning "complex instruction set computer")
Post 17 Sep 2006, 19:27
View user's profile Send private message Reply with quote
TheRaven



Joined: 22 Apr 2008
Posts: 89
Location: U.S.A.
TheRaven
Two considerations for cross platform anything:the CPU and native calling convention to the O.S. kernel. Every platform has a basic processor minimally and if an O.S. there will be a kernel. Opcodes and calling conventions can and usually are stored in something like a look up table by reference in the same manner as database management systems.

Thomasz Grys Phantasy Star 4 has already proven that assembler is portable in accordance with the philosophical rantings of the old skewl PhD.

Have we forgotten that FAsm ports are object files that we compile against the native C/C++ compiler chain essentially wrapping FAsm in the native API.

The API macro libraries for FAsm in Windows indicates precursory behavior in that FAsm will inevitably utilize the same strategy and technologies for all platforms it supports. Additionally, these methodologies FAsm employs will allow it to be ported more easily to any processor and operation system requiring nothing more than include libraries and a basic native compiler.

Phantastic stuff!
While this thread is a bit dated, the subject is more enticing than ever.

Externalize instruction sets to library objects and according to compile time/pre-processing flags compile FAsm for RISC, CISC or both for comprehensive cross-assembling. Everything software API will continue to be managed via FAsm include Macro support libraries -- done and done.

I like the way Thomasz thinks.
Post 15 Jan 2015, 10:38
View user's profile Send private message Reply with quote
TheRaven



Joined: 22 Apr 2008
Posts: 89
Location: U.S.A.
TheRaven
The closer to the hardware your system descends the more likely you will minimally design an abstraction layer. Creating a unique HAL really boils down to developing a specialized driver -- nothing new there at all. Not all HALs are created equal and therefore not all are as complicated as one might assume.

Open the bay doors HAL...

On another note, standardizations are policy models based on proven methodologies for common operations, but I digress. Standards are most certainly for lazy people; let's consider the morons at ISO, ECMA, POSIX and all that IEEE crap, not to mention those idiots at the W3C and ANSI. Those a** holes ain't ever done nothin'.

Who the hell needs to burn a CD/DVD or use that stupid world wide web anyhow...

Sorry, had to get it out of my system.

_________________
Nothing so sought and avoided more than the truth.
I'm not insane, I know the voices in my head aren't real!
Post 15 Jan 2015, 10:53
View user's profile Send private message Reply with quote
m3ntal



Joined: 08 Dec 2013
Posts: 296
m3ntal
Portable assembler? Working on it.

What's up, Raven? Smile Cool

(I'm not exactly a "nerd", either. (From streets, shelters. Self-tattoos everywhere, chest, hands, fingers.) Gotta get to work.
Post 21 Jan 2015, 10:29
View user's profile Send private message Reply with quote
Eduardo



Joined: 18 Jan 2015
Posts: 23
Eduardo
Do you want a portable assembly language? Very Happy What do you think about mine? Mine its based on BFASM (yes, i love esolangs). Look:
Code:
; ok, this is a comment
; directives:
code intel_x86  ;we are compiling code to x86 intel
stk 7  ; max stack depth
regs 4  ; number of general registers, redefine a option initially provided by code directive
org 0  ; like our FASM's org directive
org 0h
org 0b  ; FASM-like numbers

db 'this is a string, of course', 0ah, 0

lbl my_label
psh 3  ;push a byte on stack
pop r1  ;r1 is a general register
pick r1, [3]  ; pick the 3rd level from stack, put it in r1
sto [r1], 4  ;moving immediate to register-addressed memory
rcl r1, [r2]  ; contrary of sto
eq r1, r1, 3  ; value of r1 equal to 3? if so, r1 now = 1, else = 0
gt r1, r1, 27  ; greater than?
ge r2, r3, r4  ; greater or equal?
lt r4, r3, r2  ; less than?
le r4, r3, r2  ; less or equal?
jz my_label, r1  ; if r1 = 0, jump to my_label
jnz my_label, r3  ; auto-explicative
jmp my_label
call my_label
ret
;other instructions at your taste    

To define instructions, we can use a FASM-macro-like system:
Code:
instr out char
intel_x86_code
   push char
   call putchar
pseudo_code
   psh char
   sys putchar  ;we can define this instruction after
arm_v7_code
   ; whatever
end_instr    

Criticism? Idea
Post 24 Jun 2015, 20:26
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17287
Location: In your JS exploiting you and your system
revolution
For ARM code something like "sto [r1], 4" requires the use of a temporary register to hold the value "4" before storing it. Is the temporary register that is used fixed, or can it be (re)defined somewhere in the code?

Also how are the sizes of the memory accesses and registers defined?
Post 25 Jun 2015, 01:52
View user's profile Send private message Visit poster's website Reply with quote
PeExecutable



Joined: 26 Jun 2015
Posts: 181
PeExecutable
C is an assembler already that does that for you. Once you realize that, in practice, C is just a very sophisticated macro assembler and an assembler is just a slightly less sophisticated macro assembler.

When you're looking at a piece of code in C, you can tell to a great degree of accuracy what comes out of it once you've decided what architecture it's compiling for. There is no hocus pocus, once you look at your source, you know (in 80% of the cases) more or less whats coming out of it.

People have to understand that C is just a very sophisticated macro assembler. There is no C boogey man hiding inside there, it's a macro assembler. Do you get it? When you write code for it and you peek at the final output, it's as small, sometimes even smaller than fasm output, and extremely well optimized.

And even better, here is the thing that absolutely blows your mind away, no matter what you do, your C code will survive the future, no matter what the future is, it's eternal and can be re-used. When you're designing and practice your artistic code skills, it's eternalized and you actually produce something which has value.

My wishes for the future is that we get something new, which isn't as bony as an assembler and not as fat as C, a modular language which is based on precompiled modules made in assembly, perhaps with the use of pseudo instructions as examplified above.

Basically a language as easy as Basic, with the speed between C++ and asm and the size of assembly but it must be portable. If anyone can create such a language, they would be ingenious.

And also, make sure the language supports HSLS, so we can produce pixel shaders in it. That would be absolutely mind blowing. If you can create a language like that, it doesn't have to exactly like that, I will definitely use it and use it permanently. If anyone is into that, make sure you create a very nice windows help file for the language. The main thing to keep in mind, is that, we focus on creating something that really survives the future, and perhaps captures the mind of other people. But it must support HSLS pixel shader assembly language so we can code pixel shaders for our DirectX apps.

A side note: I strongly believe in languages that ships with a skinny but solid base foundation. IT must ship with some form of defaults for everyone to use, and it must be fast too.
Post 27 Jun 2015, 04:35
View user's profile Send private message Reply with quote
fasmnewbie



Joined: 01 Mar 2011
Posts: 553
fasmnewbie
PeExecutable wrote:
C is an assembler already that does that for you. Once you realize that, in practice, C is just a very sophisticated macro assembler and an assembler is just a slightly less sophisticated macro assembler.

When you're looking at a piece of code in C, you can tell to a great degree of accuracy what comes out of it once you've decided what architecture it's compiling for. There is no hocus pocus, once you look at your source, you know (in 80% of the cases) more or less whats coming out of it.

People have to understand that C is just a very sophisticated macro assembler. There is no C boogey man hiding inside there, it's a macro assembler. Do you get it? When you write code for it and you peek at the final output, it's as small, sometimes even smaller than fasm output, and extremely well optimized.

And even better, here is the thing that absolutely blows your mind away, no matter what you do, your C code will survive the future, no matter what the future is, it's eternal and can be re-used. When you're designing and practice your artistic code skills, it's eternalized and you actually produce something which has value.

My wishes for the future is that we get something new, which isn't as bony as an assembler and not as fat as C, a modular language which is based on precompiled modules made in assembly, perhaps with the use of pseudo instructions as examplified above.

Basically a language as easy as Basic, with the speed between C++ and asm and the size of assembly but it must be portable. If anyone can create such a language, they would be ingenious.

And also, make sure the language supports HSLS, so we can produce pixel shaders in it. That would be absolutely mind blowing. If you can create a language like that, it doesn't have to exactly like that, I will definitely use it and use it permanently. If anyone is into that, make sure you create a very nice windows help file for the language. The main thing to keep in mind, is that, we focus on creating something that really survives the future, and perhaps captures the mind of other people. But it must support HSLS pixel shader assembly language so we can code pixel shaders for our DirectX apps.


Most people here are C programmers. Are you trying to teach expert C programmers about C and pixel shaders?

Quote:
A side note: I strongly believe in languages that ships with a skinny but solid base foundation. IT must ship with some form of defaults for everyone to use, and it must be fast too.


NASM can't take direct floating-point immediates. You need to use some form of macro to do that. And still without that default feature, NASM is heavy, slow and bloated.
Post 28 Jun 2015, 06:31
View user's profile Send private message Visit poster's website Reply with quote
Eduardo



Joined: 18 Jan 2015
Posts: 23
Eduardo
Quote:
Is the
temporary register that is used fixed,
or can it be (re)defined somewhere in the code? Also how are the sizes of the
memory accesses and registers
defined?

My opinion is that the tool must give a initially workable environment, with reasonable pre configurations, and if the programmer wants to mess it, its up with him. So yes, we could redefine it somewhere. About the sizes, same: a standard value is implicit used, and you can modify it with directives.
Post 29 Jun 2015, 04:37
View user's profile Send private message Reply with quote
Eduardo



Joined: 18 Jan 2015
Posts: 23
Eduardo
Quote:
When you're looking at a piece of
code in C, you can tell to a great
degree of accuracy what comes out
of it once you've decided what
architecture it's compiling for. There
is no hocus pocus, once you look at your source, you know (in 80% of
the cases) more or less whats coming
out of it.

Sorry sir, are you really talking about the C language? I will show what i think about C: i n t * ( * ( * a r r [ 5 ] ) ( ) ) ( ) ; v o i d * ( * a [ 5 ] ) ( c h a r * c o n s t , c h a r * c o n s t ) ; v o i d * * ( * d ) ( i n t & , c h a r * * ( * ) ( c h a r * , c h a r * * ) ) ;
Post 29 Jun 2015, 04:58
View user's profile Send private message Reply with quote
gens



Joined: 18 Feb 2013
Posts: 161
gens
PeExecutable wrote:
And also, make sure the language supports HSLS, so we can produce pixel shaders in it.

opencl is like C for parallel computing devices

you can mix opencl and opengl, kind of (never tried it myself)
do look at vulkan and spir-v for how to do these things properly
vulkan isn't out yet but you can look at amd's mantle since it is mostly based on it

and no, its not always good to mix gpu and cpu
gpu is good at computing lots of same things at once, and has a latency attached at sending/receiving data
what it is useful for it is already used for
the general idea of "just trow it at the gpu" really annoys me
Post 29 Jun 2015, 16:48
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on YouTube, Twitter.

Website powered by rwasa.