Re: [colorforth] objects and forth

[vaded@xxxxxxxxxxxxxx]

On Mon, 9 Feb 2009 22:09:33 -0300 , "Jecel Assumpcao Jr"
<jecel@xxxxxxxxxxxxx> said:
> David J. Goehrig wrote on Thu, 5 Feb 2009 06:56:51 -0500
> > On Wed, Feb 04, 2009 at 10:33:42PM -0300, Jecel Assumpcao Jr wrote:
> > > 
> > > You might find this course interesting:
> > > 
> > > http://www1.idc.ac.il/tecs/
> > 
> > Thanks Jecel, it does look interesting. I got to say, I disagree 100% with
> > their approach on the software side.  Any student is better off learning
> > on real hardware, or at least an emulator of real hardware like Bochs.
> 
> I think both alternatives have their advantages. There are things that
> shouldn't matter but in practice they sometimes do. For example: there
> is little difference between a software emulation of some old computer,
> like a TRS-80, on a modern PC and a reimplementation of the same machine
> using some FPGA development kit. The screen looks the same, the keyboard
> feels the same and the speed is the same. Yet the sensation of using the
> two is different. But it might be just nostalgia on my part - I should
> test it with someone who has never seen the original machine and see
> what they think.
>  
> > > About the subject, I worked on hardware for OO Color Forth in 2001/2002
> > 
> > Do you have anything on it on your sites?  I'm guessing you were looking to
> > use it to power your Self port?
> 
> Here are some pictures of the machine I was talking about:
> 
> http://www.merlintec.com:8080/hardware/uploads/14/oliver002.jpg
> 
> http://www.merlintec.com:8080/hardware/uploads/16/oliver11.jpg
> 
> This terminal for truck drivers started out life as an ATMega603
> microcontroller programmed in Forth. But my clients were not happy with
> the limitations (128KB Flash not programmable in the field, 4KB RAM) so
> I replaced this with the board in the first picture in 2001, which
> reduced the cost while eliminating the restrictions (512KB Flash field
> upgradable, 8MB RAM). Instead of an interpreted Forth on the 4MHz
> processor we would have a MISC running Forth natively at 57MHz. The Self
> project was a parallel effort (with a much larger FPGA) but the two
> influenced each other in interesting ways over the years.
> 
> Given that all information would come from the 512KB Flash whenever the
> machine lost power, it might seem silly to have more than 1.5MB (suppose
> a 3:1 compression for data in the Flash). But building the machine with
> just 4MB or 2MB would actually have made it more expensive! You would
> have to go all the way down to 32KB before you saved any money.
> 
> The most natural size for the MISC processor was 16 bits since that was
> the width of all the memories used. But it would have to address more
> than 128KB (64K words) so an option would be 32 bits, but that was too
> wasteful. 24 bits would have been about right, but really awkward.
> 
> On the software side, a small problem with Forth is that you have very
> local data (on the stack) and very global stuff (the dictionary). It is
> sometimes nice to have something in between. Imagine the code for the
> serial port, for example. You need stuff like the address of the status
> register or the setting of some counter. Globals work ok for one serial
> port, but become awkward when you have two or more. One solution is to
> use objects - then you have a single very local data (the object
> reference on the stack) and it leads you to context dependent global
> data. So now I could have 64K objects in a 16 bit implementations and
> these would make good use of the memory I had.
> 
> So I added just one register to MISC and called it "self". It always
> pointed to the current object. When you addressed the memory using the @
> and ! instructions, the offset would come from the "a" register and the
> base address would come from an object table indexed by "self". There
> was a small, virtually addressed cache (which meant that the object
> table was only accessed when the cache missed and not on every memory
> instruction).
> 
> The call instruction was replaced with two variations of send. One which
> kept the value of "self" as it was and another that loaded "self" from
> the top of the data stack. The old value of "self" was pushed to the
> return stack along with the "PC" (the return instruction popped the two
> registers).
> 
> Normally message sending is a slow process with lots of indirections and
> complicated caches to try to make it faster. That was not acceptable to
> me since I wanted it to run as fast as normal ColorForth. But I had all
> this RAM being wasted, so I simply implemented a full selector/class
> table. This is something that is used in the literature as a comparison
> with practical implementations but is not considered itself to be
> practical (because the table is normally 5 to 20% full at most). This is
> simply a huge 2D table where the row index is derived from the class of
> the object and the column index is the selector (or name) of the
> message. That gives you the address where you should jump to.
> 
> Since most methods are small, I put the start of each one in the table
> entry. That eliminated one indirection in the common case, and when the
> method was too large to fit in there you just put in a jump to the
> actual method and would be no worse off than in the original table.
> 
> One popular solution for finding the class of an object is to have its
> first field point to it. But the alternative I used encodes the class
> into the object pointer itself, avoiding a memory access to fetch that
> every time. So given the value in "self" and the selector (encoded into
> the send instruction) I could start fetching the first instruction from
> the new method on the very next clock cycle, which made this as fast as
> a call in normal ColorForth.
> 
> In early 2003 my clients asked me if I could switch to Smalltalk since
> they found that more readable than ColorForth. I said it wouldn't fit
> into 15K gates like the modified MISC did. But after thinking about it
> for a couple of weeks I figured out a way of converting MISC into a
> reasonable Smalltalk processor by just adding two banks of 8 registers
> each. They liked this change but in early 2004 the project was still
> late and was cancelled though I continued to work on it for a few more
> years. These register banks were used to implement Smalltalk blocks, but
> other than that the difference compared to normal MISC and ColorForth
> was really tiny. Since I was so busy with the hardware level I didn't
> write a lot of code in this OO ColorForth, but what I did write turned
> out very nice. The most significant difference was the use of a garbage
> collector instead of the traditional Forth memory allocation. This makes
> string manipulation a bit more convenient. And like I wrote above,
> having objects as places to store intermediate level data worked really
> well.
> 
> I used the term "class" above several times but the system was actually
> prototype based like Self instead of like Smalltalk. This is a very
> minor detail.
> 
> There are many programming languages I like to use: Forth, Lisp,
> Smalltalk, APL, C, Prolog and so on. Mixing them up doesn't often get
> you very good results, but sometimes it works.None of these is good for
> all problems, but sometimes I see Forth fans deny that by refusing to
> consider as valid problems for which their favorite language is not the
> best option. Like the old joke: "Doctor, it hurts when I do this...",
> "Then don't do that!"
> 
> -- Jecel

Jecel,

You wrote: 

but sometimes I see Forth fans deny that by refusing to
consider as valid problems for which their favorite language is not the
best option.

If you wouldn't mind, could you explicate what contexts you find cf to
be a fitting approach and in what contexts you don't think cf would be
the best match in?  While I understand your point about people thinking
their hammer is best for all nails, in the case of cf, all things being
equal, I have a hard time imagining many situations where I would prefer
to use C, Lisp, Smalltalk, etc.  Of course there are reasons like: 
"my clients don't want it in Forth", etc., but I mean from a more pure
perspective of elegant problem solving rather than from a perspective 
of the socioeconomic realities of programming languages.  

Thanks,

V

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