Ruvim <
ruvim.pinka@gmail.com> writes:
On 2024-06-23 21:10, Anton Ertl wrote:
Ruvim <ruvim.pinka@gmail.com> writes:
It seems, in almost any system we can have a separate byte-based address >>> space. For an address in this space, 1+ produces the address of the next >>> consecutive byte.
For example, let's consider a cell-addressed, little-endian
Forth-system, where one cell is 32 bits, and several most significant
bits of addresses are always 0.
: byte-address ( addr -- b-addr ) #2 lshift ;
The BCPL approach in reverse. Just say No!
Having two incompatible address types was bad in BCPL (and AmigaDOS
programmers can show you their scars from this mistake), and it would
be bad in Forth.
Well, it's not obvious to me why this is bad.
It leads to bugs where the wrong kind of address is provided or
expected. It leads to complications in designing the words where you
now have to deal with two kinds of addresses and design your words to
expect or provide the right one. And in cases where the usage of the
word includes both kinds of addresses, perform the conversion before
and/or after the call, or have two functionally parallel words, one
for each kind of address; or maybe more, if you want to support
various combinations for the different parameters and return values.
Actually, it's worse than the BCPL approach: On the Amiga in BCPL the
two kinds of addresses were clearly distinct, i.e., the conversion
were not nops, and any mistakes in usage would be found quickly in
testing.
In the suggested approach, on the widely-used byte-addressed Forth
systems the conversion words would be nops, and having one too many,
too few, or in the wrong direction or in the wrong place would not
become apparent in testing. You would have to test on a system where
the address unit >8 bits to find the mistake, and it's likely that the
program won't test there for other reasons (e.g., because it uses
OPEN-FILE). We have seen with CHARS how well that has worked. Even
those who wanted to write Forth-94 standard programs could not test
that their programs actually complied. We finally accepted reality
and standardized 1 chars = 1.
My preferred alternative of reading and writing the data in a byte-per-address-unit format (or maybe converting between a packed and
a byte-per-address-unit format) has the same problem, of course, but
at a smaller scale: if we standardize words for doing this reading and
writing, or this conversion, on a byte-addressed machine you cannot
determine by testing that you did the OPEN-FILE without a BYTEWISE
fam, where it would be appropriate. However, the places where
BYTEWISE would have to be inserted are far fewer, making it much easer
to get right without testing, or to insert missing instances of
BYTEWISE.
For the variant where there is a conversion between packed and
bytewise representations in memory the number of places to consider is
between the fam approach and the two-kinds-of-address approach, so I
would rather recommend the fam approach.
If we do not standardize words for systems with address units >8 bits
(and I currently don't plan to propose such words, because I would
like to see some existing practice before proposing such words), the
situation is actually not that much difference from if we standardize
them: many programs will not use these words either way, and it's best
to go for the variant that requires the least changes.
[two kinds of addresses]
If systems like jsforth want to go there, they should implement it and
establish common practice about such things. It will be interesting
to see how this approach works out with, e.g., 20-bit cells.
It will not work if addresses use all bits in a cell.
That's also the case for jsforth. jsforth can address 16GB (4G
cells), but 32-bit byte addresses can only address 4GB.
The only way that I can see is to use double-cell size addresses to
refer individual bytes (or even bits).
On one hand, requiring double-cell addresses for W@ etc. will
certainly ensure that most or all mistakes in converting between the
address types will be found in testing.
On the other hand, double-cell addresses for W@ etc. conflicts with
existing practice and is very likely to lead to a proposal that
proposes it being rejected. I also doubt that the that the users of
systems with address units >8 bits would prefer it over the fam
approach, and that the implementors of such systems would implement
such words.
- anton
--
M. Anton Ertl
http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs:
http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard:
https://forth-standard.org/
EuroForth 2024:
https://euro.theforth.net
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)