Fri Apr 17 12:32:10 CEST 2009
So, the idea is that asm and dasm become integral parts of the
language tower, to allow compile-time checks (type checking) and
partial evaluation based on abstract interpretation.
The challenge is going to be to get a better idea of what is static
and what is dynamic. The confusion is rooted in the type of
application: it is a code transformer, so should all code transforming
code be scheme compile-time code or not?
* referential transparency for asm and dasm. (replace parameters
with explicit environment objects).
* syntax cleanup for signed/unsigned relative/absolute addressing
It's probably best to focus on dasm for now, since it's simpler. Asm
also contains a link to target dictionary.
* add address input to dasm
* add type convertors to dasm
the main decision is: run time (interpretation) or compile time
conversion? let's tick to run-time, and move to compile time when
what is needed is the analogue of this:
(define (paramclass->asm name)
((R) #'asm+/pcr) ;; used for relative jumps
(else #'asm+))) ;; assemble value ignoring overflow
Ok. Using this:
(define (paramclass->dasm name)
we will do parameter class translation at compile time:
box> (dasm-lambda-tx #'foo #'(a R) #'(((123 10) (a 1) (R 5))))
(let-values (((temp13 a R) (disassemble/values '(10 1 5) temp12)))
(and (= temp13 123) (list 'foo (dasm/unsigned a) (dasm/pcr R)))))