Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!clyde!watmath!watnot!ccplumb From: ccplumb@watnot.UUCP (Colin Plumb) Newsgroups: comp.lang.forth Subject: Re: TIL design topics Message-ID: <12188@watnot.UUCP> Date: Sun, 16-Nov-86 23:59:02 EST Article-I.D.: watnot.12188 Posted: Sun Nov 16 23:59:02 1986 Date-Received: Mon, 17-Nov-86 04:59:23 EST References: <1001@usl.UUCP> Reply-To: ccplumb@watnot.UUCP (Colin Plumb) Organization: U of Waterloo, Ontario Lines: 133 Keywords: Roll Your Own Language In article <1001@usl.UUCP> elg@usl.UUCP (Eric Lee Green) writes: >Velcome, forthfans. > >I am currently designing a small threaded language in which to program >my fairly new Commodore 128. I don't particularly like FORTH, it is >excruciatingly slow on a 6502, and the command names are just aweful >(comeon now, "!"? "."? ":"? Gimme a break!). Well, you can redefine them if you're not happy - but I find they're quite legible after a little bit. > But I do like the general >FORTH idea. So, I'm looking for comments on these implementation >decisions: > >subroutine-threaded: Instead of threads being two-byte machine >addresses, have a jsr
machine instruction instead. Immediate >advantage is speed (NEXT is very slow on a 6502), Yes, trying to handle lots of indirection using 16-bit pointers on a processor without 16-bit registers is the pits. (La Brea tar pits, that is :-) Of course, you could always use the Z-80 in the 128. (1/2 :-) > at a cost of making >the program 3/2 larger. The largest FORTH I've ever seen for the 6502 >was only 25K. My C-128 has 128K of RAM. Space is hardly a problem. Just don't forget that spreading a dictionary across segments is tricky. you might want to copy a bit from Commodore and put only arrays and strings in bank 1, with the rest in bank 0, or some similar static allocation scheme. > >I noticed an additional goodie about subroutine threading -- you can >put assembly language code in the same procedure as regular code, and >you can call regular TIL words from within your assembly language >subroutines. This is one step further toward the goal of being able to >write your program completely in the TIL, then come back and re-write >critical routines and critical parts of routines in assembly language >to get the required speed. Actually, you can already do this in indirect-threaded Forth, with the limitation that a given word must be either all Forth or all assembler. It is, in fact, one of the great strengths of Forth - the calling procedure doesn't change a bit from Forth words to assembler primitives. > >Reversing the links: In most FORTH systems, the "compiler" or >"interpreter" (threader?) starts searching for words starting at the >last word defines, and runs down the link till reaching the bottom or >finding the word. The most-used words, like "@" and "!", though, are >defined close to the bottom of the text stack. So why not start at >the bottom, and go upwards? In Superforth-64, it sometimes takes 10 >seconds to compile a block after reading it in from disk (which is >tediously slow in itself, with the notorious 1541 drive). Probably due >to the fact that it has some 250-300 words in its vocabulary. > >But, what side effects will that have? Surely, there is SOME reason >that FORTH systems usually have the links going the wrong way! The main problem you'll encounter is that your application words will get lost. For example, if you first load some utilities, they may use the word FOO for some purpose. You, the user, might not even know about it, since it's an internal word. Then you try to compile your program, which also uses FOO, and you'll end up with a non-working application, since all references to FOO were caught by the utility's definition. One way to speed up dictionary searching is to split up each linked list into, say, 4 or 8, and hash the word to choose which list to use. XORing the first letter of the word with its length, and masking out the appropriate number of bits is reasonably efficient and fast. > >Those are the major implementation questions. Now for a quick rundown >of some of the other features I'm considering: > >Dynamic string handling a' la' BASIC, along with a seperate string >stack. I have the garbage collector designed, and it is very time >efficient, at the cost of being a bit space-inefficient (a string >variable consisists of a length, address, and link -- 5 bytes). Since >the application I have in mind is very string-intensive, this was a >very important feature to have. Sounds good - you might want to post details for other interested parties. > >And a simple module structure, somewhat like Forth "vocabularies", > except with better syntax. I don't mind the standard Forth vocabulary words if you use a vocabulary stack. But if you've got something better, please post. >And a method of doing overlays, easily. Good. This issue really ought to be addressed in a Forth Standard. >And array declaration and access words.... I'm not so sure these are necessary in a general-purpose language. There are so many variants on arrays (bounds-checking, element size, number of dimensions, address or value returned, etc.) that it's hard to come up with efficient general words, and usually so few are used in any given application that it's no chore to roll your own (start with CREATE ARRAY 100 ALLOT : ARRAY 2* ARRAY + ; and add features as desired). But you did mention that you had a specific application in mind, so my comments may be inapplicable. > >And a file-oriented system. Screens are the pits. The designer of >whatever hard drive etc. that I'm using has already gone to a bunch of >trouble making a compatible DOS driver, it's really a drag to have to >write a FORTH driver for that drive myself when the DOS driver is >sitting there... I have a SFD-1001 disk drive that I cannot use with >Superforth-64 simply because I do not have time or inclination to go >in and critically mangle the screens code. Not to mention that having >to cram all of your code into 16 lines of 64 characters tends to make >you omit comments and otherwise use poor style... Yes, screens are pretty bad compared to standard text files if you've got a driver already written. A blank line put in for readability should *not* take up 64 bytes. Again, please post any bright ideas you have on the subject. >-- > > Eric Green {akgua,ut-sally}!usl!elg, elg%usl.CSNET > (Snail Mail P.O. Box 92191, Lafayette, LA 70509) > >" In the beginning the Universe was created. This has made a lot of > people very angry and been widely regarded as a bad move." -Colin Plumb (ccplumb@watnot.UUCP) Zippy says: My CODE of ETHICS is vacationing at famed SCHROON LAKE in upstate New York!!