5 ms·

C and C++ also use 8 bits in most cases. One reason is to support pointers, ie `bool *`. You can get a single-bit bools in a C++ struct, with eg struct foo

by tlb 2y ago

C and C++ also use 8 bits in most cases. One reason is to support pointers, ie `bool *`. You can get a single-bit bools in a C++ struct, with eg struct foo { bool a:1; bool b:1; ... } but you can't take a pointer to such a member.

PaulHoule 2y ago
The old PDP-10 had 36-bit words but you could write pointers to any range of bits inside a word. On that machine you could write a pointer to a single bit. I was thinking about a fantasy computer that could run under JavaScript and have 48 bit words (fit in a double) and pointers like the PDP-10 but that could hang off one word into the next word. [1] First I was thinking “screw C” but came to the conclusion that supporting C would not be so hard after all with that kind of pointer. [1] Think of a Chinese home computer from an alternate timeline where a strange mainframe had a baby with a NeoGeo arcade machine.
unwind 2y ago
Just for completeness' sake: bit fields are a feature in plain old C too, and the syntax is the same [1]. Their most "obnoxious" feature is that the layout is implementation defined, so they are not very portable between compilers and/or architectures. Often used in an embedded setting to model hardware registers, when you can know/control what compiler implementation is used. [1]: https://en.wikipedia.org/wiki/Bit_field#C_programming_language https://en.wikipedia.org/wiki/Bit_field#C_programming_langua... Edit: more with the words.
- mmaniac 2y ago
  Isn't struct layout in C implementation defined in general? C itself doesn't specify any ABI. A given platform simply uses one as a matter of convention.
  - unwind 2y ago
    No, it's quite well-defined as far as I know. Fields must be packed in the order they are declared, and be suitably aligned, basically.
    - mmaniac 2y ago
      Time to put my language lawyering cap on. C99 §6.7.2.1.13 > Within a structure object, the non-bit-field members and the units in which bit-fields reside have addresses that increase in the order in which they are declared. A pointer to a structure object, suitably converted, points to its initial member (or if that member is a bit-field, then to the unit in which it resides), and vice versa. There may be unnamed padding within a structure object, but not at its beginning C99 §6.7.2.1.13 > An implementation may allocate any addressable storage unit large enough to hold a bit-field. If enough space remains, a bit-field that immediately follows another bit-field in a structure shall be packed into adjacent bits of the same unit. If insufficient space remains, whether a bit-field that does not fit is put into the next unit or overlaps adjacent units is implementation-defined. The order of allocation of bit-fields within a unit (high-order to low-order or low-order to high-order) is implementation-defined. The alignment of the addressable storage unit is unspecified. Which is standardese for pretty much exactly everything you said :) The consequence of the first rule is that there's only one sane way to lay out structs. The only way to break that rule which I can imagine would be to add extra padding - you can't swap the order of any members under these rules.
rcxdude 2y ago
See also why the specialisation implementation of vector<bool> (which uses a packed internal representation) is widely considered a mistake.
kevincox 2y ago
In theory you could use 3 extra bits for a bit pointer. Although the fact that a void* could hold it (or you need to make void* larger) would likely be an issue. The funny thing is that there are much more than 3 wasted bits on 64 bit pointers anyways. So we could just use bit pointers. Of course this has costs in the hardware.
- PaulHoule 2y ago
  For a long time I've thought about various sorts of weird pointer organization (think of the compressed pointers used in modern JVMs or "tiny pointers" [1] or 8086 code that uses a 16-byte aligned segment pointer to point to a struct or array and uses and ordinary pointer to point to things inside that structure) It doesn't seem too weird to me to make some kind of composite pointer that is a pointer plus some extra stuff. I've done some design work for a fantasy computer that has - 48-bit words (fills up most of a Javascript double) - 24-bit pointers (point to a 96 Mbyte address space) - a "deep" extension that adds 6 bits to point to a starting bit and a 6 bit length field for an up to a 48 bit long extent -- extravagantly and maybe unrealistic for hardware these could extend into the next word. A zero length deep bit pointer could point to a UTF-8 character inside a word and there would be a load instruction that unpacks the next codepoint [2] - a "wide" extension of 6 bits that points to one of 64 "address spaces" which are the unit of virtual memory management and could be contiguous to emulate a big address space bigger than 4GB with some room left for I/O spaces, video ram, etc. - you're still left with 6 bits of "tag" to fill out a 48 bit word used for something defined by the OS or application The backstory is that something like the IBM 360 had a baby with the PDP-10, had the word size doubled to get to VAX/370 XA size then had a baby with the Neo Geo arcade console to make a "home computer" that supports single/double width Unicode text. There would be extra points for there being a 24-bit instruction subset built in. [1] https://arxiv.org/abs/2111.12800 https://arxiv.org/abs/2111.12800 [2] ... wouldn't it be nice to find a use for the illegal offset+length combinations?
  - kevincox 2y ago
    This isn't an outlandish idea. For example V8 has "pointer compression" https://v8.dev/blog/pointer-compression/ https://v8.dev/blog/pointer-compression/. This is basically just 32-bit pointers with a know base offset. They still point at bytes (but known alignment is used for tag bits, so they don't really point at bytes, but more some VM-defined word)

