[colorforth] About source code, addresses and hardware

[Adam Marquis <adam.marquis@xxxxxxxxxxxx>]

I'm trying myself to simplify things, and I also came to the conclusion
that complexity is needed somehow.

I'm struggling in designing my editor as I'm never satisfied with the 
result:
I'm at the keyboard handler at the moment, and I want to minimize
the shear size of a traditional keyboard handling routine, the only
truly interesting thing I saw was 
http://digilander.libero.it/franapoli/danteadvance/ 

===========
3-4 type of data in forth source (pretty dense, ask for comments):
* String reference in dictionary
 Forth words, if the indexed cell is zero -> definition, as in AHA,
 use aligned adresses, so context can be saved in 2 bits:
 if macro, call right away
 if forth compile call right away (something better to done im sure!
 if named address compile a "# a!"
 if ... then ...

(
Definition can be handled by previously defined macros to change context...
but handling for all would be defined in the string reference handler.
"Forth" would be defined to change the "define" subroutine behavior.
append correct context to the definition... context would be placed at 
MSBits,
so shifting and the carry flag can be used to decode and yield an address.
or perhaps at the LSB, I'm not sure
)

* Comment
Human words, ignored by compiler, used by editor.
Could be only a keystroke sequence (3 bits/key) instead
of huffman, or huffman compressed keystrokes ;p


* Binary number
Machine word, needed to define macros in the first place. For barebone 
systems,
no static part at all, every program is independant, unless one use a
"predefined" compiler as in colorforth. Consensus of best primitives to 
use.

Those are the minimum, then there are:
* Numbers
 those always have a special treatment..... I don't know in what 
category to put em,
in the dictionary I lose one or two bits... not really harmful, unless 
it would be an address
to where the full litteral is stored...

The previous idea could be embedded in hardware, so call and jumps of
8+32 bits long could be reduced to let say 8 bit indexes into a dedicated
circular stack, something like that. Only a push would be used to define,
sure the "flow of indexes" would be hard to follow manually, each word's
index changing all the time but anyway its meant for a machine ;p

Still need polishing but would love to hear comments from you people,
lets tackle some problems together! I'm sure brainstorming could help a lot.
To me, this is an issue we should deal with, or perhaps this isn't the case.
I would love to hear why.

Anyway, if not implemented in hardware, it simplifies source code
a lot to me. I must have a working implementation as soon as possible,
so I can discuss it in my work i have to hand out on the 23rd of January.
Anything suggested will be taken in consideration.

I hope to see the new colorforth soon! Truly inspiring vision!

Adam



---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com