Take `#>` space from `pad`.

[ekipan]

Per this comment.

[ekipan]

I guess "no builtin words will modify this region" is possibly no longer true. I think see at least uses unbounded space after here.

[jkotlinski]

Don't you like that PAD has a fixed space assigned to it? That seemed like a nice feature to me, as that space was anyway unused.

[ekipan]

I could revert pad at least. I don't really know my way around the memory so I worry if there's any stuff around there. It would give see and all of durexForth free reign after here again I guess.

[jkotlinski]

"I think see at least uses unbounded space after here."

Right, I remember now.. .the main reason why one would have a separate #> buffer, is that other words may work with the HERE RAM. It was very difficult to debug SEE when . and dump was overwriting the data it was supposed to debug.

[ekipan]

Okay, I'll change back pad.

[jkotlinski]

I wonder if SEE works in a way, that is incompatible with mapping the #> buffer to HERE 34 +. It almost seems like it, because as you noticed, it both writes to the HERE area in unbounded fashion, and calls .?

[ekipan]

Oh. That's true. I shall have to change see to start writing there then. Gimme a minute.

[ekipan]

Could use a regression test with loads of branches.

[ekipan]

Can you think of any other words that write to here but also do number format?

[ekipan]

Alternatively!

You could give here 34 + to the user as pad and move see's branch list to $35b. Maybe name it there or something for use in durexForth internal words.

Probably okay as it is, though.

[ekipan]

Did some grepping, ls needs fixed, I can do that. Some of mml.fs looks dodgy but I'm not sure. Possibly v.fs since it accepts to here but probably not.

[jkotlinski]

If you think about it, if all here accesses must change to here 34 +, it is no longer a net improvement. The peak RAM usage would stay the same, the only difference is that the #> buffer moves from one place to another.

In addition, there is the extra 34 + code which also consumes some bytes.

[Whammo]

I think I have an ls that doesn't require buffering.

Edit: I do, but it requires io.

[ekipan]

You could recover most of the code bytes by defining:

( base.fs )
$35b constant there
( ... )
hide there

( format.fs )
: pad here 34 + ;

And then any durexForth words ~that print or need more than 34 bytes~ (without exception, as you say) would use there instead of here, effectively swapping them also as you say. It still has the benefit that user programs that misuse pad or #> are more recoverable, but dF words have to be more careful. Maybe the benefit is not worth the cost.

[jkotlinski]

Right now, I am thinking, it would be nice if PAD can stay at $35b. It would be nice to use that memory for something. It is also nice to have a fixed-size PAD, that does not shrink as more words are added.

About the problem that words such as SEE use HERE as transient storage, and that it conflicts with putting #> at HERE + 34. How about letting SEE and others use PAD as transient storage instead? I think that might be O.K., as long as it is clearly documented.

[ekipan]

...many programmers are reluctant to use PAD, fearing incompatibilities with system uses. PAD is specifically intended as a programmer convenience, however, which is why we documented the fact that no standard words use it.

Sounds cut-and-dried, unless I'm missing something. However it does say that SEE may step on #>.

[jkotlinski]

As I understood it, it is OK to have a non-standard SEE that uses PAD, as long as it is documented.

[ekipan]

You likely know the standard a lot better than I do, and you definitely know durexForth better than I do. I don't know how much of dF relies on storing at HERE so my own personal opinion has changed that this PR is probably not worth it.

[jkotlinski]

It is not urgently needed to change anything, because things work as they are.

At the same time, I think it is right to point out that the current setup is unusual. It is traditional that PAD and #> are at an offset from HERE.

Words like SEE are not compatible with the traditional set-up. I think at the core of things, it is probably bad practice that words like SEE use HERE as general-purpose transient storage, especially in combination with .. That is not portable and generally it should not be expected to work.

[jkotlinski]

How about this idea? Keep everything as in master, but move the #> buffer so that it grows downwards from $3fb.

$35B - $3D9 :: pad buffer $3DA - $3FB :: #> buffer

[ekipan]

Seems like the better idea. Finally looked at the memory map, I guess it's the datasette buffer? And I would also guess the first 31 bytes are used by the interpreter or something. The map I looked at suggests the 8 bytes before and 4 after are also unused, but I'm not confident enough to poke any more.

[ekipan]

A #> overrun now only steps on the end of pad instead of jumping to an unpredictable place in memory. A definite improvement.

[jkotlinski]

That's a nice find, AAY64 also suggests there is unused space around the cassette buffer.

memmap.adoc would need an update, too.