Why is PAD 68 bytes above the DP?

[IamRob]

Ok, I am getting closer.

Dealing with binary numbers, the largest 16 bit-number that can be entered is 16-1's. But entering a 16-bit double number can not be entered as 32-1's. It has to be broken up into 2 sets of 16-1's. Which means that only 18 bytes is needed at HERE to form a 16-bit double word of 32-bits as each 16-bit binary number of the double number gets copied to HERE separately.

When printing the double word, still needs 32 bits in the PNO buffer to print out those bits.

We are now up to 18 bytes at HERE for the binary word being interpreted and 32 bytes in the PNO buffer to print the binary number to screen for a total of 50 byte space required between HERE and PAD.

Notice in the picture that the last line was entered with 18 digits for the binary number and I got an UNDERFLOW ERROR.

[BruceRMcF]

IamRob wrote:

Ok, I am getting closer.

Dealing with binary numbers, the largest 16 bit-number that can be entered is 16-1's. But entering a 16-bit double number can not be entered as 32-1's. It has to be broken up into 2 sets of 16-1's. Which means that only 18 bytes is needed at HERE to form a 16-bit double word of 32-bits as each 16-bit binary number of the double number gets copied to HERE separately. ...

Yeah, the 68 is not about entering numbers, it's about other uses for WORD. From a fig-Forth glossary:

Quote:

WORD c --- L0
Read the next text characters from the input stream being
interpreted, until a delimiter c is found, storing the packed
character string beginning at the dictionary buffer HERE. WORD
leaves the character count in the first byte, the characters, and
ends with two or more blanks. Leading occurrences of c are ignored.
If BLK is zero text is taken from the terminal input buffer,
otherwise from the disc block stored in BLK.
See BLK, IN.

So for up to a 31 character counted string, that's 34 characters ... the count, the up to 31 characters, and the two blanks. 33 characters was the minimum space requirement for WORD from Forth94, where they only require one trailing blank.

Of course, it's up to the person implementing it, but that seems like where the 68 comes from.

[IamRob]

BruceRMcF wrote:

IamRob wrote:

Ok, I am getting closer.

Dealing with binary numbers, the largest 16 bit-number that can be entered is 16-1's. But entering a 16-bit double number can not be entered as 32-1's. It has to be broken up into 2 sets of 16-1's. Which means that only 18 bytes is needed at HERE to form a 16-bit double word of 32-bits as each 16-bit binary number of the double number gets copied to HERE separately. ...

Yeah, the 68 is not about entering numbers, it's about other uses for WORD. From a fig-Forth glossary:

Quote:

WORD c --- L0
Read the next text characters from the input stream being
interpreted, until a delimiter c is found, storing the packed
character string beginning at the dictionary buffer HERE. WORD
leaves the character count in the first byte, the characters, and
ends with two or more blanks. Leading occurrences of c are ignored.
If BLK is zero text is taken from the terminal input buffer,
otherwise from the disc block stored in BLK.
See BLK, IN.

So for up to a 31 character counted string, that's 34 characters ... the count, the up to 31 characters, and the two blanks. 33 characters was the minimum space requirement for WORD from Forth94, where they only require one trailing blank.

Of course, it's up to the person implementing it, but that seems like where the 68 comes from.

Right, but I think the misconception here is that a word being found in the dictionary, is not the same as a word failing the dictionary search is then treated as a number.

The difference being that once the word is found in the dictionary, the interpreter then stops searching and just compiles the address and has nothing to do with the PNO buffer, whereas converting to a number still requires the use of of the word that was copied to HERE.

So now the question becomes, what is the longest number that the interpreter can handle and the answer is only 16-bytes for a 16-bit Forth can be used to describe a number, because in BASE-2 that is the longest number that can be entered with 16 digits. The 32-byte length of a dictionary word is no longer the case for a maximum word length entry being treated as a number.

The longest BASE-10 number (-2147483648) only has 11 digits which can be entered into a WORD definition. Try to enter 12-digits or greater and you will get an error.

