Dave Long writes: > [quoting Kragen] > > It's also used in > > the Open Firmware standard, which describes what Macintoshes and Suns > > have in their ROM to boot with, and in NVIDIA's current "FCode" > > graphics cards. > > That portability means that a card could ship with a simple driver > in ROM, which could work for different host CPU ISAs.
That's the reason for it. > > The execution of words pushes things onto the stack and pops > > other things off the stack; knowing which words are talking to which > > other words requires that you know the stack effects of all the words > > between them. > > But from what I can tell of Chuck Moore's designs, he won't use the > data stack with wild abandon like those of us coming from the Lisp > or Algol traditions are likely to. Yes, that's right; the recent FORTH CPUs (the 21-bit line) don't even have ROT or OVER, just SWAP, DUP, and DROP. I think reading Chuck's code would make me a better programmer, even if I don't program like Chuck, in the same way that reading Remembrance of Things Past might make me a better writer. > (I think his hardware designs have a small (4? 8?) number of data > stack slots, and they'll silently clobber each other, in a circular > fashion, on overflow.) Yes, and control stack, too. The numbers of slots are always a little weird; I think they depend on how much room he has left on that part of the chip when he gets to that. > To increase the knowledge needed, FORTH, like lisp, makes heavy use > of read-time macros. (immediate words) Like backquoting in *sh, > multi-level interpretation gives a great deal of power, at perhaps > some loss in clarity. (but it is nice, at least from the viewpoint > of a C++ linker, to run ctors at compile time instead of run time) Yes --- FORTH avoids the static initialization order fiasco this way, by initializing things at compile-time. > > The rationale for the lack of ... > > The reason for the lack of those things is probably that, being a > fancy macro assembler, FORTH is about getting the CPU to do what has > been described, and any more organization: in memory, on disk, with > interrupts, etc. is left to applications. C doesn't address those > issues either, and leaves them to libraries and the OS. 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. 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. -- /* By Kragen Sitaker, http://pobox.com/~kragen/puzzle4.html */ char b[2][10000],*s,*t=b,*d,*e=b+1,**p;main(int c,char**v){int n=atoi(v[1]); strcpy(b,v[2]);while(n--){for(s=t,d=e;*s;s++){for(p=v+3;*p;p++)if(**p==*s){ strcpy(d,*p+2);d+=strlen(d);goto x;}*d++=*s;x:}s=t;t=e;e=s;*d++=0;}puts(t);}
