Why is PAD 68 bytes above the DP?

[IamRob]

I still haven't found the reason for the 68 byte gap between the DP and PAD. Can someone please enlighten me?

[GARTHWILSON]

From my "shadow screen" (really just a description text file):

Code: Select all

\ PAD  is an area of RAM that floats above HERE , leaving enough room for WORD
\ to put a whole line at HERE from the input stream as when commented-out by ( .
\ PAD is used for building pictured numeric output with <# # #> etc., and for
\ temporary storage of strings.  In a sense, it can hold both a pictured numeric
\ output string and a text string at the same time. This is because the pictured
\ numeric output string starts at PAD-1, and grows downward toward HERE as a
\ number string gets built, while the text string starts right at PAD and goes
\ up.  If a string comes in the input stream (using " ) and STATE is off, the
\ string will get put where PAD points.

[IamRob]

GARTHWILSON wrote:

From my "shadow screen" (really just a description text file):

Code: Select all

\ PAD  is an area of RAM that floats above HERE , leaving enough room for WORD
\ to put a whole line at HERE from the input stream as when commented-out by ( .
\ PAD is used for building pictured numeric output with <# # #> etc., and for
\ temporary storage of strings.  In a sense, it can hold both a pictured numeric
\ output string and a text string at the same time. This is because the pictured
\ numeric output string starts at PAD-1, and grows downward toward HERE as a
\ number string gets built, while the text string starts right at PAD and goes
\ up.  If a string comes in the input stream (using " ) and STATE is off, the
\ string will get put where PAD points.

Thanks.

I still am confused by WORD putting a whole line at HERE, as that would require a delimiter other than a space, and words are limited to 31 characters in Forth when finding them.

And I haven't come across enough numeric output to really study "those" words in depth, and didn't realize they built down. But there it is, <# starts at PAD, and #> builds down from PAD. The most common numeric output examples I have seen are with dates. But even they only take a dozen characters at the most.

I feel 68 bytes is overkill. 32 max would probably be enough.

Everyday use in Forth probably would never see that much space used, but maybe in a SEARCH/REPLACE function of a word processor. I know I have never done a SEARCH/REPLACE with over 12 characters, let alone 32 or 68.

I also don't think I have see both HERE and numeric output used at the same time. Couldn't they share the same space?

Maybe the space between HERE and PAD could have been made into an adjustable variable and used like virtual memory is used. If you need more space, then increase the variable.

I am basically speaking from a user with limited memory, like on a 64 kb machine. Users with larger memory access probably would not care one way or another as an extra 30 or so bytes is peanuts to them.

[GARTHWILSON]

IamRob wrote:

I still am confused by WORD putting a whole line at HERE, as that would require a delimiter other than a space, and words are limited to 31 characters in Forth when finding them.

<snip>

I feel 68 bytes is overkill. 32 max would probably be enough.

('s delimiter is ) rather than a space, so you could have a lot more than a word. It can be the whole line; and if you have 64-character lines (like in 64x16 screens), you'll need at least that many bytes.

I have not looked at these internal details in many years; so I hope I'm not steering you wrong.

[IamRob]

GARTHWILSON wrote:

IamRob wrote:

I still am confused by WORD putting a whole line at HERE, as that would require a delimiter other than a space, and words are limited to 31 characters in Forth when finding them.

<snip>

I feel 68 bytes is overkill. 32 max would probably be enough.

('s delimiter is ) rather than a space, so you could have a lot more than a word. It can be the whole line; and if you have 64-character lines (like in 64x16 screens), you'll need at least that many bytes.

I have not looked at these internal details in many years; so I hope I'm not steering you wrong.

Your not steering me wrong. But you are also not giving me an answer that challenges me either.

When talking about screens, ENCLOSE will get the address of any line or multiple lines from a screen and does not copy it to HERE. I often use "; WORD" which will enclose a word definition and usually spans multiple lines much greater than 68 characters. And if anything was copied out of the buffer, it would be to PAD and not HERE.

When creating a colon definition, most of the interpretation is done in TIB and only -FIND searches for the word stored at HERE. And words have a limit of 31 characters.

The longest numeric output I have seen is a DATE/TIME string which has a max of about 22 characters, and is never used at the same time when Forth is searching for words.

So, all-in-all, looking through the Forth system code, I don't see a reason to have as large a gap as is given. Although it really doesn't make much difference from a programming standpoint, it is just more of a curiosity thing than a necessity.

I was just wondering if any one had a reason or ever felt the gap between HERE and PAD was big enough or was even necessary to be that large.

[barrym95838]

I didn't know it was a 68 byte gap until now, but I admit that the first inkling of a reason that flashed through my mind was a standard 64 char line plus a couple of delimiters at either end.

[GARTHWILSON]

Code: Select all

: WORD          ( C -- addr )           \                    SF240-245  ANS_CORE
   TIB     >IN @  +       \ Get the addr of the first char to look at. ^ char addr
   #TIB @  >IN @  -       \ Get the remaining length of string in TIB. ^ char addr len
   0 MAX                  \ Important at end of line:  No -1 lengths!  ^ char addr len
   2PICK  SKIP            \ Derive string starting with non-delimiter. ^ char addr len
   ROT    SCAN            \ Get addr & len of just the word it found.  ^ addr len
   2DUP + TIB - 1+ >IN !  \ Update >IN .  1+ avoids redoing delimiter. ^ addr len
   DUP HERE C!            \ Put word at HERE , starting with length byte,
   HERE 1+ SWAP    CMOVE  \ then the string.                           ^ EMPTY
   BL HERE DUP C@ + 1+ C! \ Put a blank after the word (needed only by CONVERT).
   HERE  ;


: (     ASCII )  WORD  DROP     ;  IMMEDIATE   \  ( -- )   SF24,26  FIG  ANS_CORE

( puts the ASCII value of ) on the stack and uses WORD to find it, and WORD puts the whole thing it found at HERE, including spaces.

[IamRob]

GARTHWILSON wrote:

Code: Select all

: WORD          ( C -- addr )           \                    SF240-245  ANS_CORE
   TIB     >IN @  +       \ Get the addr of the first char to look at. ^ char addr
   #TIB @  >IN @  -       \ Get the remaining length of string in TIB. ^ char addr len
   0 MAX                  \ Important at end of line:  No -1 lengths!  ^ char addr len
   2PICK  SKIP            \ Derive string starting with non-delimiter. ^ char addr len
   ROT    SCAN            \ Get addr & len of just the word it found.  ^ addr len
   2DUP + TIB - 1+ >IN !  \ Update >IN .  1+ avoids redoing delimiter. ^ addr len
   DUP HERE C!            \ Put word at HERE , starting with length byte,
   HERE 1+ SWAP    CMOVE  \ then the string.                           ^ EMPTY
   BL HERE DUP C@ + 1+ C! \ Put a blank after the word (needed only by CONVERT).
   HERE  ;


: (     ASCII )  WORD  DROP     ;  IMMEDIATE   \  ( -- )   SF24,26  FIG  ANS_CORE

( puts the ASCII value of ) on the stack and uses WORD to find it, and WORD puts the whole thing it found at HERE, including spaces.

I know what the code does and posting code is not an answer. What I am asking is, why the need for such a large gap or should the gap be larger?

Let me give you an example. If I print a line with ." like this:

." This is a very long line to indicate that PAD and numeric output gets overwritten by any text that was just printed."

The text gets printed up to the 80 character limit set by QUERY and this test means that the text will over-write any pre-existing values in the numeric output area and anything at the start of PAD. Which also means they cannot hold data for future use. Which also means WORD does not know about the gap between HERE and PAD and is not restricted by the 68 byte limit. WORD is also not restricted by the 64 char limit of a screen line, otherwise it would have C/L MAX in WORD's definition.

My QUERY says 80 EXPECT and it interprets just fine. That should make the gap 80 characters, not 68. If WORD had anything to say about that, it would restrict the input basically to 64.

Since WORD is not restricted, can only mean one thing, that PAD is meant more as a starting point for numeric output to be calculated downwards. The longest numeric string I have seen so far is a Date/Time string that probably looks like this (hr:mn:ss Saturday DDth day of September, YYYY)( makes 45 characters, if text is allowed with numeric output )

I guess then, it is not unheard of to reach large numeric output strings.

[GARTHWILSON]

IamRob wrote:

What I am asking is, why the need for such a large gap or should the gap be larger?

My own is larger, because I allow for my maximum line length of 132...

Quote:

I guess then, it is not unheard of to reach large numeric output strings.

...and if you for whatever reason want a 32-bit pictured numeric output in binary, that's a lot of digits. I don't remember ever doing more than 16 bits in binary pictured numeric output, but I leave the possibility.

[IamRob]

GARTHWILSON wrote:

IamRob wrote:

What I am asking is, why the need for such a large gap or should the gap be larger?

My own is larger, because I allow for my maximum line length of 132...

Now I would like to know, why?
I thought I just proved that the numeric output area and PAD are just temporary position holders and it is ok if WORD over-writes text in those areas.

Were you getting corruption in PAD with something I haven't seen yet, or were you just being cautious?

[GARTHWILSON]

I send the workbench computer source code for my applications over RS-232 from the DOS PC where my screen is 132 columns (and up to 60 lines, although I usually keep it at 43 lines). 132 gives enough room for comments without being cryptic. The workbench computer only has 16K of RAM (but a rather wealthy Forth in 24K of its 32K of EPROM), and with Forth's code density, I've never come close to running out of RAM except when I wanted large data arrays where even megabytes might not be enough. If I ever get around to building my next upscaled workbench computer, I'll add that RAM, probably 12MB (three of my 4Mx8 SRAM modules). The Forth will still run in bank 0 only, but will be able to access the large data arrays in the higher banks.

[IamRob]

GARTHWILSON wrote:

132 gives enough room for comments without being cryptic.

I am still not sure what you are scared of overwriting at PAD since PAD is only temporary? Unless you are storing arrays starting at PAD?

[GARTHWILSON]

I don't remember if I foresaw a problem with that or not. The 132 is not including the pad. Altogether I'm leaving 136+34, or 170. I'll have modify things when I finish and automate my set of words for temporary software buffers at the end of RAM which can even hold temporary code meaning I'll need to be able to compile there, past the pad area.

[JimBoyd]

IamRob wrote:

GARTHWILSON wrote:

132 gives enough room for comments without being cryptic.

I am still not sure what you are scared of overwriting at PAD since PAD is only temporary? Unless you are storing arrays starting at PAD?

Storing arrays at PAD? Whenever anything is added to the dictionary, be it a new definition or just adding data to an existing data structure with comma and c-comma, PAD will move but its contents will not. In Fleet Forth, PAD is defined as:

Code: Select all

: PAD  ( -- ADR )  HERE PADGAP + ;

where PADGAP is a metacompiler string macro which evaluates to $55.
I chose such a large gap between HERE and PAD to accommodate a very large pictured numeric output without crashing through the dictionary. This hypothetical code fragment will work.

Code: Select all

   2 BASE !
   <# 31 0  DO  # ASCII - HOLD  LOOP  # #> TYPE

but this will crash through the dictionary.

Code: Select all

   2 BASE !
   <# 31 0  DO  # ASCII - DUP HOLD HOLD  LOOP  # #> TYPE

I realize these are extreme cases and in practice the gap between HERE and PAD has been far more than what I've needed for pictured numeric conversion and perhaps I'm being a little over cautious. That said, I feel that avoiding smashing the dictionary is worth the cost of a few dozen extra bytes.

[GARTHWILSON]

JimBoyd wrote:

Storing arrays at PAD? Whenever anything is added to the dictionary, be it a new definition or just adding data to an existing data structure with comma and c-comma, PAD will move but its contents will not.

No; what I'm doing is putting temporary software buffers out at the end of RAM. So yes, the pad still floats above the dictionary, but beyond that, there will normally be still-available RAM between the top of the pad and the bottom of the newest buffer. (The buffer area grows down; but it's not totally like a stack, because resizing or deletion of buffers is not limited to the last one created; it's just that if you do resize or delete other ones, ones created later get scooted around as necessary to avoid any fragmentation of memory. The programs that use the buffers obviously will need to know if their buffers got moved. The words that handle the buffer creation / deletion / resizing notifies those programs. It's been a while since I've gotten to work on it; but IIRC, the records of their buffers' starting addresses are kept on the stack, so it's still re-entrant.)

The main use for the software buffers is for temporary variables and arrays; and the way I'm doing it allows using the same normal Forth words ! @ C! C@ OFF ON EXCHANGE etc., which partly means that the temporaries have to have headers like the globals do, but you don't want those taking space after compilation is completed, so those headers (and any defined compile-time behavior code) go in the temporary buffers too. At compile time, their compile-time code and headers go in a temporary buffer, which is deleted after the word using them is finished being compiled, and LATEST gives the address of that word, meaning the link fields are not messed up. At run time, the word needing the temporaries creates space for them in a buffer, which is deleted when that word is done executing.

I'm nearly done with my current work project, and then hopefully they'll give me some hang-loose time before the next big project so I can get back to finishing this buffer stuff. I got to work on it a bit several months ago and then had to put it down; so I'll have to figure out where I left off.