The largest BASE-16 number is $FFFF and only has 4 digits and uses 6 bytes at HERE. Even a double BASE-16 number is still treated as 2 separate 16-bit numbers separated by a space. The interpreter interprets the first 16-bit number then the second, but when converted to numeric printout, they are included together as a 32-bit print-out.

Now that I understand what it takes to make a larger number, I think I can make my 16-bit Forth print out a 128-bit number. But it still only converts 16-bits at a time towards that 128-bit number.

Which means I only need 18 bytes for the word and 128 bytes for the numeric string.

[IamRob]

This is my final analogy, this is what I believe, and I am sticking with it.

The 68 bytes was calculated as such:

- it was assumed that 32 bits could be entered at HERE as a double number, plus length byte plus ending space, plus 2 (as was mentioned some Forths copy words to HERE+2) = 36 bytes
- and 32 bytes were needed in the PNO buffer to print a 16-bit double binary number

36 + 32 = 68 bytes

The error in the math is then the assumption that 32 bytes is needed to copy a 32-bit number to HERE, when in actuality only a 16-bit binary number can be copied at any one time since a 32-bit double number is separated by a space and seen as 2x 16-bit numbers. Therefore:

16 + length byte + space + 2 = 20 bytes at HERE for the binary word (allowing 2 extra if words are copied to HERE+2)
32 bytes for the numeric printout buffer

20+32=52 max bytes only need be allotted for a 16-bit Forth to print a 32-bit double binary print-out.

using a calculation to find the space required between HERE and PAD can be done with this equation:

n_bits + 4 + n_bits*2

so a 32-bit Forth may need up to 32+4+68=104 bytes between HERE and PAD if binary printout is needed
and a 64-bit Forth may need up to 64+4+128=196 bytes between HERE and PAD if binary printout is needed

CASE SOLVED!


An FYI:
If the lowest BASE to be used is BASE 10 which is usually the case, then the max space needed between HERE and PAD for each bit width. This is printing BASE 10 to BASE 10, and not to BASE-2

16-bit - (-2147483648) (11 + 4 + 11) = 26 bytes to print a 32-bit dbl-word
32-bit - (-18446744073709600000) (21+ 4 + 21) = 46 bytes to print a double word of (64-bits)
64-bit - I don't have the means yet to print a double word of 128-bits

[BruceRMcF]

IamRob wrote:

... Right, but I think the misconception here is that a word being found in the dictionary, is not the same as a word failing the dictionary search is then treated as a number. ...

In programming in fig-Forth, WORD is also a general purpose word ... while the fig-Forth use of WORD in it's outer interpreter is WHY it is defined as it is, it can also be used in general programming.

To be sure, it's an essential system word, but fig-Forth leveraged a lot of essential system words to make them available for other purposes as well.

For a bespoke implementation based on fig-Forth, that isn't aiming to support the whole fig-Forth model, and if you aren't hosting any source that makes that kind of use of WORD, then there certainly does seem to be an opportunity to squeeze that space down a bit more ... just as you can squeeze the PNO buffer down if you don't have any double number output capability.

In other words, the ultimate answer to "why 68 bytes?" in the fig-Forth model seems like "because it's handy", not because it is essential.

[BruceRMcF]

Note also that "Pictured Numeric Output" is expected to be able to hold characters in addition to the digits. That is what HOLD is for. So the PNO buffer has to be one or two characters larger than the maximum number of digits, for the HOLD character(s).

[IamRob]

BruceRMcF wrote:

In programming in fig-Forth, WORD is also a general purpose word ... while the fig-Forth use of WORD in it's outer interpreter is WHY it is defined as it is, it can also be used in general programming.

I am still willing to bet that even in general programming, everything is separated by spaces. Without spaces, the English language could not be read or understood efficiently. Even math expressions need to be separated by spaces to fully comprehend the equation. There is no general programming that would ever use more space than what I laid out as a requirement above.

Quote:

For a bespoke implementation based on fig-Forth, that isn't aiming to support the whole fig-Forth model, and if you aren't hosting any source that makes that kind of use of WORD, then there certainly does seem to be an opportunity to squeeze that space down a bit more ... just as you can squeeze the PNO buffer down if you don't have any double number output capability.

