BFRTH9.DOC

(11 KB) Pobierz
*lm10:rm70
*hd3:Start Blazin' Forth,page -#-
Forth Geography

Page 231

Not surprisingly, the memory maps of Forth systems tend to differ. Here is the one for Blazin' Forth:

LOW MEMORY **********************
           *  PARAMETER STACK   *
           **********************
           *   TERMINAL INPUT   *
           *       BUFFER       *
           **********************
           *   RETURN STACK     *
           **********************
           *    ERROR MESSAGE   *
           *        BUFFER      *
           **********************
           *   OPERATING SYSTEM *
           *      VARIABLES     *
           **********************
           *   USER VARIABLES   *
           **********************
           *   SCREEN MEMORY    *
           **********************
           *    PRE-COMPILED    *
           *       FORTH        *
           **********************
           *    PRE-COMPILED    *
           *     ELECTIVES      *
           **********************
           *    USER DICTIONARY *
           **********************
           *         PAD        *
           **********************
           *    BUFFER CONTROL  *
           *        QUEUE       *
           **********************
           *    BLOCK BUFFERS   *
           *        (4)         *
           *         or         *
           *    SPRITE IMAGES   *
           **********************
           *  MEMORY MAPPED IO  *
HIGH MEMORY*  AND KERNAL OS     *
           *        or          *
           * HIRES COLOR MEMORY *
           * HIRES SCREEN       *
           * SPRITE IMAGES      *
           **********************
*fp0
User Dictionary


Page 233

The arrangement described here works the same in Blazin' Forth. The only difference is that the variable H , used by Brodie, is called DP in Blazin' Forth. (Stands for Dictionary Pointer.)


Parameter Stack


Page 235-236

'S is SP@ in '83 Forth. Just substitute SP@ for 'S in the examples given, and they will work just fine. In reference to the example showing how to copy the fifth element down, you might want to consult the system documentation for the words PICK and ROLL. (These are '83 standard words.)

S0 is SP0 in Blazin' Forth. Note that this is NOT a '83 standard word. There is also a word SP! , which copies the value stored in SP0 to the stack pointer. This effectively empties the return stack.


Input Message Buffer

Page 236

The modern name for this memory region is Terminal Input Buffer. SP0 does not reference this area. Instead, use the system constant TIB . TIB leaves the starting address of the terminal input buffer on the top of the stack.


*cn1;Chapter 10*cn0


page 255-256

Forth-83 makes a distinction between FLUSH and SAVE-BUFFERS. Both words force all updated buffers to be written to the disk. The difference is that after executing FLUSH , the buffers will be emptied (FLUSH-ed , get it?). But after SAVE-BUFFERS, the blocks will still be in memory, although they will no longer be marked as UPDATEed, since they have been written to disk.

Output Operators

Page 258

