Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Newsgroups: comp.arch
Subject: Re: Keeping other stuff with addresses
Date: Sun, 1 Dec 2024 15:22:14 -0800
Organization: A noiseless patient Spider
Lines: 66
Message-ID: <viir36$2qq41$9@dont-email.me>
References: <memo.20241128153105.12904U@jgd.cix.co.uk>
 <20241128185548.000031c9@yahoo.com> <vidtpt$pon$1@gal.iecc.com>
 <2024Nov30.072829@mips.complang.tuwien.ac.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 02 Dec 2024 00:22:15 +0100 (CET)
Injection-Info: dont-email.me; posting-host="17232c29395538db7d47c3a356e5c0c8";
	logging-data="2975873"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/GF7T1qaPO4fnHkxQxBWO9kOyo48QZrSY="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:IWcIQlzXrcyPRfaY5tO1+DjomAI=
In-Reply-To: <2024Nov30.072829@mips.complang.tuwien.ac.at>
Content-Language: en-US
Bytes: 4515

On 11/29/2024 10:28 PM, Anton Ertl wrote:
> John Levine <johnl@taugh.com> writes:
>> S/360 had 24 bit addresses and 32 bit registers. When doing address arithmetic
>> the high 8 bits of the register were ignored. That turned out to be a really bad
>> decision since a few instructions and a lot of programming conventions stored
>> other stuff in that high byte, causing severe pain a few years later when
>> memories got bigger than 16 meg.
> 
> The technique of putting stuff in unused bits of an address has its
> drawbacks, but it also has benefits, in particular type information is
> often stored there (even on architectures that do not ignore any
> bits).  Of course AMD and Intel have the bad examples of S/360 and
> 68000 in mind, and did not want to have anything to do with that
> during the first two decades of AMD64.

Fwiw, stealing bits from pointers is a common practice in exotic 
lock-free algorithms. It's not portable at all, but comes in handy!


> 
> The designers of ARM A64 could think beyond that and designed in the
> top-byte-ignore feature.  Apparently this made AMD and Intel see the
> light:
> 
> AMD added the upper-address ignore feature, which, when enabled,
> ignores the top 7 bits.  One problem with this in the Linux kernel
> (and maybe other OSs) is that the Linux kernel expects the top bit to
> be set only for kernel addresses.  Not sure how that works with ARMs
> top-byte ignore feature, which is supported since Linux 5.4 in 2019
> using the PR_SET_TAGGED_ADDR_CTRL option of the prctl() call.
> 
> Intel added the linear address masking feature, with two variants:
> LAM_U57 ignores bits 57-62 (but not the MSB), allowing 6 bits for
> other uses; LAM_U48 ignores bits 48-62, allowing 15 bits for other
> uses.  These variants require bit 63 to have the same value as bit
> 56/47; another bit could be made available by ignoring bit 56/47 (the
> information is in bit 63 anyway), but Intel apparently decided that
> programmers don't need that extra bit.
> 
> RISC-V has the pointer-masking extension, which ignores the top 7 bits
> (like AMD's upper-address ignore) or optionally 16 bits.
> 
> See <https://muxup.com/2023q4/storing-data-in-pointers> and
> <https://lwn.net/Articles/902094/>.
> 
> Concerning the kernel requirements, as someone who has implemented
> Prolog with tagging, having to untag on passing an address to the
> kernel would be only a minimal cost.  Not having to unmask on every
> memory access would be quite useful.  Having the top bit always be 0
> with the tags in the 6 bits below would not have been a restriction
> for us (we used 4-bit tags); OTOH, if one more bit was available,
> programmers would find good uses for it.
> 
>> These days I'd say the relevant N is the size of arithmetic registers but a
>> lot of marketers appear to disagree with me.
> 
> Which arithmetic registers on an Intel processor?  The 64 bits of a
> GPR?  The 128 bits of an XMM register?  The 256 bits of a YMM
> register?  The 512 bits of a ZMM register?  Note that until recently,
> Intel sold you the same silicon either with only XMM or with XMM and
> YMM registers.  They sell consumer CPUs with XMM, YMM, and ZMM
> registers, but more recent consumer and small-server CPUs have
> reverted to only supporting XMM and YMM registers.
> 
> - anton