Tue May 20 13:39:41 CEST 2008
constants and the 'parameter' word
Constants are a sort of typed macro: they represent literal values,
but are not necessarily completely defined in the core compiler:
(re)definition of constants is necessary to obtain a specialized
compiler that can generate code.
The problem i run into is where to generate the error for undefined
constants. Currently, target-value evaluation uses target-value-abort
to signal a value is not available. However, this should really be
reserved for labels only.
-> fixed: partial evaluation of target-values NEVER calls the actual
evaluation: this means make-constant can pass code straight to the
assembler (currently: just the constant name)
fixed another problem: wrap-macro/mexit requires the state to be
compilation-state, while macro->code from 2stack.ss works only on
2stack. added a mechanism to temporarily wrap the 2stack state in a
so.. this can be moved to forth. simply add a word 'parameter' which
will create a constant that's later to be redefined. a parameter is
something more than a mere macro: it has a guarantee to produce only a
single value. (i'm thinking about things like 'fosc' and 'baud')
i can't call it 'constant' because of confusion with the way that word
works in standard forth. so:
A parameter is a stub macro that produces a single literal
value. These serve to parameterize lowlevel code without resorting
to more explicit parameterization. (i.e. 'fosc' might influence a
lot of timing related constants)
A parameter that is actually used to generate code needs to be
(re)defined as a macro that produces a single value. Otherwise an
undefined-parameter exception will be thrown at assembly time.
Parameters are thus a somewhat controlled violation of the overall
bottom-up structure of Purrr code.
small prob: the 2stack / compile-state code gave problems again. what
i'm doing now is to avoid that problem and require parameters to be
defined in forth code with mexit support.
EDIT: another problem with paramters: redefining them with another
paramter is not a good idea: basicly, there's a sequential element