cc

- proper Pratt parsing of expressions
- fixed some register saving around divs and muls

1 files changed, 29 insertions, 2 deletions

diff --git a/miniany/REQUIREMENTS b/miniany/REQUIREMENTS
index 645bdfa..7dcfc78 100644
--- a/miniany/REQUIREMENTS
+++ b/miniany/REQUIREMENTS
@@ -54,6 +54,7 @@ not implementing:
 - enums as constant replacement (instead of preprocessor), realy enum types
   are not really useful.
 - forward struct definitions or typedefs (handy for Compiler structure), but..
+  and we can work around by not producing any loops (hopefully)
 - for loop: unless we start optimizing (SIMD) there is no real benefit
   for a generic 'for', a strict for i=0 to N, i++ is easier to optimize, when
   you have a grammatical construct to help recognizing it.
@@ -63,7 +64,7 @@ not implementing:
   can just be a ignored keyword.
 - c4 freestanding
   - uses some casts, the malloc ones are actually good for clarification,
-    the ones in memset are not so usefull (this is all because we don't
+    the ones in memset are not so useful (this is all because we don't
     have 'void *')
   - open/read/close is POSIX, we would prefer either C style file handling
     (we have it in libc-freestanding.c or some stdin, stdout thingy)
@@ -82,4 +83,30 @@ not implementing:
     - other cases translate by hand:
       - case EXIT: /* putstring("exit("); putint(*sp); putstring(") cycle = "); putint(cycle); putnl(); */ return *sp;
       - default: putstring("unknown instruction = "); putint(i); putstring("! cycle = "); putint(cycle); putnl(); return -1;
-      
+  TODO:
+  - global char array declarations
+  - void parameter
+TODO:
+- avoid GNU-stype inline assembler (is far too complex), have more a
+  inline bytecode adder for explicit opcodes, e.g. nop -> .byte 0x90
+  - c.c in swieros (the c4 successor) has 'asm(NOP)', this is something we
+    could implement easily, preferably just as 'asm(0x90)'.
+    u.h contains an enum with opcodes (most likely doable or an easy architecture
+    like the one in swieros, I doubt this works for Intel opcodes).
+    There should though be only one single point of information for
+    opcodes per architecture, so asm gets sort of an inline string
+    generator for the assembly output. Or we share a common C-file with
+    enums for the opcodes and cat it to both the assembler and the compiler
+    during the build (should not result in increaed code size, as
+    those are enums).
+    the asm(x) or asm(x,y) constructs can be mapped on the host compilers
+    to asm __volatile__ .byte ugliness. In cc and c4 we can take the swieros
+    approach. This should give us nice lowlevel inline assembly in a really
+    simplified way (basically embedding bytes).
+    Not having inline assembly means you need compilation units written
+    and linked to the program in assembly, which - well - adds a linker
+    and calling conventions, which might be too early in bootstrapping.
+- asm-i386: device a new version which runs on c4 and is again freestanding   
+  - static: just ignore, we don't have a linker, otoh, just rewrite it whithout static,
+    vararg, etc.
+- c4.c: checkout c5-AST branch (darn, that one looks more promising to extend!)