News for hackers. Stuff that matters.

A comment on The prospects for 128 bit processors (1995).

Re:The prospects for 128 bit processors (1995) by EdSchouten on Wednesday February 23, 2022 @05:34PM (#30447507)
Relatedly, I hope we ever get CPUs where pointers are bit addressed. I’m not suggesting they should allow byte level access at arbitrary alignments. I just mean that the smallest addressable unit is a bit.

That would allow us to finally declare lists of booleans without needing any specialization or losing the possibility of referencing elements.

[ Parent | on HN ]
Re:The prospects for 128 bit processors (1995) by gumby on Wednesday February 23, 2022 @06:08PM (#30447921)
> Relatedly, I hope we ever get CPUs where pointers are bit addressed.

You mean like the famous PDP-6 from 1964? The width of a byte was variable and could be as small as 1: http://pdp10.nocrew.org/docs/instruction-set/Byte.html

(That's the PDP-10 instruction set documentation, but the PDP-6's instruction set was essentially identical).

I never wrote PDP-6 code but wrote a lot of PDP-10 code and the byte instructions were used heavily. In particular characters were commonly six or seven bits wide so string manipulation used byte pointers and was quite fast, but they were also good for packed arrays of all sorts of sizes.

[ Parent | on HN ]
Re:The prospects for 128 bit processors (1995) by esmIII on Wednesday February 23, 2022 @05:43PM (#30447625)
Some ARM cortex-m chips have a feature where you can address individual bits. https://developer.arm.com/documentation/ddi0439/b/Programmer...
[ Parent | on HN ]
Re:The prospects for 128 bit processors (1995) by flohofwoe on Wednesday February 23, 2022 @05:54PM (#30447752)
This would also go nicely with arbitrary-width integers. Load/store instructions would just need to set aside a few opcode bits to define the number of bits to load or store, and pointers would just get 3 bits wider (basically left-shifted 3 bits, the upper bits in a 64-bit pointer are not used anyway). Pointer alignment could be the same as the bit width, e.g. 2-bit load/store could require 2-bit alignment, byte load/store byte alignment, and so forth...
[ Parent | on HN ]
Re:The prospects for 128 bit processors (1995) by KerrAvon on Thursday February 24, 2022 @10:46PM (#30463501)
https://en.wikipedia.org/wiki/IBM_7030_Stretch

> Bytes are variable length (1 to 8 bits).[17]

[ Parent | on HN ]
Re:The prospects for 128 bit processors (1995) by convolvatron on Wednesday February 23, 2022 @06:51PM (#30448384)
the CM-1 and the CM-2 were bit addressed. I _loved_ that part of it, and I don't even understand why

edit: I hadn't started doing systems programming yet, but now that I am I would like it even more

[ Parent | on HN ]
Re:The prospects for 128 bit processors (1995) by jecel on Thursday February 24, 2022 @09:55AM (#30455398)
Here is a commercial bit addressed processor:

https://en.wikipedia.org/wiki/TMS34010

[ Parent | on HN ]
Re:The prospects for 128 bit processors (1995) by cwp on Wednesday February 23, 2022 @06:18PM (#30448036)
Funny, I've had the opposite thought. If registers are a certain width, and all memory access is aligned anyway, why do we need pointers that can address arbitrary bytes? Heck, why are bytes even a thing in a 64-bit machine?
[ Parent | on HN ]
Re:The prospects for 128 bit processors (1995) by kens on Wednesday February 23, 2022 @07:11PM (#30448582)
Having done some network code on the 16-bit Xerox Alto, it's a big pain if you can't access bytes directly. If you want to deal with characters, you need to do shifts and AND operations, depending if you want the odd byte or the even byte. It's very annoying.
[ Parent | on HN ]
Re:The prospects for 128 bit processors (1995) by akvadrako on Thursday February 24, 2022 @04:56AM (#30452903)
Do you mean characters as in real languages? Because then bytes don't matter, but codepoints, which can be any length.

Obviously dealing with legacy formats that are bit or byte aligned should still be supported using char arrays, it just would require compiler assistance for pointers.

[ Parent | on HN ]
Re:The prospects for 128 bit processors (1995) by phkahler on Thursday February 24, 2022 @03:45AM (#30452376)
Well let's just switch to 32bit unicode characters and drop all this UTF8 stuff. But even then we would addressing 32 bit words with a 64bit machine.
[ Parent | on HN ]
Re:The prospects for 128 bit processors (1995) by convolvatron on Wednesday February 23, 2022 @07:02PM (#30448499)
I don't know if you lived through the early RISC days, but it was really a bit of a bother when dealing with things that weren't words. but sure, its wasn't that bad. I just get really tired of all the shift and mask stuff...seems like we should be able to do better. I guess you could paper over it with sufficient language/runtime support
[ Parent | on HN ]
Re:The prospects for 128 bit processors (1995) by NavinF on Thursday February 24, 2022 @01:59AM (#30451504)
It's really convenient to pass around pointers to a single GPIO pin on embedded systems that have a special region of memory where each byte corresponds to one pin rather than the usual 8. Atomic access to bits would also be convenient.
[ Parent | on HN ]
Re:The prospects for 128 bit processors (1995) by mishafb on Thursday February 24, 2022 @05:43AM (#30453221)
We have atomic bitwise operations already (look at glibc's mutex implementation), and the unit atomic operations work on is a 64-byte cache line. Cache lines are useful because reading 64 bytes isn't really more expensive but it improves sequential memory access by a lot.
[ Parent | on HN ]