Hacker News Reader

Comment by EdSchouten | Hacker News Reader

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.

View on HN

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

Some ARM cortex-m chips have a feature where you can address individual bits. https://developer.arm.com/documentation/ddi0439/b/Programmer...

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

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

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

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

Here is a commercial bit addressed processor:

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

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?

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

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.

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.

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.

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.

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.

Reply on news.ycombinator.com