I have decided what I shall do to combine the knowledge of all the assembly languages I know -- making an assembly-like language that is less specific than direct assembly and less generic than low-level C -- basically a notation language to carry out certain processes on different processors that compiles to 99% optimized assembly code on each platform!  Such as an example of Cor0x code:

LOAD[reg1(16),$80]
PUSH[regSP(16),reg1(16),INC [regSP(16),2]]
RETURN[POP,regPC(16),regSP(16),2]
Would be something like this in z80:

ld hl,$80
push hl
ret
And in something like 68K or SH3 the same thing, while trying to stick to the model as close as possible.

Of course, the idea would not to be coding something for x86 and z180 at the same time, but maybe something like SH3 and ARM or x86 and a3 at the same time.

I know what I posted is described poorly, but I hope you get what I am meaning

This will be a lot more work than making a normal compiler -- this will require a lot more attention at the tables and acceptable conversion methods -- and a really tough syntax to the coder.  However, it would be more than work it

If it is possible do you think that some of the instruction mnemonics could be shortened. And I would highly recommend doing this for the SH3 and the ARM. So I think what you are saying is this would be just like assembly language in the instruction simplicity and speed part. but all of the complex data handling normally found on a RISC style processor would be handled by the compiler. Just as example on the SH3 to load word or longword data into a register you need to use a displacement that points to a data table. But in this language the coder could give a literal value and the compiler would set up the table and the displacement.   

If it is possible do you think that some of the instruction mnemonics could be shortened. And I would highly recommend doing this for the SH3 and the ARM. So I think what you are saying is this would be just like assembly language in the instruction simplicity and speed part. but all of the complex data handling normally found on a RISC style processor would be handled by the compiler. Just as example on the SH3 to load word or longword data into a register you need to use a displacement that points to a data table. But in this language the coder could give a literal value and the compiler would set up the table and the displacement.   

Of course, I'll try to make the really unnessicary low level parts be don by the compiler like table making, however most parts are going to be done by hand coding -- this is basically a way to code in assembly for two entirely different but somewhat similar in data handling processors at the same time -- while maybe you won't be coding in and IDE for this, maybe you can make a HLL compile to this as an intermediary, and then use the Cor0x compiler to compile to all specified platforms. 

The thing is, this is really as close to assembly as you can get without doing specific-platform ASM -- and it shows in the complex syntax (which I can try to shorten).

One thing that will make this so cool is the creation of user-defined 'instructions' that take an unlimited amount of parameters and of any type, and can be used to create totally different code for each platform while still holding the same idea.  So, if you made a SIN[] instruction, for the x86 it would set up registers and perform the sine instruction built in, but for z80 it would insert code for manually calculating the sine output without a built in instruction.  And even cooler, with two separate ways to compile instructions, you can technically program for a windows 7 computer, a calculator, and a commodore 64 at the same time.  However, good luck making something rather large

Also, another thing: the variable system is a LOT different in this -- these are the types of bars: Int(bytesize), Short(bytesize), Word(bytesize), byte(size), bit, trit, quit, nibble(bytesize), port(address size), register(size), constant(length, base), char(range, base), string(range, base, type), address(size)

register and port sound weird to be called variables, but maybe for cross-compilation between z80 and x86, you want an IN[] instruction to have the input go to A from port $02 on z80, but to EAX from port $607C on x86.  That way, Reg1 equals something constant for each platform, and same with port (port has more to do with actual hardware surrounding the processor, but that is taken care of with 'specific machine compilation', which you can define ports with different values between processors AND devices )

And, with that, I realize this must be a massive wall of text for you to read. 

I am don't know much about assembly but I do see that something like this would definitely be a little easier to use if you made it OOP Language.
I don't know if this is possible but that is my main idea on the project

Python like syntax(no semicolons/braces just tabs and spaces(wow that rhymes)) would make this pretty easy to code and a very interesting project. I wonder is it even possible?

I don't think I can make the syntax easy as I have to have a lot of information crammed into each line like LLVM IR, its not gonna be an easy thing to code in.

However, I will include Lo-OO, so it will be OOP -- but the way you'll code in it is much more different and much harder than you think.

It's a form of Assembly, I actually expected it to be hard.

Good idea: though the OOP design of Lo-OO isn't really the same found in C++ or Java -- it's more of a way to access them rather than all the crap found at higher levels just think of it more as Lua tables than real objects -- because to tell the truth, Lo-OO is kind of the bridge between High level OOP and assembly.  It's more of a way to organize the objects and such rather than doing complex crap with them.  I totally get your concern though, and I'll make sure I don't go too high level

Also, I do plan to have a basic RISC design that works on all processors, but many people want to do stuff like access complex x86 instructions that are far from the RISC design -- so I'll have the RISC stuff work fine for everything, but some processors will have live saving instructions to include as well.  However, instructions in Cor0x can be low level machine opcodes of any length -- therefore a sine instruction on x86 can be a more complex sine subroutine on z80 -- the point is to be as supportive of everything as possible, unlike LLVM which would not be suitable for writing the same code in 2 processors.

Plus, LLVM handles OOP horribly IMHO, so there's a lot of fixable points to be Made