Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #164673
| From | Bart <bc@freeuk.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Here come the 128-bit pointers |
| Date | 2022-01-27 12:11 +0000 |
| Organization | A noiseless patient Spider |
| Message-ID | <ssu24p$941$1@dont-email.me> (permalink) |
| References | (3 earlier) <sspgoj$s5l$1@dont-email.me> <ssprrc$d8h$1@dont-email.me> <ssr1jb$nqj$1@dont-email.me> <sssabd$625$1@dont-email.me> <ssseqb$717$1@dont-email.me> |
On 26/01/2022 21:35, BGB wrote:
> On 1/26/2022 2:18 PM, Bart wrote:
>> On 26/01/2022 08:43, Bonita Montero wrote:
>>> I don't see any sense in logical or physical 128 bit pointers.
>>> Imagine that memory-density could be shrinked up to 100 times,
>>> so computers could be equipped with much more memory. But it
>>> would be impossible have tolerable access-times with an amount
>>> of memory in the upper margin of 64 bit (that's 16 billion
>>> gigabytes).
>>> So the only usage for me would be a larger address space to
>>> accomodate larger memory-mapped files. But memory-mapped files
>>> are slow anyway as they don't allow pipelined transfers from
>>> the disk (except asynchronous read-ahead). An access-facility
>>> like in a database-system which issues pipelined asynchronous
>>> operations is much more efficient.
>>> And have a look at the filesystems: although ZFS data-layout
>>> allows 128 bit filesystems, its current implementation is
>>> limited to 64 bit.
>>
>> How often are you going to be working with a single file more than
>> 2**64 bytes in size? (Equivalent to 16 million 1TB drives I think.)
>>
>> Or perhaps you want to be able memory-map every file on every computer
>> in the world at the same time?
>>
>
> I expect such large mmaps to be exceedingly unlikely.
>
>
>> The various plans for 128 bits anyway don't appear to give that kind
>> of addressability. While those uses are so niche that a software
>> solution will work perfectly well. Bear in mind that fetching any data
>> from a file will be bigger overhead than having to use two 64-bit
>> registers to emulate such a pointer.
>>
>> I think the chip makers are just desperately trying to find more uses
>> for wider GP registers.
>
> Could be.
>
>
> My preference (in my ISA) had been to use register pairs.
>
>
> Handling 128-bit data as fixed pairs has both some of the same features
> as having separate registers (such as not having much of the register
> space being "wasted" for narrower values), but in other cases pairs can
> be treated by the hardware (and ISA) as if they were a single larger
> register (without as much cost and complexity as would be associated
> with using separately addressable register pairs).
>
> So, for example: R3:R2, R5:R4, and R7:R6 can be treated as a 128-bit
> register, wheres, say: R6:R5 or R7:R2 or similar cannot...
I've seen this approach in a few processors. I first came across it on
Z8000 I think, where the 16 x 16-bit registers R0..15 can also be
accessed as:
16 x 8-bit registers (over R0..7 only)
8 x 32-bit registers (as RR0 RR2 .. RR14)
4 x 64-bit registers (as RQ0 RQ4 RQ8 RQ12)
(So 64-bit registers 40 years ago! Although probably there were
limitations on what could be done with such a type)
Like yours, the wider registers couldn't overlap, as in R6:R7 and R7:R8.
Such a scheme for 128 bits wouldn't be objectionable. Actually it would
be useful the other way too: C is still primarily 32 bits, but you can't
conveniently use one 64-bit register to hold two independent 32-bit values.
>
>
> Though, going the other way and trying to, say, allows for 128x 32-bit
> registers or similar, would have its own issues (doesn't make sense from
> a cost/benefit POV).
I actually use quite a few 128-bit types (actual 128-bit ints, and
composite ones like slices and variants).
These are expressed using a virtual 128-bit type in my IL, but are
implemented as two 64-bit registers on x64, not necessarily consecutive.
(Sometimes, half of it can be on the stack!)
The funny thing is that x64 /has/ 128-bit registers (xmm0 etc), but not
in a form that I found useful for my purposes.
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Here come the 128-bit pointers scott@slp53.sl.home (Scott Lurndal) - 2022-01-24 18:12 +0000
Re: Here come the 128-bit pointers Dan Purgert <dan@djph.net> - 2022-01-24 18:31 +0000
Re: Here come the 128-bit pointers BGB <cr88192@gmail.com> - 2022-01-24 15:41 -0600
Re: Here come the 128-bit pointers Bonita Montero <Bonita.Montero@gmail.com> - 2022-01-25 08:25 +0100
Re: Here come the 128-bit pointers BGB <cr88192@gmail.com> - 2022-01-25 02:31 -0600
Re: Here come the 128-bit pointers Öö Tiib <ootiib@hot.ee> - 2022-01-25 02:04 -0800
Re: Here come the 128-bit pointers scott@slp53.sl.home (Scott Lurndal) - 2022-01-25 14:48 +0000
Re: Here come the 128-bit pointers BGB <cr88192@gmail.com> - 2022-01-25 11:54 -0600
Re: Here come the 128-bit pointers scott@slp53.sl.home (Scott Lurndal) - 2022-01-25 18:23 +0000
Re: Here come the 128-bit pointers BGB <cr88192@gmail.com> - 2022-01-25 14:17 -0600
Re: Here come the 128-bit pointers David Brown <david.brown@hesbynett.no> - 2022-01-26 09:36 +0100
Re: Here come the 128-bit pointers Theo <theom+news@chiark.greenend.org.uk> - 2022-01-28 22:12 +0000
Re: Here come the 128-bit pointers Bonita Montero <Bonita.Montero@gmail.com> - 2022-01-25 19:49 +0100
Re: Here come the 128-bit pointers BGB <cr88192@gmail.com> - 2022-01-25 15:59 -0600
Re: Here come the 128-bit pointers scott@slp53.sl.home (Scott Lurndal) - 2022-01-25 22:25 +0000
Re: Here come the 128-bit pointers Bonita Montero <Bonita.Montero@gmail.com> - 2022-01-26 09:43 +0100
Re: Here come the 128-bit pointers scott@slp53.sl.home (Scott Lurndal) - 2022-01-26 15:53 +0000
Re: Here come the 128-bit pointers Bonita Montero <Bonita.Montero@gmail.com> - 2022-01-26 17:25 +0100
Re: Here come the 128-bit pointers Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-01-26 08:34 -0800
Re: Here come the 128-bit pointers Bonita Montero <Bonita.Montero@gmail.com> - 2022-01-26 17:57 +0100
Re: Here come the 128-bit pointers Bart <bc@freeuk.com> - 2022-01-26 17:10 +0000
Re: Here come the 128-bit pointers scott@slp53.sl.home (Scott Lurndal) - 2022-01-26 17:27 +0000
Re: Here come the 128-bit pointers Bart <bc@freeuk.com> - 2022-01-26 17:41 +0000
Re: Here come the 128-bit pointers scott@slp53.sl.home (Scott Lurndal) - 2022-01-26 18:05 +0000
Re: Here come the 128-bit pointers Bart <bc@freeuk.com> - 2022-01-26 18:23 +0000
Re: Here come the 128-bit pointers BGB <cr88192@gmail.com> - 2022-01-26 14:42 -0600
Re: Here come the 128-bit pointers BGB <cr88192@gmail.com> - 2022-01-26 14:30 -0600
Re: Here come the 128-bit pointers Mateusz Viste <mateusz@xyz.invalid> - 2022-01-26 19:36 +0100
Re: Here come the 128-bit pointers scott@slp53.sl.home (Scott Lurndal) - 2022-01-26 18:52 +0000
Re: Here come the 128-bit pointers tth <tth@none.invalid> - 2022-01-26 21:01 +0100
Re: Here come the 128-bit pointers Bart <bc@freeuk.com> - 2022-01-26 20:18 +0000
Re: Here come the 128-bit pointers BGB <cr88192@gmail.com> - 2022-01-26 15:35 -0600
Re: Here come the 128-bit pointers scott@slp53.sl.home (Scott Lurndal) - 2022-01-26 21:50 +0000
Re: Here come the 128-bit pointers BGB <cr88192@gmail.com> - 2022-01-26 20:34 -0600
Re: Here come the 128-bit pointers Bart <bc@freeuk.com> - 2022-01-27 12:11 +0000
Re: Here come the 128-bit pointers BGB <cr88192@gmail.com> - 2022-01-27 13:40 -0600
Re: Here come the 128-bit pointers William Ahern <william@25thandClement.com> - 2022-01-27 13:28 -0800
Re: Here come the 128-bit pointers Theo Markettos <theom+news@chiark.greenend.org.uk> - 2022-01-28 23:18 +0000
csiph-web