Instead of S0 (SP0 in Blazin' Forth) use TIB :

TIB 12 TYPE

Note that a word like S0 or SP0 is very system dependent, but since TIB is a '83 standard word, it can always be used to access the terminal input buffer.

Page 259

To use TEST in the way Brodie describes, it is important to remember that the '83 tick returns the code field address, and not the address of the paramter field. Just remember to use >BODY to do stuff like this, and you'll be fine. I.E.:             
   ' TEST  >BODY 3 + 7 TYPE

where
   ' TEST
gives the CFA (compilation address) of TEST
   >BODY
converts this address to the PFA (address of parameter field), and the rest works as described by Brodie.

Note that the same remark applies to the definition of LABEL . In '83 Forth, LABEL would be:

: LABEL  8 * ['] "LABEL" >BODY 3 +  + 8 TYPE SPACE ;

Note the addition of >BODY to convert the compilation address (CFA) to the address of the parameter field.


Internal String Operators


Page 266

MOVE is not part of the '83 standard. It is included in the Uncontrolled Reference Word set, and in Blazin' Forth, but its definition is different from that given by Brodie. Essentially, MOVE is just a smart CMOVE. It examines the addresses, and then picks CMOVE or CMOVE> as appropriate. This prevents accidentally overwriting data, and is in general one less worry for the hacker.

<CMOVE has been renamed CMOVE> in '83. (The idea is to emphasize function, instead of how its done. CMOVE> is usually used to slide strings towards high memory, as Brodie explains. That's why the upward pointing bracket.)
*fp0
Single-Character Input


Page 268

Following is from the Forth-83 standard:

"...characters received by KEY will not be displayed." Other than this, KEY behaves as described. To duplicate the behaviour of the KEY described by Brodie use the phrase:

  KEY DUP EMIT

You might also examine the systems ?KEY routine, which works like KEY , but doesn't wait for the user to type a key.

Page 270

'83 systems return the ASCII code for every key pressed, including the return key. So the definition of BLOCKS in '83 Forth is:

 : BLOCKS   ( count --- )
      SCR @ + SCR @ DO  I LIST
          KEY 13 = ( CR) IF LEAVE THEN LOOP ;

You can also use Blazin' Forths ?LEAVE :

 : BLOCKS   ( count --- )
      SCR @ + SCR @ DO  I LIST
          KEY 13 = ( CR) ?LEAVE  LOOP ;


String Input Commands, from the Bottom up

page 270
The definition for text is almost the same as Blazin' Forths TEXT. Blazin' Forth's TEXT follows the recommendation of the '83 standard team, and stores the count in the first byte of the string, as does WORD. Otherwise, works the same as described.

Page 271

The example

S0 @ 80 EXPECT

would be

TIB 80 EXPECT

in Forth-83 systems.

Note also that the '83 EXPECT does not store a null at the end of the string. This is one of the major improvements of the '83 standard. '83 standard systems use a count, instead of a delimiter, to determine the end of the input stream. '83 EXPECT stores the count of the characters received in the variable SPAN . More on this later.

Page 275

As you might discover, the FORM LOVE LETTER does not work as described. Certain names will tend to change the text colors, or do other odd things to the display. For example, using:

VITALS  BJ,BLUE,FRED

the program will appear to work just fine. But using

VITALS  VIOLA,BLUE,FRED

will cause a problem - the text will change white when printing the word VIOLA. Clearly, VIOLA causes a problem, while BJ does not. Why is this?

It has to do with the fact that '83 TEXT stores a count byte in the first byte of PAD. So when you execute the phrase

NAME 14 -TRAILING TYPE

You are TYPEing extra characters. In the case of BJ, you will be typing a ASCII 2, an ASCII B and an ASCII J. On the CBM-64, ASCII 2 is a do-nothing character - doesn't do anything at all. So the program appears to work fine. On the other hand, when NAME contains VIOLA (or any other 5 character name), you will be TYPING an ASCII 5, which is the character to EMIT if you want to change the character color to white.

There are two solutions to this problem. One is to change the definition of VITALS to the following:

: VITALS  // modification 1
          ASCII , TEXT ( 44)  PAD 1+ NAME 14 MOVE
          ASCII , TEXT        PAD 1+ EYES 12 MOVE
                1 TEXT        PAD 1+  ME  14 MOVE ;

Which will prevent the count (stored at PAD) from being moved to the variable. However, there is a better solution all together. The solution is to use COUNT. Count takes an address on the stack, and returns the address of the start of the string, and the count byte in the order needed by TYPE. In this version, VITALS remains unchanged (i.e. Just as Brodie gives it in his book), but you will have to replace every occurrence of

<number> -TRAILING TYPE

with the shorter (and faster) phrase

COUNT TYPE

Here is how the beginning of LETTER will look with this second version:

: LETTER     PAGE // modification 2
      ." DEAR " NAME COUNT TYPE ." ,"
   CR ." I GO TO HEAVEN WHENEVER I SEE YOUR DEEP "
                      EYES COUNT TYPE ."  EYES.  CAN "

and so on. If you try this version, you will notice that it runs much faster, and also occupies less space in the dictionary.
*ln2
Page 276

The version of GREET given here doesn't work because of a rather subtle problem. Remember that '83 Forth uses a count, and not a delimiter to determine the length of the input stream. So in order to get this definition of GREET to work, in '83 Forth, you must do the following:

: GREET83  CR ." WHAT'S YOUR NAME? " TIB 40 EXPECT
               SPAN @ #TIB ! 0 >IN ! 1 TEXT CR ." HELLO, "
               PAD COUNT TYPE ." , I SPEAK FORTH. " ;

All of the changes to this definition have been discussed previously, with the exception of the phrase

SPAN @ #TIB !

Since '83 Forth doesn't use a delimiter, but a count which determines the size of the input stream, in addition to reseting the input stream back to the beginning of the TIB with 0 >IN ! , you must also tell Forth how long the current stream is. #TIB controls the length of the input stream when you are not interpreting from disk. SPAN is a variable which is set by EXPECT , and which always contains the number of characters actually received by EXPECT . So by storing the value of SPAN in #TIB , we have told Forth that the input stream is as long as the name the user typed.

Number Input Conversions

Page 277

PLUS will not work as shown, since the version of NUMBER used in Blazin' Forth follows the recommendations of the '83 Standard, and always returns a double number. Use this version of plus on '83 systems:

: PLUS   BL WORD  NUMBER DROP + ." =" . ;

This just drops the high cell of ...
Zgłoś jeśli naruszono regulamin