Forth course part X
Had I been present at the creation,
I would have given some useful hints
for the better ordering of the universe.
Alfonso the Wise
STRENGTH IN FORTH
part ten
A CREATIVE LANGUAGE
When I started writing this part of the FORTH-course of ST NEWS,
I didn't know yet, how the first issue of this magazine under the
wise , skillful and creative leadership of the new chief-editor,
would look like. I don't know Stefan Posthuma at all. The only
two facts of his complexity I know of are his name and his black-
and-white drawingprogram Artist. So I could write 'wise, creative
and skillful'. A skillful and creative programmer he certainly
is, and wisdom he laid in the fact that he chose to make it a
P.D.- program. I recognise these characteristics as those of an
artist, as I am kind of an artist myself. I do some drawing and
painting now and then. Quite well I might say, and if Rembrandt,
Van Gogh and some other guys hadn't stolen most of my creative
and brilliant ideas, I would have been rather famous all over
this beautiful world now. In writing this course and in
programming my computer in FORTH, I've found a worthy substitute
for that lost empire. Now let's get serious and see what made
me saying, that FORTH is a creative language.
IN THE BEGINNING...
Well, it was in part nine that I promised you to tell you more
about a particular pair of words: {CREATE...DOES>}. The first
part of this mighty combination we have used many times without
much explanation; the second part is going to be a new element in
your ever expanding knowledge of FORTH. One aspect of FORTH is
its extensibility. In defining new words you take advantage of
this feature. Every new word you will enter in the dictionary
will extend FORTH's capabilities. The creation of new words is
made possible by FORTH's compiler. In generating code for a new
entry in the dictionary, the compiler always decides to which
type this entry will belong to. This decision is made by
looking at the defining word used. The most frequently used
defining word in FORTH is {:}. It produces a new dictionary-entry
with - in its code-field - a pointer to some code to handle the
addresses and data compiled in its parameterfield. {VARIABLE} and
{CONSTANT} are two more defining words, each with substantual
different code-field pointers. So {:}, {VARIABLE} and {CONSTANT}
will create different types of entries. This compiler now can be
extended !! By you, the user. Extending the compiler means adding
new defining words. And for that purpose {CREATE...DOES>} will
perform the right action. To avoid total distress, let's begin
our explanation of what is going on with {CREATE...DOES>} by the
very beginning of what you should already know......{CREATE}.
....THERE WAS DISTRESS
I've let you use {CREATE} many times. Remember that chapter
dealing with strings. We then took {CREATE} to set aside a region
of memory for use as a buffer, so we could store a string in it.
{CREATE} is a word that will produce a dictionary head, whose
code field contains the address of the machine code used by
{VARIABLE}. I must tell you, that this code leaves on the stack
the startaddress of the parameter area, when a dictionary head
formed by {CREATE} is later executed. Unlike {VARIABLE}, however,
no parameter space is allocated. So if we
{CREATE} MBUF OK
the dictionary entry will appear as shown in the following
diagram:
|¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯|
| MBUF | <-- Name field
|_________________|
| Address of |
| previous word | <-- Link field
|_________________|
|¯¯¯¯¯¯¯¯| | Code field |
|Code of |<-- | pointer | <-- Code field
|VARIABLE| |_________________|
|________| | | Free | |
| | | | <-- Parameter field
V V
Executing {MBUF} will leave the address of the first free byte in
the dictionary, assuming that {MBUF} is the last word in the
dictionary. In this case it is the same address as returned by
{HERE}. We could now {ALLOT} some space in the dictionary for
storing some values in {MBUF}'s parameter area. Thus if, after
creating {MBUF}, we then type 8 {ALLOT} we shall reserve 8 bytes
of memory. And whenever we'll execute {MBUF}, the address of the
first of these bytes will be left on the stack. To store a byte-
value in the first byte, type
134 {MBUF} {C!} OK
To store a value into the second byte, you'll have to increase
the address of {MBUF} with one
231 {MBUF} {1+} {C!} OK
Fetching a value from a byte is easily done with the help of
{C@}. Some difficulties may arise, if you want to store and fetch
16- or 32-bit values in the parameter area of {MBUF}. To avoid
these difficulties you should add {EVEN}.
{CREATE} MBUF {EVEN} 8 {ALLOT} OK
This will ensure that it all begins at an even address. To store
a 16-bit value, you have to use {W!} and to fetch {W@}. The words
{!} and {@} will accomplish the fetching and storing for 32-bit
values. It is best, if you always treat these three pairs of
words in combination. You may {C@} a value that you stored with
{W!}, but you never can tell what the result may be; that's
unpredictable. If you will respect the combined use of the word
pairs for storing and fetching, you can use this method for a
word that can serve as some kind of variable. That means,
however, a lot of typing. Things should be made easier and
simpler. Some parts ago I gave you some alternative definitions
of {VARIABLE}. Here is another one in terms of {CREATE}.
: 2VAR CREATE , , ;
Now, what are the main differences between these two sequences of
code ( MBUF and 2VAR) in both of which appears {CREATE} ?
1. In the first sequence {CREATE} acts outside a colondefinition,
in the second one it appears inside a colondefinition.
2. In {2VAR} the dictionary-entry for {2VAR} is not made by
{CREATE}, but by {:}.
3. The action of the {CREATE}-word is executed in the definition
of {MBUF}, but it is compiled in {2VAR}. The action, thus, is
postponed till the moment {2VAR} is executed.
4. It is when {CREATE} executes, that it excepts the name of
the dictionary-entry it is to make. This means that the name
should not be included in the colondefinition using {CREATE}.
This name is required when executing {2VAR}; it is then used
to create a new entry in the dictionary by the compiled code
of {CREATE}.
The use of {2VAR} is
123 234 {2VAR} DISTRESS OK
With {2VAR} we created an entry for {DISTRESS} and twice {,} put
two values into the parameter field of {DISTRESS}.
890 789 {DISTRESS} {2!} OK
The above line of code serves to put two new values in the
parameter field of {DISTRESS}. The word {2@} fetches the two
values and pushes them onto the stack and twice {.} writes them
at your display in the following line
{DISTRESS} {2@} {.} {.} 890 789 OK
BE BORN TIRED
Now we have made two steps forward. The first one was analysing
the history of {CREATE} outside a colondefinition. The second one
was, when we looked at {CREATE} inside a colondefinition as in
{2VAR}. So far the most important thing to remember is that all
examples have used the fact that a word defined using {CREATE}
will leave the startaddress of the parameter area on the stack,
irrespective if defined outside or inside a colondefinition. What
is secondly most important now is the fact, that a name for a
{2VAR} doesn't need to be embedded in the definition of {2VAR}
itself. So you can use any name you like each time you executes
{2VAR} and that as many times as you like. In other words: with
{2VAR} you can DEFINE as many words of the type {2VAR} as
necessary. Now let's make the third step. Your programming
passion (and laziness) will urge for the possibility to avoid
additional entering of words, to place on the stack the two
values stored in {DISTRESS}. If it would please you that entering
{DISTRESS} would place these two values on the stack
automatically, then we have to create a new type of word. A word
with some quite welcome action. A word that will really dó
something. In fact that does it to me:
: 2VARI CREATE , , DOES> 2@ ; OK
The difference with {2VAR} is obvious {DOES> 2@}. This part is
not ment to do anything when you are going to use {2VARI} to
DEFINE a new type of word. You may use {2VARI} as follows
123 345 {2VARI} LAZY OK (a)
{LAZY} {.} {.} 123 345 OK (b)
In line (a) we have defined a {2VARI}-word {LAZY}. It is done
essentially in the same way as {DISTRESS} with {2VAR}. As if
there were no {DOES> 2@}-part, there isn't any additional action,
at least not perceptable with one's eye. But things are different
in line (b). To put on the stack the two values in {DISTRESS} we
had to {2@} them and twice {.} made them visable at the screen.
To put on the stack the two values in {LAZY}, it suffies to
execute {LAZY}. On execution the {DOES>}-part of {2VARI} makes
itself useful. It puts the two values on the stack, using {2@}.
Twice {.} remains necessary to display the values. We didn't
include {.} in the {DOES>}-part of {2VARI}. Perhaps it occured to
you, that any word defined with {2VARI} will demonstrate the
above features. And further, did you notice, that such {2VARI}-
words perform identically as words defined with {2CONSTANT} ?
What we were doing all the time, was - step by step - defining a
high level substitute for {2CONSTANT} !! But, you will ask me, is
it possible to include twice {.} in the {DOES>}-part ? Yes, that
is possible ! You are lazier than I thought you were !
: 2VARI CREATE , , DOES> 2@ . . ;
All words defined with this variation of {2VARI} will have the
property to display their 2 values, when they are executed.
CREATING NONSENSE
Here is another example of {CREATE...DOES>}
: 2VARI CREATE , , DOES> 2@ DO 42 EMIT LOOP ;
Before you are going to use this type of {2VARI}, try to imagine
what {2VARI} will work out in the {DOES>}-part. And of course the
number and the order of the parameters, which are needed at the
moment of defining a {2VARI}-word. The parameters are going to
serve as the loop index and limit. Here you are
20 0 {2VARI} STARDUST OK
Enter
{STARDUST} ******************** OK
Is this the result you expected from the code above ? If so, you
understand the power of {CREATE...DOES>}. Try to unravel the
following:
: 2VARI CREATE , , DOES> 2@
CREATE , DOES> @ 1+ DO CR I SPACES 65 MIN DUP EMIT
LOOP DROP ;
It is a rather complicated defining word {2VARI}, which in turn
will create another defining word, which at last will define
words to emit and skew characters with at least ASCII-value 65.
Its use is as follows:
6 0 {2VARI} LOOPDEF OK
Now {LOOPDEF} has become a defining word with the additional
action of putting two values on the stack, which can be used by
all words defined by {LOOPDEF}.
67 {LOOPDEF} ASCDEF OK
{ASCDEF}
C
C
C
C
C OK
Another one
10 0 {2VARI} 10LOOP OK 69 {10LOOP} SKEWEE OK
SKEWEE
E
E
E
E
E
E
E
E
E
E OK
This, of course, is all nonsense. But it demonstrates the
possibility to create hierarchical trees of defining words, as it
is allowed to sort of nest the {CREATE...DOES>} couple. This can
be seen in the latest version of the {2VARI}-word.
STRINGS AGAIN
Let's go on and step back to part nine. There we all fought some
frightful wars with strings, which we won of course. One
complaint, alas, lasted nevertheless. We stayed without an easy
method for creating strings. This easy method can be provided by
{CREATE...DOES>} in the following way:
: STRING CREATE 253 OVER < ABORT" String out of range !"
HERE SWAP DUP 2+ EVEN ALLOT SWAP C!
DOES> 1+ ;
The {DUP 2+ EVEN} sequence serves to avoid an odd address as the
start of the parameter area. In the examples above we were so
heavily concentrating on extending the {DOES>}-part, that you may
have thought that extending the {CREATE}-part was limited to
twice {,}. As you can see now, extending the latter is just
depending on the function of the word.
128 {STRING} MBUF OK
And here you have your empty string of 128 bytes. As you can see
from the code this length is stored in the first byte of the
string. It may be used to determine string-overflow. If in
defining a string the memory allocated for exceeds 253 bytes an
error-message will be given and the system will abort. The
{DOES>}-part puts on the stack the start-address + 1, thus
jumping over the string length byte. To store a string in {MBUF},
the following word will do
: STRING" ( Stringaddr - )
34 [COMPILE] WORD SWAP 2DUP 1- C@ SWAP C@ DUP
ROT > ABORT" Inputstream too long !" 1+ CMOVE ;
It goes like
{MBUF} {STRING"} NO APARTHEID !" OK
As a delimiter {"} is used - ASCII 34. Just forget [COMPILE].
I'll explain that word and some family-members at a later date.
The stringword {STRING"} checks if there is space enough at
{MBUF} to insert the string. Defining a word that will print the
string at {MBUF} at the screen, is all up to you. It can be done
very simple, don't look too high for the solution.
HURRAY, HURRAY, ARRAY, ARRAY
In the above section we didn't mention, that the sequence of
{CREATE MBUF 8 ALLOT} was a simple form for defining a byte-
array. But it is one , although a rather simple one ! I adore
simple facts (They are very relaxing too, see !), but simple and
elegant should unite. The elegance is put there with
{CREATE...DOES>}. Here is a slightly more elegant solution:
: BARRAY CREATE ALLOT DOES> + ;
A twelf element array for single-byte variables is made by
12 {BARRAY} ELEGANT OK
The elements of the {ELEGANT}-array are NOT set to some initial
value. To store a value at the fifth element the following code
will do the job:
100 5 {ELEGANT} {C!} OK
To fetch the contents of the fifth element simply enter
5 {ELEGANT} {C@} 100 OK
For me it's easy to tell how the storing and fetching were done,
but as I might hope, for you too ! The next step could be to
create an array to hold 2-byte values, or one to hold 4-byte
values. I'll give the 2-byte version:
: 2BARRAY CREATE 2* ALLOT DOES> 2* + ;
{2BARRAY} is to be treated in the same way as {BARRAY}.
12 {2BARRAY} ELEPHANT OK
And storing a value in {ELEPHANT} and fetching it successivily
31567 10 {ELEPHANT} {W!} OK 10 {ELEPHANT} {W@} OK
The tiny word {W!} is one of the many words that - as you will
discover - live in your system and that are not standard words.
Some FORTH-systems have been equiped with a 32-bit stack. In such
a system operators aligned for 32-bit values are so to speak
'standard'. Perhaps your system is a 32-bit FORTH, perhaps not.
But my favourite system has a 32-bit stack. In this FORTH the {!}
operator for instance handles values up to 32-bits. Sixteen-bit
values are possible, as are byte-values. These explicit 16-bit
values are handled with special operators. Their names are
derived from the operators {!}, {,} and {@} by means of the
prefix W, as are the byte-handlers with C. So you'll have to
detect what system you are living in and what adaptions there are
to make. As I pointed out before, it is absolutely necessary to
take good care to choose for the right combination of operators.
As you might have already noticed, there isn't any check made in
{2BARRAY} on the range of the index. It could be possible to use
an out-of-range index and so to overwrite other dictionary-
entries. So here is an alternative definition, which will check
the range, give an error-message if needed and that is a 4-byte
array defining word.
: 4BARRAY CREATE DUP , 1+ 4* ALLOT
DOES> 2DUP @ OVER < SWAP 0< OR
IF @ CR ." Range-error - max index = " .
." ; used index = " . QUIT
THEN 4 + SWAP 4* + ;
The use is similar to that of {2BARRAY}, except of course for the
operators to use. The extensive error-checking and reporting will
slow down execution speed. (See part nine on the subject of
error-checking).
It is very easy to develop a two-dimensional-array defining word.
In the following definition the elements of the array are 32-bits
variables and the array contents are not initialised.
: 2DIMARRAY CREATE DUP , * 4* ALLOT
DOES> ROT OVER @ * ROT + 4* + 4 + ;
With
10 6 {2DIMARRAY} ELASTIC OK
you have created a 10 by 6 array called {ELASTIC}. The array
indices may range from 0,0 to 9,5 inclusive. The value 1234567 is
stored in the 3,4 element with
1234567 3 4 {ELASTIC} {!} OK
Sometimes it may be necessary to create a data-structure, known
as 'table'. Such a structure has only to leave the starting
address of the data:
: BYTABLE CREATE ALLOT DOES> ;
And that's all !!
23 {BYTABLE} LIST OK
will create the table {LIST} with room for 23 byte-values. When
{LIST} is executed it will leave the starting address of the
data. To reach the fifth byte, enter
{LIST} 5 + OK
From the early examples it should be clear to you, how to store
and fetch values into and from the table. Another method of
creating a table to store values is the following. It only can be
used if you know the values at the time of creating the table and
if they are not likely to be changed anymore.
CREATE SINUS
0 , 175 , 349 , 523 , 698 , 872 , 1045 , 1219 , 1392 ,
1564 , 1736 , 1908 , 2079 , 2250 , 2419 , 2588 , 2756 , 2924 ,
3090 , 3256 , 3420 , 3584 , 3746 , 3907 , 4067 , 4226 , 4384 ,
4540 , 4695 , 4848 , 5000 , 5150 , 5299 , 5446 , 5592 , 5736 ,
5878 , 6018 , 6157 , 6293 , 6428 , 6561 , 6691 , 6820 , 6947 ,
7071 , 7193 , 7314 , 7431 , 7547 , 7660 , 7771 , 7880 , 7986 ,
8090 , 8192 , 8290 , 8387 , 8480 , 8572 , 8660 , 8746 , 8829 ,
8910 , 8988 , 9063 , 9135 , 9205 , 9272 , 9336 , 9397 , 9455 ,
9511 , 9563 , 9613 , 9659 , 9703 , 9744 , 9781 , 9816 , 9848 ,
9877 , 9903 , 9925 , 9945 , 9962 , 9976 , 9986 , 9994 , 9998 ,
10000 ,
This table reflects the values you'll need, if you're going to
develop an application to draw circles using only integers. I
shall use this table in a part of this course still to come.
Although, if you only knew some of the basic principles of sinus
and cosinus, you would be able to do the mathematical
calculations yourself. If you would like to try, remember that
you are drawing at a screen. So you'll have to deal with the
coordinates of the screen; the solution is not only a
mathematical one.
AN AVERAGE INTELLECTUAL
A far more advanced feature of arrays - rather than of
{CREATE...DOES>} - is the phenomenon of the string-arrays and of
course FORTH is quite capable of implementing such complex
structures well. Perhaps I'll discuss string-arrays at some later
date, as now it will not contribute to the elucidation of
{CREATE...DOES>}. For now I'll give you some intelligent array-
creature, one that will always be able to tell you the exact sum
and average of all its elements.
: IQARRAY CREATE DUP , 0 , 0 , 0 DO 0 ,
LOOP
DOES> DUP DUP @ SWAP 12 + OVER 0 SWAP
0 DO OVER @ + SWAP 4 + SWAP
LOOP
SWAP DROP DUP >R SWAP / OVER 4 + ! R>
OVER 8 + ! 4 + SWAP 4* + ;
First comes the use of this remarkable array:
20 {IQARRAY} EINSTEIN OK
It is not allowed to store values in the 0-th and the 1-st
element, because they are going to be used to hold of all the
elements the average and sum respectivily. Be nice and start
storing values not lower than in the fourth element. (As the
array starts counting at zero, the fourth element is found with
3 {EINSTEIN} ).
2000 3 {EINSTEIN} {!} OK
If you now
0 {EINSTEIN} {?} 100 OK and then 1 {EINSTEIN} {?} 2000 OK
and that's quite intelligent !
3000 8 {EINSTEIN} {!} OK 0 {EINSTEIN} {?} 250 OK
1 {EINSTEIN} {?} 5000 OK
In the {CREATE}-part of the definition the initialising of the
array is done by setting the first element to the number of
elements the user wants the array to hold, and the nexr two
elements to zero. The latter are going to hold the average and
the sum. The need for these three elements is independent of the
- varying - length of the array. After that space is allocated
and set to zero; notice, that if 20 elements are allocated, the
array will count three more elements. The {DOES>}-part in the
first place supplies the address of the start of the array
several times. Then fetches the number of array-elements and sets
off to the 'real' start of the array; the start of the 'user
area', say.( 12 + !!). With {OVER 0 SWAP} the parameters are set
for the coming {DO...LOOP}: (1) start user area , (2) 0 , (3)
number of elements , (4) 0 . Inside the {DO...LOOP} the contents
of the succesive elements are fetched and summed. After the loop
has completed all parameters are set in the right order to
calculate the average of all the elements and to store this
result and the result of the summation at their right place. The
sequence {4 + SWAP 4* +} calculates the address at which the
value that has been input last has to be stored. This means, that
at the moment this value has been stored, the average and sum are
not in accordance with the average and sum of the current values
stored in the array. It is when you enter 0 (or 1) {EINSTEIN}
{?}, that the average or sum are updated. I must admit, that I
need more days to create {EINSTEIN}, than God did for this whole
universe. Perhaps I should have asked His advice ?
Halleluiah !!!
SUMMARY
In the following table I have brought together all words
concerned with storing and fetching values.
|¯¯¯¯¯¯¯¯¯¯¯¯¯|¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯|¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯|
| WORD | STACKNOTATION | DESCRIPTION |
|_____________|_______________________|_________________________|
| C! | ( b addr --- ) |Stores byte-value b at |
| | |address addr. |
| C@ | ( addr --- b ) |Fetches byte-value b at |
| | |address addr. |
| C, | ( b --- ) |Compiles byte-value b in|
| | |the first free byte of |
| | |dictionary. |
| W! | ( w addr --- ) |Stores word-value w at |
| | |address addr. |
| W@ | ( addr --- w ) |Fetches word-value w at |
| | |address addr. |
| W, | ( w --- ) |Compiles word-value w in |
| | |the first free word in |
| | |dictionary. |
| ! | ( n addr --- ) |Stores n at address addr |
| @ | ( addr --- n ) |Fetches n from address |
| | |addr. |
| , | ( n --- ) |Compiles n in the first |
| | |free space in the dictio-|
| | |nary. |
| 2! | ( n1 n2 addr --- ) |Stores n2 at address addr|
| | |and n1 at addr+4. |
| 2@ | ( addr --- n1 n2 ) |Fetches n1 from address |
| | |addr and n2 from addr+4. |
| ;CODE | Used as |Same as DOES> except for |
| |: nnnn CREATE (words) |the assemblercode to fol-|
| | ;CODE (assemblercode)|low. |
| |;C | |
| ;C | Use see ;CODE |Terminates assemblercode |
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
EXTRAS
Another possible form of {CREATE...DOES>} implies the use of
assemblercode in the {DOES>}-part. That is, the {DOES>}-word
itself is omitted and replaced with {;CODE}. The assemblercode is
terminated with {;C}, which is the machinecode counterpart of
{;}. As I have told you in the very beginning of this course I
don't know very much (= nothing) about 68000-assembler.
Nevertheless, here is an example:
: SOMETHING CREATE ,
;CODE SP )+ A0 LMOVE
A0 ) D0 LMOVE
D0 SP -) LMOVE C;
I don't know if you have any working knowledge of 68000-
assembler, but if so, you will probably have noticed that the
syntax of a FORTH-style assembler is a reversed one. The use of
{SOMETHING} is
12345 {SOMETHING} BEAUTIFUL OK
Executing {BEAUTIFUL} puts 12345 on top of the stack. The
{CONSTANT}-word will do exactly the same !! The code above has
been proven suitable for my 32-bit FORTH. I don't know how your
FORTH will react when he gets this code 'fot bread and butter'.
I'll try to explain the code. The {CREATE}-part is quite simple:
create a header in the dictionary and store a number in the first
four bytes of the parameter area. On executing a defined word -
here {BEAUTIFUL} - {;CODE} places the parameter field address on
the stack. Now {SP )+} takes a 32-bit value from the stack, which
in this case is the PFA (Parameter Field Address) and stores it
in address register A0 by {A0 LMOVE}. Then {A0 )} fetches the
contents of the PFA stored in A0 and moves them to data register
D0. At last the contents of D0 are moved to the top of the stack,
overwriting the PFA, which was still there.
SOLUTIONS TO PART NINE
1. As to include a possible space in the string. Otherwise the
following string wouldn't have been possible: a young girl.
2. The definition of {LEFT$} is: : LEFT$ 1 SWAP MID$ ;
3. The optimized version of {COMPARE} looks like:
: COMPARE >R 2DUP C@ SWAP C@ R@ >= SWAP R@ <= AND 0=
IF ABORT" Length-count error !" THEN
R> 1+ 1 DO 2DUP I + C@ SWAP I + C@ 2DUP <>
IF > IF 2DROP 1 LEAVE
ELSE 2DROP -1 LEAVE
THEN
THEN
LOOP DUP 1 > IF 2DROP THEN ;
4. The highest number you can possibly store in a byte is 255.
5. The two parts in the compare word are a) the error-checking
and b) the true comparison.
a) : ?ERRCOMP ( addr1 addr2 count --- | addr1 addr2 count )
>R 2DUP C@ SWAP C@ R@ >= SWAP R@ <= AND 0=
IF ABORT" Length-count error !" THEN R> ;
b) : (COMPARE) 1+ 1 DO 2DUP I + C@ SWAP I + C@ 2DUP <>
IF > IF 2DROP 1 LEAVE
ELSE 2DROP -1 LEAVE
THEN
THEN
LOOP DUP 1 > IF 2DROP THEN ;
: COMPARE ( addr1 addr2 count --- 0 | 1 | -1 )
?ERRCOMP (COMPARE) ;
6. Optimizing {MID$} is done by making it buffer independent and
leaving out the error-checking:
: MID$ SWAP >R SWAP 1 MAX 2DUP R> + SWAP C@ 1+ MIN >R OVER
C@ MIN R> OVER - >R + R> ;
The stacknotation: ( addr1 offset n --- addr2 count ). As you
can see, what is left on the stack is just fine for {TYPE}.
7. The answer is to compare the count-bytes of the 2 buffers.
: IN$ 2DUP C@ SWAP C@ < IF ABORT" String too long !" THEN ;
The rest of the definition remains unchanged and should
follow {THEN}.
8. The 'neutral' {GLUE}-word: ( addr1 addr2 --- )
: GLUE 2DUP >R >R OVER C@ OVER C@ 1+ ROT + ROT 1+ SWAP ROT
MOVE R> R> SWAP C@ OVER C@ + SWAP C! ;
This {GLUE} expects two addresses of stringbuffers; the
concatenated string is placed at addr2. With addr2 {COUNT
TYPE} you can print the string at your display.
9. Here are two adapted words:
: LEFT$ 1 -ROT MID$ ;
: RIGHT$ SWAP OVER C@ OVER - 1+ SWAP ROT MID$ ;
EXERCISES
1. If you studied {CREATE...DOES>} carefully, you should be able
now to define the word {CONSTANT}. For practising purposes
only, as this word is already in your system.
2. Define a word that will print out any string given its start-
address. Call it {.STRING}.
3. Create a defining word that will let you define byte-
variables. Call it {CVARIABLE}.
4. What's wrong with the output of {SKEWEE}?
5. Define {VARIABLE} in terms of {CREATE...DOES>} in two ways:
one version should initialise the parameter field, the other
should not.
6. Replace {SWAP * +} with some other code that will work out
the same. Think it {OVER} and {OVER} !
7. Insert some error-checking in the definition of {2DIMARRAY}.
8. Define a tableword that will leave its starting-address and
the number of items it contains.
9. Which word could I have used in stead of {,} in {SINUS}?
And for what reasons would that have been an improvement?
�
Disclaimer
The text of the articles is identical to the originals like they appeared
in old ST NEWS issues. Please take into consideration that the author(s)
was (were) a lot younger and less responsible back then. So bad jokes,
bad English, youthful arrogance, insults, bravura, over-crediting and
tastelessness should be taken with at least a grain of salt. Any contact
and/or payment information, as well as deadlines/release dates of any
kind should be regarded as outdated. Due to the fact that these pages are
not actually contained in an Atari executable here, references to scroll
texts, featured demo screens and hidden articles may also be irrelevant.
