Path: ...!weretis.net!feeder9.news.weretis.net!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: Address space limits
Date: Sun, 5 May 2024 22:25:46 +0000
Organization: Rocksolid Light
Message-ID: <bee5c0c86431e8e6081b092490c70b95@www.novabbs.org>
References: <v0s17o$2okf4$2@dont-email.me> <62dff0b888855a31ec10c0597669423f@www.novabbs.org> <v0soai$30rmc$3@dont-email.me> <f2ac45ffe1718a0b0070f027f0e5f58c@www.novabbs.org> <20240501225652.00002853@yahoo.com> <jwvh6fhnuzu.fsf-monnier+comp.arch@gnu.org> <v0uppp$3fitf$2@dont-email.me> <v1521l$15g68$1@dont-email.me> <v16b3u$1dm6l$2@dont-email.me> <9e81a0aa95b5eae7ae6fc9f99455df97@www.novabbs.org> <v16u6q$1lbg7$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="200530"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="65wTazMNTleAJDh/pRqmKE7ADni/0wesT78+pyiDW8A";
User-Agent: Rocksolid Light
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Site: $2y$10$wIzm2RdAfc8gLfvQymp/EeV16G4ycZdtzHv4B84kInHUns.ndmfqm
X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
Bytes: 3147
Lines: 39

Chris M. Thomasson wrote:

> On 5/4/2024 5:12 PM, MitchAlsup1 wrote:
>> Chris M. Thomasson wrote:
>> 
>>> On 5/4/2024 3:18 AM, Thomas Koenig wrote:
>>>> Lawrence D'Oliveiro <ldo@nz.invalid> schrieb:
>>>>
>>>>> Intel pushed this thing called the “x32” ABI into the Linux kernel
>> (and
>>>>> possibly some other places) some years ago. This was using the AMD64
>>>>> instruction set, but with only 32-bit pointers. This way, you got the
>>>>> benefit of the extra registers, without the overhead of the longer
>>>>> addresses.
>>>>
>>>> That was Donald Knuth's idea.
>> 
>>> Storing meta data in actual pointers, aka aligned on a larger 
>>> boundary, is critical to many advanced lock/wait free algorithms as 
>>> well. I remember storing an actual reference count in pointers before 
>>> for a special type of counting.
>> 
>> Even if one has multi-location ATOMICs ?? (as a single event ??)

> This was a technique for storing data in a pointer. For instance, strong 
> atomic reference counting we need to update a pointer _and_ a reference 
> together atomically. This can easily be done with DWCAS, or double width 
> compare and swap. So, on a 32 bit system we need 64 bit cas, for a 64 
> bit system we need 128 bit cas. However, sometimes we can pack the 
> reference count in the pointer value itself if its aligned on a big 
> enough boundary. Then we can update the pointer and the reference count 
> using normal word based atomic RMW's.

I understand why you had to pack the pointer and a chunk of data into a
single container.

What I don't understand is if you had easy access to multi-container ATOMICs
the packing would be unnecessary--would it not ?? That is in one ATOMIC event
you could update the pointer and the chunk of data independently and not NEED
to store them in a single container.