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:


Code:


Would be something like this in z80:


Code:


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

/me looks at LLVM and notes that LLVM IR already does that.
Go go LLVM backend for x architecture?

Not to be a critic, but isn't that basically a restricted form of C?

Qwerty: not really at all. C is a more high-level language, whilst it can be used for low level purposes. This is MUCH more specific about the instructions, instead of an If/Else/End block, you can specify for a block with conditional jumps and bitwise comparations . Basically, Cross Platform Assembly in a way.

Tari: it seems that whatever LLVM is, it does do most of what I want to do. But then again, if C++ did everything we wanted, then why does Java, Python, Lua, and C# exist? Just because one language seems to do what I am aiming for already, doesn't mean I can't try to make mine better or add extra features

LLVM is a compiler for C, just like GCC is a compiler for C? And regarding the last sentence of your post, Ashbad, That's true! One option would be to make a C/C++ language extension, though, rather than creating a new language. It's up to you.

Maybe it could be a language extension -- I doubt anyone would hand code in this, it's a pain to do so manually, much more than specific-device code. So most likely C would compile to this (with my own optimizing techniques in place with the compiler), then the Cor0x compiler could compile to specific machine code from there

Ashbad, that is exactly what Llvm does, and it does a very good job at doing that. Mesa also does the same, the OpenGL[ES] is compiled to mesa ir and then that is compiled into code that will run on each of the respective GPU's Mesa supports or in the case of Gallium3D it supports going to llvm ir for running on the local CPU.

It almost sounds like you're talking about what compiler writers call IR ("Intermediate Representation"), a platform-independent machine-ish language that compilers convert higher-level code to before directly converting it to the machine code for the given architecture.

Like I said, I have many more things that I want to have that LLVM does not seem to support. If TASM was perfect, then why did SPASM and Brass z80 come into existence? Same thing here. I think your advice is good, but not good enough to discourage me from this one.

I would post some moar details on this, but I just posted 2000 chars of text on this on omni, so if you really want to see what I said, look at http://ourl.ca/10553/201344;topicseen#new since I'm way too tired to edit it for this specific discussion, since I just came back home from an exhausting 11-hour straight class of lifesaving, 8 hours were spent in the pool before lunch happened at 4-5 o'clock. So please excuse me if I sound like a [mean guy] ATM.

I am making the executable for the compiler in Java right now, though I'm debating on whether I should switch to C++ or not, not due to ease for me programming but rather for compatibility with a C compiler. I'm thinking though that I'll make my own C compiler (Or make my own OOP HLL that uses Cor0x as an IR) instead that is fine with a java executable.

Also, I've been theorizing some more and I think that it wouldn't be terribly hard to implement my concept of Lo-OO (a concept I had for using object oriented things at a lower-than-C level, right above specific assembly) into Cor0x. Methods and traits of an object would be sorted by type in an address table, in which specific-named traits or methods are access by location on table rather than name. Such as this: Object A is from Class A, which has a constructor, deconstructor, and one method, along with an int and an 80-bit FP real. The methods are first, with the constructor first on list, a deconstructor second (with address == $0 if not existent or defined), and the next few methods -- these methods have a 32 bit label to them that defines them as a method, and give a few other attributes and a virtual name. The int has it's own label, same with the 80 bit FPR. If you want to access the int, you look in the class structure for the address of the int on the table, and look at the object's address table's 4 entry for more details.

A really simple approach to OOP that could be implemented at a really fast speed on any platform, including the Zilog z80. In fact, if I hadn't been discouraged from it, I would have finished my 80% done OOP axiom that implements this. Oh well. At least this will use the theory.

REQUEST: even if you don't know assembly or won't use this, can you post some ideas here to be implemented? The more the merrier.

OOP is just as fast as non-OOP on any machine, actually, because anything object-oriented just gets compiled down into relatively simple machine language, just as it does with functional programming. That sounds like a decent plan; are you familiar with structs and unions in C? Those are similar to your idea (without functions) and thus might give you some additional ideas about what you could add to that.

I am not familiar with those terms -- helpful google search will be very helpful thanks, Kerm!

Yeah, OOP can be fast with modern techniques, but most attempts at OOP I've seen on omni for Axe have been a lot different and very cycle-wasting -- I think that 1000 cycles each time you access an object is a little much compared to ~50 with this

Thanks for the support Kerm, if you say an idea is decent then it must be true

Thanks; I mean it in the "good" sense, not in the "mediocre" sense, in case that was unclear. I hope you'll at least pursue this for the fun and educational aspects, and if you discover it's not something you want to pursue further, then at least it was a learning experience.