CHAPTER 27. MODIFYING 4TH 530
Now it still points to the "duplicate name" error. We simply change "LastMsg4th" to our mnemonic:
/* ranges */
#define LastWord4th
#define LastMsg4th
FTELL
M4FLOATE
We’re done now! Note that this final step is not necessary when you insert messages.
Instead, you will have to renumber the table in 4th.h. No two mnemonics may ever share the same error code, remember that! If you don’t keep the mnemonics, the errorcodes and the messages properly synchronized you may get some pretty strange error messages.
Which is less than helpful.
27.15
Sizing the Code Segment
By default 4tH assumes a 1:1 relationship between a word in source and a compiled word
(in the Code Segment). When ParseText() is called it will count the number of words in the source. This number is later used to size the initial Code Segment. This 1:1 relationship is not so strange as it may seem at first, e.g.:
BL DROP
Will compile to:
[0] literal
[1] drop
Will compile to:
[0] ,
(32)
(0)
Two words in source, two compiled words. But there are exceptions too, e.g.:
BL ,
(32)
That is because ’,’ does not compile to anything, but changes the previously compiled literal to an constant array element. Note that ’,’ is an immediate word. In fact, all exceptions to this 1:1 relationship rule are immediate words! The vast majority of 4tH words obey this
’one on one’ rule:
• All numbers and constants compile to literals
• All ordinary words compile to a word without argument
• All symbols compile to a word with argument
CHAPTER 27. MODIFYING 4TH 531
In a previous chapter we’ve created an immediate word called "[SEXTAL]". When you take a closer look, you will see that it just changes the base; it doesn’t compile to anything.
Still, without the proper argument 4tH assumes it will compile a token and reserves space in the Code Segment.
Can you prevent this? Yes, you can. There is a member in the table of ImmedList[] which allows you to signal 4tH that it shouldn’t reserve space in the Code Segment for
"[SEXTAL]". The first field indicates the length of the keyword, the third indicates the correction 4tH should make to the sizing of the Code Segment when this keyword is encountered, the fourth is the keyword itself and the last one is the C function that compiles the word. The second and the fifth field will be discussed later.
{ 8, 1, -2, "VARIABLE",
{ 8, 0, -1, "[ASSERT]",
{ 8, 0, -1, "[BINARY]",
{ 9, 0, -1, "[DECIMAL]",
"",
"",
"",
"",
DoVariable },
DoAssert },
DoBinary },
DoDecimal },
Now, the correction we want to make is that 4tH should allocate one word less in the Code
Segment, since "[SEXTAL]" does not compile to anything. One less means "-1". We can now change the table accordingly:
{ 8, 1, -2, "VARIABLE",
{ 8, 0, -1, "[ASSERT]",
{ 8, 0, -1, "[BINARY]",
{ 8, 0, -1, "[SEXTAL]",
{ 9, 0, -1, "[DECIMAL]",
"",
"",
"",
"",
"",
DoVariable },
DoAssert },
DoBinary },
DoSextal },
DoDecimal },
That’s all. We’ll give to a few more examples.
E.g. ’VARIABLE’ does not compile to anything either; it just reserves space in the Variable
Area. But ’VARIABLE’ always comes with a name, which doesn’t compile to anything either. So we should decrease the the number of words in the Code Segment by two!
’CONSTANT’ not only requires a name, but consumes a previously compiled literal as well. Initially this literal allocates space in the Code Segment, but it is gone after ’CON-
STANT’ has been compiled. So we decrease the number of words in the Code Segment by three!
’VALUE’ is even more complicated. You can write something like:
10 value ten
But this will compile to:
[0]
[0] literal to
(10)
(0)
’VALUE’ does not consume the previously compiled literal! But the name does not compile to anything. ’VALUE’ takes a value from the Data Stack at run time, while ’CON-
STANT’, ’STRING’ and ’ARRAY’ take a previously compiled literal at compile time. If you don’t believe us, check the glossary.
’VALUE’ itself compiles to something, the literal is undisturbed, only the name vanishes.
That means only one word less, thus "-1".
