If you mean by "independent" architecture independence and the lack of primitives, then the language I've designed and use for my OS matches your criteria. It has only two built-in operator-less "data types", void and byte, the latter merely allocates one byte of memory and nothing more. All the others, like char, int, float etc. implemented in the standard library, and are out of the scope of the language itself. There's a cheat though, my language basically is a dialect of C, but allows assembly mode. It is necessary to implement primitive types, because no operator exists by default to work with (not to mention performance issues).
Example:
Code: Select all
#codeblock "fasm", "x86_64", 48, 12
typedef int {
byte[8] val; //allocate 8 bytes for instance
public inline int +(int val2) {
clbaseof rax, this.val //get offset of instance
add qword [rax], r8 //first argument passed in r8
}
//...
}
Unlike C, my language uses the keyword "typedef" for instanceable classes. The "inline" keyword tells the compiler to use the method as a macro instead of compiling a "call" for it. The codeblock directive turns on assembly mode (and specifies assembler, address space width and page size in bits). The compiler outputs asm source that can be assembled with a crafted macro assembler. Each assembler has it's own include file, the clbaseof mnemonic is a macro defined in this file (fasm.inc in this case).
Non assembly sources (without codeblock directive) will be compiled to an intermediate bytecode object file.
Code: Select all
class app.helloworld {
string hello = "Hello "; //class variable (global among threads)
public int main(string args[]){
string world = "World and "; //local variable (thread private)
lib.ui.printf(hello + world + args[0] + "!\n");
return(true);
}
}
If you want to port it to a new architecture, you'll need a
a) macro assembler for that architecture,
b) an include file for it with specific, well-defined macros,
c) and to port it's stdlib (strictly speaking this is not necessary from the language point of view, but you'll need the types in it anyway).
Once these are ready, you can compile other sources without any modifications. The binary bytecode object files also can be used as is, they will be translated to an assembly source (containing macro invocations only, no direct mnemonics), and assembled to native code with the help of the fore-mentioned include file.
This may seem strange for the first glance, but makes the language, the produced binaries as well as the assembly outputs truly architecture and class independent, which is what I think you were asking.
