[<<][staapl][>>][..]
Thu Nov 22 04:53:21 CET 2007

standard 16 bit forth

i keep coming back to a standard forth for sheepsint. purrr18 is there
to stay as a low level metaprogrammed machine layer, but teaching it
is a real pain..

maybe the time is there.. maybe a safe language is not the way to
go. maybe a simple forth is more important? maybe standard is
important after all? i have a lot of design choices to make, like
building the interpreter on top of a unified memory model or
not..

 [ mostly triggered by ending up at the taygeta site (from e-forth) ]

more questions. if i want to make a standard forth platform, wouldn't
it be better to go for the 18f2620 with a resonator and a linear
regulator, and add a keyboard in and video out while i'm at it? why
not the dspic then? ( because i didn't port to it yet, tiens! )

so possible projects for januari:
  - portable forth on top of purrr18
  - linear safe language on top of purrr18
  - dspic assembler + compiler
  - a home computer based on 18f2620

strategically, portable forth seems to be the best option, since this
solves most of the documentation issues.. dspic and the home computer
are more of a lab thing. the linear safe language is something i need
to figure out how to do first in PF context.

portable forth could use 'code' words to switch to purrr? maybe it's a
good exercise all in itself to try to write a standard forth, and not
care too much about optimization etc.. i have my non-standard forth
now, so it's good to aim for the average.



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