The Fig-Forth model never was whole. It started out as a general idea of what a Forth system should look like. That is why it is continually being improved upon. Standards keep changing, programmers keep revising it ..etc. The nicest thing for me, about Fig Forth is, it is very compact and easy to change and/or make it compatible with other Forth standards. To make as simple as one wants or as complicated as one needs. But without understanding the complete workings of Forth, those changes can be difficult. I am like that guy on "The Matrix" who asks "Why?". He says "Without Why? There is no purpose. No meaning."

Quote:

In other words, the ultimate answer to "why 68 bytes?" in the fig-Forth model seems like "because it's handy", not because it is essential.

Like the teacher always says "show your home work". I wasn't looking for a general answer. I was hoping someone already had that knowledge and would show me how that number was arrived at. Only then can one truly understand the workings of Forth. And since 99% of the postings on this forum are about making the Forth system either more efficient or more flexible, then it becomes a necessity to understand Forth's complete workings.

Without posting here, I would have never known that some Forths copy a word to HERE+2. There must be a reason for this as well. If you could point to an example of which Forth uses it, I would like to see it. If it is just done that way because its handy, that is fine. I still want to see it. Programming that way may have made some other code more efficient and/or faster.

I guess for future questions I will have to learn to change my questions to "How is the 68 bytes between HERE and PAD calculated."

But I am sure I will still get silly answers like "It was a random number picked out of a hat." or "That's just the way it is".

With answers like these, no wonder no-one posts to these Forums any more.

[BigEd]

I think it's often necessary to discount unhelpful answers - what really matters is getting forward progress from the good answers, and I'm sure it helps to formulate the question with care. I even think it's sometimes worthwhile starting a new thread with new subject and head post, to try to get the discussion and responses that you want.

(I'm saying all that on general principles: I don't know whether or not it's worth restarting this thread. But it might be. Certainly those 68 bytes came up in some engineer's head at some point, and probably for a reason.)

[BruceRMcF]

IamRob wrote:

BruceRMcF wrote:

But I am sure I will still get silly answers like "It was a random number picked out of a hat." or "That's just the way it is".

I said the the size allocated for the PNO buffer is the size required to display a double number including room for a couple of HOLD characters. That's 34 bytes. That's neither "it was a random number picked out of a hat", not "that's just the way it is". That's what the fig-Forth style PNO requires. The "<# # #S #>" words are defined to use double numbers, and you need SOME room for the HOLD characters, else why have HOLD in the first place?

If space is tight, and output of double numbers is not seen as important as it was back in 1979, the "<# # #S #>" words could be redefined to work with singles, and you could squeeze that down to 18 bytes.

The 80's were a while ago, and I needed to refer back to a fig Forth glossary to remember the detail about the two trailing spaces, hence thinking at first that it was one trailing space. Again, if space is tight and using word as an general purpose input word for counted strings is not given any priority, you could shrink to the maximum required for numeric input when BASE is 2.

[IamRob]

BruceRMcF wrote:

I said the the size allocated for the PNO buffer is the size required to display a double number including room for a couple of HOLD characters. That's 34 bytes. That's neither "it was a random number picked out of a hat", not "that's just the way it is". That's what the fig-Forth style PNO requires. The "<# # #S #>" words are defined to use double numbers, and you need SOME room for the HOLD characters, else why have HOLD in the first place?

If space is tight, and output of double numbers is not seen as important as it was back in 1979, the "<# # #S #>" words could be redefined to work with singles, and you could squeeze that down to 18 bytes.

The 80's were a while ago, and I needed to refer back to a fig Forth glossary to remember the detail about the two trailing spaces, hence thinking at first that it was one trailing space. Again, if space is tight and using word as an general purpose input word for counted strings is not given any priority, you could shrink to the maximum required for numeric input when BASE is 2.

Thanks a lot Bruce. You have been most helpful. You have guided me in the right direction to solve what has been bothering me.

