I was trying to think of a fix for the huge bad thing with assembly...portability
I bet that this is out of the scope of FASM, but anyway...plus this is the only assembly baord I know of

Now, I know advanced things can't be done portably, like OS production(or at least not the LGDT and such things) but if you use a small, simple instruction set, then portable assembly is possible

also, along with being portable, this could actually make programmign in ASM much easier...or at least for newbs..

like I said, just a simple instruction set, with generic register names and such..

now I don't know anything but intel assembly, so I can't give very good translations..but anyway

for example something like

mov [my_var],[my_other_var] should be impossible to do on intel syntax, but because to keep it portable, we have to use multiple instructions..
If it were done to do only one opcode per instruction, it would be like

mov r0,[my_other_var]
mov [my_var],r0

and this would create a one-to-one translation ratio
it would output something like this:

mov eax,[my_other_var]
mov [my_var],eax ;;oops forgot to specify size above..oh well

another thing is that it will probably have something like a 64 register limit..
like r40 would actually be memory on IA32, but on something like (i think) italium, it would actually be a register

to keep it portable for number of bits, you could do something like



In IA32, this could translate to something like,


now of course, this seems very ridiculous, but it does allow you to think your programming a 64bit CPU...


now, the big one, of course is edian-ness(what order the bytes go in)
for that you could have something like


and would translate in IA32 to


also, for a bit of optimization, you could specify certain register numbers as certain things on specific archs(if not on that arch, then does nothing)



There could also be a command like, "NO TEMP REGISTER" or something, and what that will do is everytime a temp register is needed, it will either use the stack, or push a register, use the register for temp, and then pop it back...

that's really all my ideas for right now..
any problems you see, or comments?


edit:

even more..
for 16bit segment stuff...
it would assume that DS is loaded with the start address of the program..
like this

with this, you just specify somewhere in the address space, no segment worrying..
you could even do "mov [0xF0000],1" and that would translate also...
the big code would translate to something like


however, you could always do segments also..



one more bit, could be something like
[code]
#if x86_family
FORCE 8086 //forces it to use only u8086 opcodes, if we are compiling for the x86 family
#endif
[code]

1. you wouldn't be able to make it really portable and still remaining 1:1

2. nobody would use it

sorry...

#2 is inherit with every new idea..
1. It's not intended to be 1:1, it's like a high level assembly kindof

What if you do something like chip8, With a sub set of x86.
I am code one for DexOS.
some links
http://en.wikipedia.org/wiki/CHIP-8
http://members.aol.com/autismuk/chip8/chip8def.htm
http://www.pong-story.com/chip8/
http://newsdee.com/flip8/

The chip8 as never been a real chip, but it runs on nearly all processor, i was thinking of design our own.

Impossible to do directly on Assembler, because it is architecture specific. It will pretty much evolve on a high level language like C whose code may be compiled and run on different architectures, for as long as the code uses functions supported by all the architecture specific libraries.

It reminds me my idea of "Portable Flat Syntax" - a syntax that allows your asm code to compile to both x86-32 and x86-64. I was seriously thinking about it, but never realized it. It would be doable under some limitations. It would be done using macros - I didn't want to make whole new assembler. (I'm masmer, but FASM macro language should be strong enough to realize it as well).

x86 and x86-64 aren't THAT different, that is why it is somewhat possible. But try doing so with ASM and x86/x86-64...

thinking about it...I could maybe do this through the FASM macro stuff...if fasm macro's can override actual opcodes, then wouldn't you be able to do something like that?

first of all, it's a stupid idea

[ Post removed by author. ]

Why did you say endianness was a big problem? We have BSWAP on Intel/AMD arch. And actually QWORD on 32-bit means EDX:EAX as defined by (I)DIV/(I)MUL...

It is not a question of stupidity, rather a question of hckr83's free time. Don't hesitate to try it, you'll probably never finish it, but you'll learn a lot.

oh..didn't really think of those... not as big of a problem then,,,

It's silly - portable assembly is called C

For a "portable assembly", you're going to limit yourself to a pretty small subset of instructions, you won't be able to code "naturally" for a CPU (dst,op1,op2 vs dst/op1, op2), et cetera. You'll lose the advantages assembly has, without really gaining anything.

Stupid or not, we'll see if it will be more portable than ASM and faster than C. Something in the middle

We even tried to make SQL in ASM as far as I remember...so...

one good thing is that all of you ASM only programmers will be able to be able to step in and almost instantly know how to write most code..

There's a good chance that it'd actually be slower than C, since you're limiting yourself to a lowest common denominator instruction set, and code without specific knowledge of your platform.

It's a funny idea, but pretty worthless for real stuff.

Isnt is what C actually does ^o) - common denominator between instruction sets. If you say i++, it makes the variable bigger +1 on any touring-complete architecture. No matter what, it finds the way - even if instruction set only has XOR/AND instructions . What C does more, is that it makes additional passes to optimize many instructions into one, assembly doesn't do that.

The thing with C is that it has a slightly higher abstraction level than assembly, and a compiler is free to choose the machine instructions it wants. While this isn't always as optimal as hand-coded machine-specific assembly, there's a good chance that the architecture knowledge built into a compiler will be better than a lowest-common-denominator "architecture".

The "portable assembly" thing won't know of things like LEA tricks instead of multiplication, won't know if "inc x" is faster than "add x, 1" et cetera... and if you start building such knowledge into the project, you just end up with a less capable and less portable C.

i second that