[colorforth] objects (was: Re-connecting)

[Jecel Assumpcao Jr <jecel@xxxxxxxxxxxxx>]

Frédéric DUBOIS wrote on Thu, 3 Mar 2005 13:25:50 +0100
> I have a question for you CF coders somewhat related to the current
> discussion. If I've looked towards vocabularies and OO, this is because I'm
> a bit in trouble with how to name things when an applications gets a bit
> "wide". For instance, if you have many different data structures and all of
> them have a field where you store the human-readable name of an object, you
> would like to have the word NAME for fetching this field but you cannot
> because it can be at different locations in each data structure, so you have
> to name ITF-NAME for the structure that describes an Interface,
> COMPUTER-NAME for computers, etc. One nice solution would that you manage
> things so that they are at the same location but it would incur some
> penality elsewhere.

I designed an object oriented Color Forth in 2001 and it was implemented
as you suggested. The most cost effective memory chips I could find were
a 512KB Flash memory for permanent storage and an 8MB SDRAM for the main
memory. Even with compression in the Flash, it is obvious that there is
main memory to spare in this machine.

So each kind (there were no classes) of object had associated with it a
large "code vector" that began with a table holding a two word entry for
every word in the vocabulary. Each word holds three MISC instructions,
so that is enough for most definitions while longer ones can have a jump
to the rest of the code.

The memory was addressed by two 16 bit words: the object ID and the
offset within the object. So to "send a message" to an object you just
load its ID (either on top of the stack or in a special SELF register)
into SELF (top 16 bits of the address) and the message index times 2
into PC (bottom 16 bits). The word NAME, for example, might be
associated with index 53 and then we just load 106 into the PC. For
different values of SELF this will execute different instructions. The
good news is that it is just as fast as a plain call in Forth, so there
is no time penalty for using objects.

Supposing that we have 140 different types (unlikely in just 512KB) and
a vocabulary of 2500 words (also unlikely), then these code tables would
take up less than 1.4MB which would still leave plenty of memory unused.
Typically, only 70KB of this would be actually used and the rest of the
space will be wasted with entries that print an error message when
called (because not all words can be used with all kinds of objects).
This is why nobody else used this scheme. You can find several
interesting solutions for reducing the 200,000% overhead of this system
here:

http://www.cs.ucsb.edu/labs/oocsb/papers.shtml (dynamic dispatch
section)

-- Jecel

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