My biggest confusion, and I think everyone elses as well, is that a double number is not compiled all at once. It is compiled as two separate 16-bit numbers. Which means it is not 34 bytes needed at HERE for the word, but only 18 bytes for each half of the double word. This can be proven by trying to enter a 17-digit or more binary number in BASE 2. You will get a compile error.

Double numbers is just as important, and maybe even more so, on a 16-bit model of Forth as a 32-bit or 64-bit Forth, as it allows me to calculate the big numbers which come up now and again. I now have the understanding in that I can calculate and display a 128-bit number on a 16-bit platform.

Thanks for everyone's help.

[GARTHWILSON]

Quote:

My biggest confusion, and I think everyone elses as well, is that a double number is not compiled all at once. It is compiled as two separate 16-bit numbers. Which means it is not 34 bytes needed at HERE for the word, but only 18 bytes for each half of the double word. This can be proven by trying to enter a 17-digit or more binary number in BASE 2. You will get a compile error.

I've never used pure fig-Forth; but from the variations I've used (modified for Forth-83), you can definitely enter a double base-2 number from the keyboard to put it on the stack, like 1101011100010100101011.111011001 . (I just tried it.) As for compiling, NUMBER, looks to see if there was a . , and if there was one, it compiles a double-precision number, otherwise compiles a single-precision. It works in binary too. I ran it just now in a test word that included D. to show it, and it worked.

[IamRob]

GARTHWILSON wrote:

Quote:

My biggest confusion, and I think everyone elses as well, is that a double number is not compiled all at once. It is compiled as two separate 16-bit numbers. Which means it is not 34 bytes needed at HERE for the word, but only 18 bytes for each half of the double word. This can be proven by trying to enter a 17-digit or more binary number in BASE 2. You will get a compile error.

I've never used pure fig-Forth; but from the variations I've used (modified for Forth-83), you can definitely enter a double base-2 number from the keyboard to put it on the stack, like 1101011100010100101011.111011001 . (I just tried it.) As for compiling, NUMBER, looks to see if there was a . , and if there was one, it compiles a double-precision number, otherwise compiles a single-precision. It works in binary too. I ran it just now in a test word that included D. to show it, and it worked.

Is this being tested on a 16-bit version of Forth-83 or a 32-bit Forth-83? It is the same idea that FigForth was made to work on an 8-bit machine but use 16-bit values and print out 32-bit numbers. I consider this to be a 16-bit FigForth as it was programmed to handle 16-bits at a time even though it is on an 8-bit machine. And even then, a 32-bit FigForth can also be made to run on an 8-bit machine. It all comes down to what your version of Forth was programmed to handle.

If the Forth-83 you are using can handle 32-bit numbers, I would consider that a 32-bit Forth.

In HEX, my maximum input for a hex number is $FFFF. If you can handle 32-bits then your max hex number should be $FFFFFFFF without any spaces. If this is correct, then your double number printout should be able to handle $FFFFFFFF FFFFFFFF separated by a space.

[GARTHWILSON]

32-bit is a double-precision number. Getting the double precision when entering a literal all it one gulp requires the decimal point to tell it it's not a standard 16-bitter. Entering FFFFFFFF without a decimal point or a space produces an error condition. A 32-bit Forth would be one where double precision is 64 bits.

[BruceRMcF]

But what if you are using PNO words in interpret state?

2 BASE !
<# # # # # # # # # # # # # # # # '.' HOLD #S '%' #>

[IamRob]

GARTHWILSON wrote:

32-bit is a double-precision number. Getting the double precision when entering a literal all it one gulp requires the decimal point to tell it it's not a standard 16-bitter. Entering FFFFFFFF without a decimal point or a space produces an error condition. A 32-bit Forth would be one where double precision is 64 bits.

YAY! Finally an answer I can chew on. Never thought about using the period with a binary number, as that looks too much like a decimal place.

So Final answer is: 32 bytes for 32-bit binary input + length byte + period + 2 spaces = 36
and 32 bytes for numeric printout = 68 bytes

or maybe this:

32 bytes for 32-bit binary input + length byte + period + 1 space = 35
and length byte (which is not needed but included for completeness) + 32 bytes for numeric printout = 68 bytes