by tlb 2y ago

PaulHoule 2y ago

The old PDP-10 had 36-bit words but you could write pointers to any range of bits inside a word. On that machine you could write a pointer to a single bit. I was thinking about a fantasy computer that could run under JavaScript and have 48 bit words (fit in a double) and pointers like the PDP-10 but that could hang off one word into the next word. [1] First I was thinking “screw C” but came to the conclusion that supporting C would not be so hard after all with that kind of pointer. [1] Think of a Chinese home computer from an alternate timeline where a strange mainframe had a baby with a NeoGeo arcade machine.

unwind 2y ago

Just for completeness' sake: bit fields are a feature in plain old C too, and the syntax is the same [1]. Their most "obnoxious" feature is that the layout is implementation defined, so they are not very portable between compilers and/or architectures. Often used in an embedded setting to model hardware registers, when you can know/control what compiler implementation is used. [1]: https://en.wikipedia.org/wiki/Bit_field#C_programming_language https://en.wikipedia.org/wiki/Bit_field#C_programming_langua... Edit: more with the words.

mmaniac 2y ago
Isn't struct layout in C implementation defined in general? C itself doesn't specify any ABI. A given platform simply uses one as a matter of convention.
- unwind 2y ago
  No, it's quite well-defined as far as I know. Fields must be packed in the order they are declared, and be suitably aligned, basically.
  - mmaniac 2y ago
    Time to put my language lawyering cap on. C99 §6.7.2.1.13 > Within a structure object, the non-bit-field members and the units in which bit-fields reside have addresses that increase in the order in which they are declared. A pointer to a structure object, suitably converted, points to its initial member (or if that member is a bit-field, then to the unit in which it resides), and vice versa. There may be unnamed padding within a structure object, but not at its beginning C99 §6.7.2.1.13 > An implementation may allocate any addressable storage unit large enough to hold a bit-field. If enough space remains, a bit-field that immediately follows another bit-field in a structure shall be packed into adjacent bits of the same unit. If insufficient space remains, whether a bit-field that does not fit is put into the next unit or overlaps adjacent units is implementation-defined. The order of allocation of bit-fields within a unit (high-order to low-order or low-order to high-order) is implementation-defined. The alignment of the addressable storage unit is unspecified. Which is standardese for pretty much exactly everything you said :) The consequence of the first rule is that there's only one sane way to lay out structs. The only way to break that rule which I can imagine would be to add extra padding - you can't swap the order of any members under these rules.

rcxdude 2y ago

See also why the specialisation implementation of vector<bool> (which uses a packed internal representation) is widely considered a mistake.

kevincox 2y ago

In theory you could use 3 extra bits for a bit pointer. Although the fact that a void* could hold it (or you need to make void* larger) would likely be an issue. The funny thing is that there are much more than 3 wasted bits on 64 bit pointers anyways. So we could just use bit pointers. Of course this has costs in the hardware.

PaulHoule 2y ago
For a long time I've thought about various sorts of weird pointer organization (think of the compressed pointers used in modern JVMs or "tiny pointers" [1] or 8086 code that uses a 16-byte aligned segment pointer to point to a struct or array and uses and ordinary pointer to point to things inside that structure) It doesn't seem too weird to me to make some kind of composite pointer that is a pointer plus some extra stuff. I've done some design work for a fantasy computer that has - 48-bit words (fills up most of a Javascript double) - 24-bit pointers (point to a 96 Mbyte address space) - a "deep" extension that adds 6 bits to point to a starting bit and a 6 bit length field for an up to a 48 bit long extent -- extravagantly and maybe unrealistic for hardware these could extend into the next word. A zero length deep bit pointer could point to a UTF-8 character inside a word and there would be a load instruction that unpacks the next codepoint [2] - a "wide" extension of 6 bits that points to one of 64 "address spaces" which are the unit of virtual memory management and could be contiguous to emulate a big address space bigger than 4GB with some room left for I/O spaces, video ram, etc. - you're still left with 6 bits of "tag" to fill out a 48 bit word used for something defined by the OS or application The backstory is that something like the IBM 360 had a baby with the PDP-10, had the word size doubled to get to VAX/370 XA size then had a baby with the Neo Geo arcade console to make a "home computer" that supports single/double width Unicode text. There would be extra points for there being a 24-bit instruction subset built in. [1] https://arxiv.org/abs/2111.12800 https://arxiv.org/abs/2111.12800 [2] ... wouldn't it be nice to find a use for the illegal offset+length combinations?
- kevincox 2y ago
  This isn't an outlandish idea. For example V8 has "pointer compression" https://v8.dev/blog/pointer-compression/ https://v8.dev/blog/pointer-compression/. This is basically just 32-bit pointers with a know base offset. They still point at bytes (but known alignment is used for tag bits, so they don't really point at bytes, but more some VM-defined word)