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.

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?

; 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    

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    

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.

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?

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.

And also, make sure the language supports HSLS, so we can produce pixel shaders in it.