[<<][staapl][>>][..]

Thu Dec 13 10:54:01 CET 2007

dtc primitives

towards a standard forth.

 1. get it to crosscompile
 2. write a kernel in itself

the important things to note about the implementation is that it is
concatenative: there are no 'parsing codes', meaning, there is no
lookahead.

  * every word is an instruction
  * 'return' is marked by a bit

as a consequence, each word has only 14 bits of payload. two bits are
reserved to distinguish between data and code, and implement the
return instruction.

now the criticism: maybe it's best to ditch the return bit, since it
limits the addressable memory. with 14 bits only 16k words can be
addressed. the trade-off needs somei think it's best to ditch the return bit, since it prevents easy
access to primitives by just reading them from code.

i'm not sure where this can bite, but using the LSB as tag bit
(0=data, 1=code) and making execute ignore the tag bit allows the use
of 15 bit numbers, which can represent addresses.

maybe it's not such a good idea.. i'm a bit uncomfortable with not
having 16 bit width.

 statistics. a return bit makes
only sense if the words are expected to be short. padding is an
option, but awkward, since every label needs to be prepended by a nop
if it's not aligned.

rebuttal: tail recursion. this is the thing that's handled with the
return bit.. i forget a lot of thought already went into this
thing. tail recursion justifies the inconvenience of handling the
extra bit.

remark: a tagged data system can be built on top of this forth. i'm
not comfortable with giving up a 16 data/return stack in favour of a
14 or 15 bit tagged system.

[Reply][About]

[<<][staapl][>>][..]