MEMORY MAP Pygmy fits in one 64K segment. DOS loads it at offset $0100.CS@ will fetch the contents of CS (the code segment), in case you need to know the absolute address of the program. The dictionary grows up from low memory. The stacks & TIB and disk buffers are in high memory (within the one segment). origin $0100 boot code system variables $010E - $013D 1st word (null) $013E HERE $2473 ( perhaps, if assembler is not loaded) TIB @ $F300 1st disk buf $F400 2nd disk buf $F800 data stk ptr $FE00 ( grows down from FE00) ret. stk ptr $FF00 ( grows down from FF00) VOCABULARIES Pygmy, like cmFORTH, has two vocabularies: FORTH & COMPILER. Compiler words are immediate by virtue of being in the COMPILER vocabulary. When in INTERPRET, words are only looked up in FORTH. When compiling, words found in COMPILER are executed immediately otherwise if found in FORTH they are compiled into the new word. To force compilation of a COMPILER word, precede it with a backslash ( \ ). This is used in place of the FORTH-83 word [COMPILE]. CONTEXT holds the number that represents which of the two vocabu- laries is current. Whichever it is, that is the vocabulary into which new words will be linked. FORTH & COMPILER set CONTEXT to the appropriate number. It also has 2 "spare" vocabularies available for use by the meta-compiler. FILES MAX-FILES may be open at once. If you want a different mix, use RESET-FILES and open a new set. See scr 77 of PYGMY.SCR for example. If you then save an image of Pygmy, next time you bring it up, those files will be opened for you automatically. To open a file, you must say what the starting block number should be. I usually open them in 300 block increments, but you may choose whatever increment you wish. It is important that they be in ascending order and that you allow at least enough room for the preceding file. If the third file opened was done this way 600 OPEN DUMMY.BLK then the beginning of the file would be screen 600. The word UNIT could be used so that the beginning of the file would be screen 0. Since DUMMY.BLK is the 3rd file, type 2 UNIT ( 0, 1, 2 = 3rd). ALL screens in all files will now be relative to DUMMY.BLK. FILES - continued To restore the addressing to match the .FILES report, type 0 UNIT. Currently, the files are open-ended. You don't have to say n MORE (as in F83) to extend a file. Just write something to it (using the editor, which does UPDATE automatically) or using n BLOCK or n BUFFER and UPDATE. So, Pygmy allows you to access past the end of a file with no warning! Be careful. When editing, you will see repeating buffers when past the end of the file. Some day I may put an end of file test in editor. NEW-FILE ( in SUPPL.SCR) will create an empty 8 screen file. e.g. NEW-FILE DUMMY2.BLK DIRECT THREADED Pygmy is direct threaded, with TOS kept in a register (BX) for speed. Constants are coded "in-line" rather than by jumping to a central constant routine. This costs 2 bytes per constant but saves 40 cycles (46 vs 86). The code is present but commented out in PYGMY.SCR for the central type CONSTANTs, if you would prefer the smaller slower method. System variables are really coded as constants. So this method helps speed up the system. Variables don't seem to offer the same advantage and so they still use a central routine. DEFER/IS deferred words are supported. EMIT, KEY, KEY?, CR are all deferred. ( e.g. DEFER EMIT ' (EMIT) IS EMIT ) HISTORY & PHILOSOPHY Pygmy is based on cmFORTH by Charles Moore. cmFORTH is designed for the NOVIX Forth chip. cmFORTH doesn't include an assembler as that's not needed for the NOVIX. Also, it doesn't include an editor, as it is designed to be used with a host terminal or computer that supplies the disk storage and editing facilities. A Forth for the IBM PC/XT etc., can't do without an assembler and editor, and so these have been included as part of Pygmy. So, the goal for Pygmy is not to copy cmFORTH exactly, but to use it as a starting point for a fast lean Forth that can be used for serious application development. But where does one stop? I've left out VIEW and I don't really seem to miss it. SEE, however, is in the SUPPL.SCR file in case you want it. I've added multiple files (up to 15, but you can change it to fewer if you like) open at the same time, and the default set are opened automatically. This was inspired by Dennis Ruffer's notes on GEnie about Forth Inc's PolyForth. The editor is fast and is so much more comfortable than the line editor in F83 that I'm satisfied for now. Still, I don't feel I've completely solved the problem of managing source code. I want a lean, fast Forth but I want my comfort, too. What to leave in & what to take out? I have not added vocabularies. I like the cmFORTH idea of marking immediate words by the fact that they are in the COMPILER vocabulary! Everything else is in FORTH. Is this a problem? I don't think so for me. It makes for a crowded & busy WORDS listing and forces the assembler words to end in commas. But so what? The auxilary words can be unlinked from the dictionary to speed up searches and unclutter WORDS somewhat. See HIDE in SUPPL.SCR. If you do the assembler work when you target compile an application there's no need to include the assembler in the application. DO/LOOP have not been included. If you miss them too much, I've put the code for a slow version in STARTING.FTH. I've been enjoying using FOR/NEXT and have not missed DO/LOOP. I'm more concerned with TYPE ( a - a'). In cmFORTH (& Pygmy) it expects to find a count at the first byte of the address. It walks through the address EMITing characters and leaves the 1st address past the string. I like this, but I also miss the old TYPE ( a # -). Of course both could be defined, but what do we call them? ( TYPE & #TYPE I guess.) There are 3 name changes in cmFORTH (& Pygmy) that delight me: PUSH POP \ instead of >R R> [COMPILE]. I think I always get >R & R> right, but it gives me hell everytime I have to think about which is which. PUSH & POP are so much better names, in my opinion. I also prefer \ to [COMPILE]. I like comments in parentheses, so do not mind losing \ for that purpose. Also it is shorter and clearer (I think) than [COMPILE] once you get used to it. The stack comment for cmFORTH's M/MOD is ( l h u - q r) but I have implemented it in the more familiar ( l h u - r q). Is there some advantage to CM's way that I am missing? Of course, there are extensive changes from cmFORTH because the primitives had to be coded for an 8088 rather than a NOVIX. I may have made other changes due to my failing to appreciate the beauty & simplicity of how CM did it. I hope anyone noticing such denseness on my part will point it out to me.
