Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!cmcl2!husc6!cfa!willner From: willner@cfa.harvard.edu (Steve Willner) Newsgroups: comp.lang.forth Subject: Re: TIL design topics Message-ID: <659@husc6.UUCP> Date: Sun, 16-Nov-86 18:15:44 EST Article-I.D.: husc6.659 Posted: Sun Nov 16 18:15:44 1986 Date-Received: Sun, 16-Nov-86 20:36:24 EST References: <1001@usl.UUCP> Sender: news@husc6.UUCP Lines: 73 Keywords: Roll Your Own Language In article <1001@usl.UUCP>, elg@usl.UUCP (Eric Lee Green) writes: > > 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), 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. > I don't see any reason not to do this if you have the space, but I can't imagine that the speed gain will be significant. (But I'm not familiar with the 6502; maybe it doesn't have decent indirect addressing??) > 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? Because then if you redefine a word, you get the old definition and not the new one. Better to compile once and _save the compiled program_; then you don't really care how long it takes to compile. Even if you are developing programs and making frequent changes, you can make most of them directly in the compiled code rather than in the source code provided you have a decent debugger. Then when everything's working, go back and change the source. I can post a rudimentary debugger if anyone wants to see it. > Dynamic string handling a' la' BASIC, along with a seperate string > stack. Sounds good to me. > > And a simple module structure, somewhat like Forth "vocabularies", > except with better syntax. Sounds good too. Would you post the syntax that you like better? > And a method of doing overlays, easily. Definitely good. I trust you have a good file system to manage the overlay files. > And array declaration and access words.... Sure. > > And a file-oriented system. Screens are the pits. I couldn't agree more. You should have a good screen editor too. > 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... It's not the organization into blocks that's the problem, it's the lack of higher organization (i.e. files) and the lack of total space. Our FORTH implementation accepts source files of up to 500 blocks each, and one source file can load others using a filename-lookup syntax. I like to put a comment in line zero giving the contents of the block; then I can create an index by printing line zero of each block. With plenty of total space, there is no reason to fill a block, so organization does not suffer, and there is plenty of room for comments. My source files typically range from 10 to 30 blocks each, and a complete program may contain 40 to 50 source files. Normally, one provides a single file that does nothing but load all the other files in the appropriate order. Two more things to consider: If you plan to do any floating point calculations, put the floating point numbers on a separate stack. This sounds unnecessary, but having tried both kinds of implementations, I assure you that it makes a huge difference. A stack 15 elements deep should be plenty. I can post more notes on implementation if there is sufficient interest. Use more than the usual "3 characters plus length" to identify words. I am informed (but have not verified) that "5 characters plus length" is sufficient. Making sure that, e.g. STATE and START are not the same will eliminate many, many problems. Steve Willner Phone 617-495-7123 Bitnet: willner@cfa1 60 Garden St. FTS: 830-7123 UUCP: willner@cfa Cambridge, MA 02138 USA Telex: 921428 satellite cam