[<<][staapl][>>][..]
Sat Jul 19 20:40:51 CEST 2008

Reachable vs. Incremental

There are 2 models of developing code:

  * Standard incremental Forth: assemble everything that's generated,
    in the order in which it appears in source code. For subsequent
    code, just append to the already defined code.

  * Reachability: define some entry points into the code, and assemble
    the serialized reachable graph. This allows for more elaborate
    dead-code elimination.

To make it clear, i'm renaming code.ss to incremental.ss since that
part is only necessary for incremental dev.

Also, it seems there was a confusion between 2 parts of state that
need to be maintained:

 - compilation: symbolic assembly code
 - assembly: binary code + allot pointers

Maybe it's best to provide a simplified interface that performs all of
this at once? What is necessary is some kind of transaction model.

Instead of having 'repl' perform just compilation, it needs to do
assembly too. The result of 'repl' is an updated target/incremental.ss
state and a list of to-be uploaded code.

 Q: Is separate compilation/assembly necessary?

Probably only when debugging macros, and then it is probably easier to
use the 'macro> interface, so the control flow analysis and
optimization doesn't get in the way. We'll see later on if a finer
granularity in the api is necessary.

Let's replace 'register-code' with a hook, so the behaviour of what
exactly happens when a file is loaded/required is pluggable.

Hook works fine: this makes things a lot easier. For example now
prj/pic18.ss has full control over what happens when code gets loaded:
it defines two modes: one that accumulates binary code and increments
code addresses, and one debugging mode that simply prints out symbolic
asm.



[Reply][About]
[<<][staapl][>>][..]