Re: Keeping other stuff with addresses

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).

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.

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