Dave Long writes:
> [quoting Kragen]
> > Chuck's vision for FORTH was not that it would be a fancy macro
> > assembler (or, at least, not that it would be used for the things
> > assemblers are used for today). He wanted it to be the user
> > interface, the application programming language, the scripting
> > language, and also the device-driver and kernel language.
>
> But isn't his vision that, if one truly codes, an interactive macro
> assembler is more than sufficient for all those domains? *
It's a matter of definition, I guess --- thus the parenthetical caveat
in my message above.
> * what were early Mac apps written in? Pascal or assembler? I
> think the UI, drivers, and kernel were almost all assembler.
I know they had to fight pretty hard to get it all into their tiny
ROM, so I wouldn't be surprised. But I don't know.
> > I agree that a language doesn't need to include preemptive
> > multitasking, virtual memory, and a filesystem. But it is useful to
> > have these things in your development environnment, and FORTH is also
> > a development environment.
>
> Preemptive Multitasking -- hang a scheduler off the timer interrupt.
You can add it, sure, especially in a single-user FORTH system.
(Messing with the timer interrupt on a multi-user FORTH system might
be rude --- what if someone else was using it?) But you can say the
same thing about a machine with only a ROM monitor that lets you type
in octal machine code.
> Virtual Memory -- is it *really* necessary? (stream large images,
> etc.) if so, initialize the page tables and hang some code off the
> page fault interrupt.
No, it's not necessary, but it is sometimes useful.
> Filesystem -- I like filesystems, but SmallTalkers are mostly happy
> with system images. I wonder how Chuck handles his CVS-like needs?
I hate filesystems, but direct disk access by block number is not an
improvement for most things.
> I think there may be parallels in the early days of micros. "Real"
> computers had {pm, vm, fs}'s, but micro people could get stuff done
> with no pm, no vm, and very little fs. "run light without overbyte"
> (even if DDJ no longer does)
Yes --- this is one reason FORTH was so popular in the early days of
micros.
> > I think reading Chuck's code would make me a better programmer, even
> > if I don't program like Chuck ...
>
> I have an ascii version of the code and shadow blocks for COLOR.COM,
> if you'd like.
I'd like very much to read them; I just never got around to running
ColorFORTH, so I never extracted them.
> His character encoding is an interesting design decision; it both
> avoids byte accesses (which were annoying on the early Alphas) and
> allows his dictionary lookup on x86 to be mostly "repne scasd".
The old traditional FORTH name structure consisted of a single length
byte followed by the first three characters of the name;
interestingly, this could also have been scanned by repne scasd
(except, of course, that the names were in a linked list, not an
array; and the processors of the time didn't have 32-bit registers or
scasd, just scasb and scasw.)
--
<[EMAIL PROTECTED]> Kragen Sitaker <http://www.pobox.com/~kragen/>
[around 1998-12-23], it is amazing to watch fear and loathing and greed at
play with the more speculative Internet stocks. To call this a tulip
craze would be a vast understatement. -- Adam Rifkin, <[EMAIL PROTECTED]>
