Re: Keeping other stuff with addresses

On Tue, 3 Dec 2024 23:52:10 +0000, Stefan Monnier wrote:

Yes, but that was a misunderstanding.  I'm not suggesting that
load/store instructions can access things at any bit position and any
bit size.  Any load or store with a pointer whose last 3 bits is not 0
would
presumably signal en error.

Seems like an odd place to put what are in practice just flag bits.

>
It's a very natural one, tho.  Byte addressing is somewhat arbitrary
(why 8 bits, why not 16 or 4 or 6 or 9 ...?), whereas bit-addressing has
some logic to it (fractional bit addressing would be hard to define).

Various architectures used 6-bit characters--you get 64 characters which
is good enough for the 16 letters, 10 digits, and all the pnctuation
+-*/&|^(){}[]_ ... Realistically, you do not need 7-bit characters until
you add lower case. AND there are some situations where 9-bit characters
would be superior to 8-bit ones.
8-bits won because it was enough (at the time of inception {IBM
360--1963})
we had no need for larger character sets. That need did not arise until
word processors were created (late 1980s) and by then 8-bit characters
were standard.

Just like the 21064 Alpha where they had byte-addressed memory but the
load/store instructions could only handle aligned words.

Well, we know how that turned out, not unlike the way IBM designed the
360
to require data alignment, got badly bitten when they realized it broke
a
lot of Fortran programs, and added unaligned accesses in the 360/85.

>
Yes, but contrary to the case for bytes, there is virtually (literally?)
no code out there which expects non-byte-aligned memory accesses
to work.

FORTRAN COMMON blocks require misaligned accesses to double precision
data.
R E Q U I R E in that it is neither optional nor wise to emulate with
exceptions. It is just barely tolerable using LD/ST Left/Right
instructions
out of the compiler.
I, personally, went through enough PAIN with misalignment, that over
time my mood swung from "aligned only" to "completely misaligned"::
a) because there is no performant* SW workaround
b) it is SO easy to fix in HW.
c) once fixed in HW, any SW burden is so small as to be barely
..measurable.
(*) MIPS LD/ST left/right still requires SW to be aware of the
misalignment so the compiler can emit enough instructions. How
much easier is it if the compiler remains blissfully unaware of
any misalignment.

It would suffer from some incompatibilities, of course, since +1 on
a `char*` would correspond to +8 on the underlying integer, so I'd
expect most `malloc` libraries to croak along with various other
non-100% portable code, but what's a few incompatibility between
friends, when you consider the fact that your architecture would be
philosophically cleaner, able to point to bit fields, *and* grant
3 extra tag bits to implementors of dynamically typed languages?
>
>
        Stefan