6.2.2000 PAD CORE EXT

( -- c-addr )

c-addr is the address of a transient region that can be used to hold data for intermediate processing.

See:

Rationale:

PAD has been available as scratch storage for strings since the earliest Forth implementations. It was brought to our attention that 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.

ContributeContributions

ThomasPorninavatar of ThomasPornin [332] PAD alignmentRequest for clarification2024-01-20 20:26:44

Is the PAD buffer guaranteed to be aligned (in the sense of ALIGNED)? This section, and section 3.3.3.6, do not say.

If PAD is not necessarily aligned then it is very tempting to just make it an alias on HERE; but users of PAD must then mind alignment issues, at least on systems where unaligned accesses are undesirable. I don't know whether PAD should be mandated to be aligned or not, but I think that alignment guarantees or lack thereof should be documented somewhere.

AntonErtlavatar of AntonErtl

There is no alignment guarantee for PAD.

The traditional implementation (e.g., fig-Forth) has PAD at some distance from HERE: In traditional systems WORD copies the data to HERE, then there is the pictured numeric output buffer, and then there is PAD. The pictured numeric output buffer grows downwards from PAD-1. So the distance between HERE and PAD in those systems accomodates the size of the pictured numeric output buffer and maybe the strings scanned by WORD (if the system wants to support using <#...#> while parsing with WORD).

Closed
Reply New Version