Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Stefan Monnier <monnier@iro.umontreal.ca>
Newsgroups: comp.arch
Subject: Re: Keeping other stuff with addresses
Date: Tue, 03 Dec 2024 18:52:10 -0500
Organization: A noiseless patient Spider
Lines: 30
Message-ID: <jwvmshc49i0.fsf-monnier+comp.arch@gnu.org>
References: <memo.20241128153105.12904U@jgd.cix.co.uk>
	<jwvcyi87lva.fsf-monnier+comp.arch@gnu.org>
	<vini47$sgi$1@gal.iecc.com>
	<jwvldww6253.fsf-monnier+comp.arch@gnu.org>
	<vio4ge$1eka$1@gal.iecc.com>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Wed, 04 Dec 2024 00:52:11 +0100 (CET)
Injection-Info: dont-email.me; posting-host="c66a6dbeddf801ae87a9f94174194f38";
	logging-data="459689"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX196/VZ60xzJQAGj1qhlLcnweh9kfdXwwTs="
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:V0gir3gpNEBsW12XcX2MTcQZ0IE=
	sha1:k3CxGTLYBkpv2z7W30xxvn8Yrbg=
Bytes: 2620

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