PropForth array questions

Don Pomplun

Sallying forth into PropForth, I'm getting into arrays, with a few issues . . .
It seems that defined variables are taking up more space than they should, e.g.,
If I define a long variable: variable x
Then print its (starting address) x . cr
It gives me 17676, apparently the start of all newly defined forth words, variables & constants.
If I then do the same for long variable y:
variable y
y . cr
I get an address of 17688, not the expected 17680. It appears to be wasting 8 bytes.
Similar wastage if I define word variables with wvariable.
What am I doing wrong???
TIA
Don

caskaz

Hi.

value's lfa(link field address) is h44BC
value's nfa(name field address) is h44BE.
h44BE=h85 h80 indicate forth-word. h05 indicate string length.

value's pfa(parameter field address) is h44C8.

Prop0 Cog6 ok
hex
Prop0 Cog6 ok

here W@ .
44BC Prop0 Cog6 ok

variable value
Prop0 Cog6 ok

44BC d32 dump

44BC 0020:
44BC: 52 42 85 76 61 6C 75 65 4D 00 00 00 00 00 00 00   RB.valueM.......
44CC: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
Prop0 Cog6 ok

value .
44C8 Prop0 Cog6 ok

prof_braino

Don Pomplun wrote: »

It seems that defined variables are taking up more space than they should, e.g.,If I define a long variable:
variable x
(starting address) x . cr 17676
variable y
y . cr 17688
not the expected 17680.

It appears to be wasting 8 bytes.

The space allocated for long STORAGE is 4 bytes. BUT the space for the FORTH dictionary overhead (the links, word name, etc) also take space, and this is consumed from the dictionary.

Rule of thumb is each definition costs about 10 bytes minimum.

We START with lots of definitions to do only one thing; after we get it working, we combine those and make one larger definition, and get back 10 bytes for every colon definition we elimitnate. And after we get everything working, we condense the whole thing into assembler, and remove ALL the unused forth over head, if needed.

In my case, I mainly do small functions, and don't run out of room. On the GY-80 driver, I stuff in a graphic display software real time clock,andaltimeter. I ran out of room. By removing the unused diagnostics, and unused small definitions, I made it fit again.

Don Pomplun

Thanks for both replies. Had to dig out my trusty hex calculator & ASCII chart to decode the Dump. "Dump" in itself is a plus to learn about. Don't know what the RB. and M are, I'm guessing it relates to whether I'm look at a New Forth Word, a variable or a constant.
Also good insight into the downside of not combining word definitions once you get things working to reduce all this overhead.
Now back to exploring arrays.

BTW, if you have a local Dollar Tree, around School Start every year, they have scientific calculators (which also include dec, hex, oct & bin functions -- for a dollar, of course.) I always buy half a dozen.

prof_braino

Don Pomplun wrote: »

...Don't know what the RB. and M are, I'm guessing it relates to whether I'm look at a New Forth Word, a variable or a constant.

In the interest of completeness: In the DUMP display, the byte values are displayed on the LEFT as HEX bytes. the are dispalyed on the RIGHT as ASCII characters. This is typical for a DUMP utility in many languages/environments.
The first byyte is 0x52, and is we look at any handy ASCII table we see that 0x52 is ASCII character R. And so on for the rest. The values that don't have a printable character (letter or number or sumbol) are displayed as a period (.) because otherwise they make the cursor move, or control flow, or other nifty stuff that would not be helpful during our diagnosit display.

You can see that the variable name "value" is right in the dictionary entry as literal text.

Exactly why the numbers in those bytes before and after the name have to do with the innards of the dictionary, ad the structure of the forth interpreter. For the time being, just take it for granted that they do what they are supposed to be doing. You will run across the details of why and how when you get to that point where you need them, which should be a little ways off still.

Peter Jakacki

Don Pomplun wrote: »

Thanks for both replies. Had to dig out my trusty hex calculator & ASCII chart to decode the Dump. "Dump" in itself is a plus to learn about. Don't know what the RB. and M are, I'm guessing it relates to whether I'm look at a New Forth Word, a variable or a constant.
Also good insight into the downside of not combining word definitions once you get things working to reduce all this overhead.
Now back to exploring arrays.

BTW, if you have a local Dollar Tree, around School Start every year, they have scientific calculators (which also include dec, hex, oct & bin functions -- for a dollar, of course.) I always buy half a dozen.

Hex calculator? Yes, any other language but not when you have Forth! You can use it as an interactive calculator.

Anyway the dump listing is already a programmer friendly display of what's in the memory, it could have been listed as ones and zeros instead but hex represents bytes but that can make it a little hard to pick out any text that's buried in there, which is the reason for the same 16 bytes being display as possible printable characters as well as the hex. Of course as Prof mentioned some bytes aren't meant to be printable (you know, 0-9,A-Zs, symbols) so since they are already displayed as hex bytes on the left we just substitute a dot as a place holder for it on the right. Of course there are some bytes that are not part of a text string but they might look like text in the right hand listing but odd characters here and there could mean anything.

Remember the dump listing is an aid to the programmer so you should have a bit of an idea about what's what. Bytes in memory can represent numbers, characters, flags, display pixels etc, If I compile a number such as h4252 then it will also show up in the ASCII section as RB but it's not interpreted that way by the software which is itself composed of bytes.

prof_braino

Peter Jakacki wrote: »

Hex calculator... you have Forth... as an interactive calculator..

so try

: 1k 1024 ;
: 1k.dump 1k dump ;
: binary 2 BASE W! ;

Then use words, and pick any word in the dictionary , and try

words 1k.dump
hex
words 1k.dump
binary
words 1k.dump
decimal
words 1k.dump

the command lind can be used as base converting calculator as Peter says:

decimal
1 1024  -1 st?
hex st?
binary st?
+ st?
hex st?
+ st?
binary st?
decimal st?