OSDev.org

done:
-preprocessor seems okay.
-variable hierarchy seems okay
-realising of data types
-realising if and for staments
-realising strings
-processing namespaces
-decoding while's
-relocating global variables
-processing things within catnails
-computing sizeofs (not fully done yet)
-computing static number operations


checklist:
-decoding of for cycles
-decoding of ,,if-else''
-simplyfier of the complex formulas
-converting typedef to #define
-decoding declarations
-implementing ,,switch'' keyword
-implementing structs
-decoding operations


compiler nearly reaching 5000 line

Although I have big doubts about its performance (even with loads of cores), I personally think this is a cool project..
designing a CPU *and* having the possibility of building the hardware, for which you write an OS is kind of awesome

yeah, thanks, maybe.
however the heavyest part is the c/c++ compiler i guess
so after i finished with that, i pauses the project, i will release the compiler publicly, independently.

abhoriel wrote:Although I have big doubts about its performance (even with loads of cores), I personally think this is a cool project..
designing a CPU *and* having the possibility of building the hardware, for which you write an OS is kind of awesome

Here's an Alan Kay quote from http://folklore.org/StoryView.py?projec ... _Think.txt

People who are really serious about software should make their own hardware.

I agree with abhoriel, this Geri is doing something interesting.

c to simplifyed c compiler pass shortly will reach milestone1.

this was one of the most hardest programming work probably in my entry life. i mistakenly believed that the assembler will be more heavy, but not (however that seems to be a very heavy work too, but that is at least trivial).

there is some little works left to reach milestone 1:
-convert craps to ,,long'' within [ ] -s (0% done)
-convert craps to proper formats when calling functions (50% done)
-fix converting issue with things within ( ) when calling functions ( e.g. sqrtf(a+b+c+d) )
-short the complex formulas properly (e.g. a=b+c*d (*, so the back starts first))
-blow up the complex formulas (e.g. a=b+c+d -> tmp=b+c;a=d+tmp)

after this, the compiler will be able to properly compile symple *REAL* algorythms like bubble sort or shell sort at lest to simplified c, if this happens, i start to write the c to text assembler (which will probably take lesser time). if assembler is done, i will be finally able to generate binary code.

Geri wrote:-blow up the complex formulas (e.g. a=b+c+d -> tmp=b+c;a=d+tmp)

This seems like a weird explicit goal...

-short the complex formulas properly (e.g. a=b+c*d (*, so the back starts first))

And this just has me wondering.

Do you know what a recursive descent parser is? Do you know anything about formar grammars? (E)BNF? Abstract syntax trees?

Don't get me wrong I don't want to discourage you, but there are very well known ways of accomplishing your goals. It sound to me like you are trying to figure these on your own. (Which is not a bad thing at all!)

no, i never did compiler before. i dubt those techniques would help me aniway, other c compilers are long and complicated as hell also.

but its does not matters any more since i am almost done.

ok lets see the first ,,screenshot'' from the sysetm.



simplifyed C - half way beethwen C and binary code.

it seems from a 60 line long c code, there is a ~200 line length simplifyed c code being produced. i assume that from this, around 1000 instruction long binary code will be compiled. this means 32 kbyte code for executing a 60 line long generic c code. however this can be bigger or slower.

when comparing to x86, where 10.000 line C code creates around 150 kbyte of binary

x86: generally 15 byte binary code per line (with gcc)
my subleq compiler: 533 byte binary code per line

note that most of it used as some kind of local stack in my case, so we can say that x86 (+ gcc) is generally 20x more effective than my subleq architecture.

since i am expecting a 5-10x slower general execution compared to x86 aniway, this does not make it more slower. but i will need a code optimizer later, that decrases the memory demand. i alreday figured out, how to do one, but the first goal is to make it working, and optimize only after that. i hope the memory demand is decrasable with 50%.

but my original suggestion to use 4 kbyte l1 cache seems bad idea, i must lift this number up to 8 kbyte temporally. i will measure the number of the cache misses later.

i alreday started to write the binary code generator. i hope that shortly i will be able to execute the folowing code:

int a=0;
void main(){
do{
a++;
}loop
}

sorry, i not yet was able to build binary

also

just noticed x86-s fake-little crapshit endiannes:
7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 23 22 21 20 19 18 17 16 31 30 29 28 27 26 25 24

anybody know what is the point of this?
i plan to use true littleendian representation:

63 62 61 60 59 ..... 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

Geri wrote:sorry, i not yet was able to build binary

also

just noticed x86-s fake-little crapshit endiannes:
7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 23 22 21 20 19 18 17 16 31 30 29 28 27 26 25 24

anybody know what is the point of this?

I don't think you understand little endian. When you can explain the output of the following program on a little endian machine, then you will understand little endian.

i mistakenly believed little endian means

15 14 13 12 .... 8 7 6 5 4 3 2 1 0

and big endian means

0 1 2 3 4 ... .7 8 9 10 ... 14 15

but, okay, then my system is big endian

also, wikipedia says there is bit-level endianness exist too.

so if my system is
63 62 61 60 59 ........ 10 9 8 7 6 5 4 3 2 1 0, then my system is a big-endian LSB if i mistaking properly

Unless you can address individual bits then it doesn't make sense to talk about bit level endianness. x86 has bytes as smallest addressable units of storage so talking about the order of bits in a byte on x86 is irrelevant. Bit level endianness is really only relevant in serial data transfer.

it matters:
-i should be able to somewhat efficently emulate it
-i should keep some compatibility with the existing file formats to be able to load them efficiently
so i think 64bit lsb will be the most proper choose