summaryrefslogtreecommitdiff
path: root/ecomp-c/README
diff options
context:
space:
mode:
Diffstat (limited to 'ecomp-c/README')
-rw-r--r--ecomp-c/README39
1 files changed, 38 insertions, 1 deletions
diff --git a/ecomp-c/README b/ecomp-c/README
index f0e3fc5..4e1e88c 100644
--- a/ecomp-c/README
+++ b/ecomp-c/README
@@ -197,9 +197,46 @@ initializing a constant of 'boolean'.
detection of uninitialized variables
------------------------------------
-this might be very hard and heuristical (and the depend on the compiler
+This might be very hard and heuristical (and the depend on the compiler
optimization level). Simple flows can be statically analyzed, what
to do when conditions, loops and complex data structures come into place?
+Also, all statically allocated variables must be initialized (and be it
+to zero) to get deterministic behaviour. Not a biggie, considering this
+is done at compile time and doesn't affect runtime.
+Data on the stack (local variables and parameters) must always be
+initialized by hand.
+
+nesting
+-------
+
+proper function/procedure nesting implies a lot of things to implement
+like closures. For now we don't implement them.
+
+prototypes/forward declarations
+-------------------------------
+
+Wirth dropped them (use function variables or nesting), and uses
+variables of type procedure/function. We should see if it is not
+easier to implement them as they are merily the same as importing
+an exported module symbol. Also, not having nesting might require
+us to use forward references (we have them now in C in both the
+compiler and the assembler, so).
+
+https://github.com/andreaspirklbauer/Oberon-forward-references-of-procedures
+
+loops
+-----
+
+do we need repeat/until along to a while?
+can we do simpler SIMD optimizations when adding a simple (stricly
+mathematical FOR-loop)?
+what about WHILE S1 DO, ELSIF S2 DO, ELSE S3.. like in Oberon?
+
+assertions
+----------
+
+got added in Oberon, handy for debugging and strict contract-based
+programming.
assembler
---------