4 ms·

It's easy with hindsight, but there must have been people back then who foresaw that power-of-two machine words are almost as necessity as you scale up (8 -> 16

It's easy with hindsight, but there must have been people back then who foresaw that power-of-two machine words are almost as necessity as you scale up (8 -> 16 -> 32 -> 64 bits).

jameshart 4y ago
But that’s building off ‘8’ as the starting unit. I can definitely imagine a counterfactual where 12bit bytes became the basic building block. Imagine if early text encoding had assumed that more than the Latin alphabet would be useful (say if standards had been being set by Japanese companies rather than American ones?) - an early maybe 10bit text standard would have weighed towards 12bit bytes being more useful. 12bit bytes also work great for encoding RGB values for video - and RGBA for image processing. The importance of having a power-of-two bits might just not be that big a deal held up against all those upsides. After all, when do you really care about how many bits it takes to store an index into a byte, or a word, anyway? The << and >> bitshift operators even on a 64bit number are only using 6 bits of their operand, so even on an 8-bit-centric architecture you’re not realizing any great synergy with the powers of two. Is it so hard to imagine instead a 12-bit era, followed by a 24-bit revolution, and maybe now we’d be talking about the end of 48-bit systems as the 96-bit processors start coming to market?
- nine_k 4y ago
  Historically, there were a number of 24-bit, 36-bit, and 48-bit CPU designs; some modern DSPs still have 24-bit ALUs, IIRC. Interestingly, all these numbers divide cleanly by 8, except for 36. I never heard about 12-bit CPUs though. Where octal representation shone was 3-bit fields in some CPU code, especially in the venerable PDP-11. Using octal representation for them was the only sane way. Coincidentally, much of the UNIX was built on various PDP machines. Also, early TTYs, that is, actual mechanical teletypes, were often 6-bit, which also sits well with octal encoding.
  - jameshart 4y ago
    > I never heard about 12-bit CPUs though. The original article points to the DEC PDP-8. That 12-bit architecture, which built on the PDP-5, also 12-bit, wound up in microprocessor form in the Intersil 6100, and DEC actually tried to build a desktop microcomputer based on that chip - the DECmate (https://en.wikipedia.org/wiki/DECmate https://en.wikipedia.org/wiki/DECmate). The 16-bit PDP-11 was literally the result of typical DEC indecision, infighting and hedging in the face of increasing importance of ASCII processing (and ultimately a response to a bunch of their engineers who had seen that writing on the wall leaving and founding Data General). Like so many things in computer history, if DEC had had its shit together, things would have worked out very differently.
- codeflo 4y ago
  > I can definitely imagine a counterfactual where 12bit bytes became the basic building block. It's definitely fun to imagine. I personally have a soft spot for a hypothetical ternary architectures, where the "trits" are either -1, 0 or 1. There's a mathematical elegance to that number system that binary can't match. > 12bit bytes also work great for encoding RGB values for video Can you elaborate, do you mean historically? The more bits the better, of course -- I get why 12 are better than 8, but it's not clear to me why you would want to stop at 12 bits. And if you don't stop there, what's the advantage? > The << and >> bitshift operators even on a 64bit number are only using 6 bits of their operand, so even on an 8-bit-centric architecture you’re not realizing any great synergy with the powers of two. 6 bits is still cleaner than the 6.58 bits required to encode shifts for this hypothetical 96-bit architecture, just use the lowest 6 address lines. And in general I think there are more places where stuff like this comes up than is apparent at first glance. How many bytes in a page? How many pages in a RAM chip? How many address lines and data lines? In the current era, RAM chips are agnostic about word size (as long as it's a power of two) because what they actually address are these much larger pages that chips can cut up in any way they want. Perhaps if everything standardized to 12 bits as the base at once, you could solve that or find workarounds, but I think would be mathematically tedious at every turn. It's so easy to just chop off a few bits and not worry about it.
  - jameshart 4y ago
    To elaborate on “12bit bytes also work great for encoding RGB values for video”: I just mean that it’s easy to encode an RGB value as three four-bit values in a 12-bit number. Aligning ‘memory addresses’ to ‘pixels’ would simplify video hardware. Historically, 4096-color modes based on 12-bits-per-pixel were used (notably on the Amiga), in spite of byte-alignment issues. And of course 24-bit pixels would map to the common 16m colors we all know and love. 8, 16 and 32 bit architectures have always had compromises of one sort or another for storing three color channels - I half feel like the ubiquity of ARGB in modern graphics is down to our finally accepting that storage and memory are now cheap enough we should stop worrying about waste, pad out pixels with another channel, and just find a use for it. Transparency? Sure, why not. Regarding how RAM is laid out… a lot of early computers used ram chips striped by bit - so they’d have eight ram chips all wired to the same address bus, with each responsible for storing one data line for each address. Twelve bit memory is just laying four more data lines and adding four more chips. In my hypothetical counterfactual universe, obviously if 12 bit bytes win, later memory architectures are built around 12/24/48/96 bit data buses, so whatever paging and slicing they do would be within that model.
- digitailor 4y ago
  This is exactly what happened in digital audio signal processing and recording, where word size represents amplitude. 12-bit audio was the first word size that provided a pretty good noise floor by the late 1980s, a real improvement over 8-bit. And by the mid-80s the CD format was already providing 16-bits for playback, which really is good enough for most playback scenarios. The 16-bit DSP era was just a few years longer than the 12-bit and quickly gave way to 24-bit, which provides a noise floor good enough for almost anything audio processing and recording related and is still the standard after more than 20 years. I have gear that defaults to 32-bit now, obviously just for power-of-2 convenience in software dev, which is annoying because the file sizes are bigger for basically no reason. (The master buses in DAWs and digital hardware use even larger word lengths these days, but it's not really the same thing, that's a summing and calculation process)
- Dylan16807 4y ago
  > maybe now we’d be talking about the end of 48-bit systems as the 96-bit processors start coming to market? Notably, all our CPUs have had 48-bit memory addresses since the introduction of 64 bit chips, and chips that bump up to 57 are in the middle of being introduced. But in part they're bumping that up because it's easy. The 48 bit mode was an optimization, and they left room. With 48 bits as a hard limit of what fits into a register, and that representing 256 terabytes / 384 tera-octets of memory, I suspect we would stick with 48 bits for many more years.
  - zamadatix 4y ago
    Notably x86-64 canonical form uses the full 64 bit address when referring to memory and that's what's in the registers it just doesn't handle addresses in the middle of all places (i.e. it counts addresses in two halves, one half from FFFF... down and one half from 0000... up, not just the first 48 bits of addresses).
    - Dylan16807 4y ago
      I'd say it does use just the first 48 bits, but in a sign-extended way. You could sign-extend to any size you want, even beyond 64 bits. And it forces the program to do the sign extension, so it'll be forwards-compatible with chips that use more bits. But once those bits are verified they get immediately discarded.
      - zamadatix 4y ago
        The method would scale to any number of bits but the actual registers and addresses passed to the MMU really are 64 bit in real processors, as in you can actually set it to some other non-sign extended 48 bit value with your program today and you’ll just get an MMU exception when you go to use it. After all the CPU doesn’t know something in a register is to be treated as a memory address until after the value is already loaded into the register. The advantage of 48 but addressing in x86-64 is fewer levels of page lookups (speed up), not abbreviated addresses.

It's easy with hindsight, but there must have been people back then who foresaw that power-of-two machine words are almost as necessity as you scale up (8 -> 16 -> 32 -> 64 bits).

jameshart 4y ago

But that’s building off ‘8’ as the starting unit. I can definitely imagine a counterfactual where 12bit bytes became the basic building block. Imagine if early text encoding had assumed that more than the Latin alphabet would be useful (say if standards had been being set by Japanese companies rather than American ones?) - an early maybe 10bit text standard would have weighed towards 12bit bytes being more useful. 12bit bytes also work great for encoding RGB values for video - and RGBA for image processing. The importance of having a power-of-two bits might just not be that big a deal held up against all those upsides. After all, when do you really care about how many bits it takes to store an index into a byte, or a word, anyway? The << and >> bitshift operators even on a 64bit number are only using 6 bits of their operand, so even on an 8-bit-centric architecture you’re not realizing any great synergy with the powers of two. Is it so hard to imagine instead a 12-bit era, followed by a 24-bit revolution, and maybe now we’d be talking about the end of 48-bit systems as the 96-bit processors start coming to market?

nine_k 4y ago
Historically, there were a number of 24-bit, 36-bit, and 48-bit CPU designs; some modern DSPs still have 24-bit ALUs, IIRC. Interestingly, all these numbers divide cleanly by 8, except for 36. I never heard about 12-bit CPUs though. Where octal representation shone was 3-bit fields in some CPU code, especially in the venerable PDP-11. Using octal representation for them was the only sane way. Coincidentally, much of the UNIX was built on various PDP machines. Also, early TTYs, that is, actual mechanical teletypes, were often 6-bit, which also sits well with octal encoding.
- jameshart 4y ago
  > I never heard about 12-bit CPUs though. The original article points to the DEC PDP-8. That 12-bit architecture, which built on the PDP-5, also 12-bit, wound up in microprocessor form in the Intersil 6100, and DEC actually tried to build a desktop microcomputer based on that chip - the DECmate (https://en.wikipedia.org/wiki/DECmate https://en.wikipedia.org/wiki/DECmate). The 16-bit PDP-11 was literally the result of typical DEC indecision, infighting and hedging in the face of increasing importance of ASCII processing (and ultimately a response to a bunch of their engineers who had seen that writing on the wall leaving and founding Data General). Like so many things in computer history, if DEC had had its shit together, things would have worked out very differently.
codeflo 4y ago
> I can definitely imagine a counterfactual where 12bit bytes became the basic building block. It's definitely fun to imagine. I personally have a soft spot for a hypothetical ternary architectures, where the "trits" are either -1, 0 or 1. There's a mathematical elegance to that number system that binary can't match. > 12bit bytes also work great for encoding RGB values for video Can you elaborate, do you mean historically? The more bits the better, of course -- I get why 12 are better than 8, but it's not clear to me why you would want to stop at 12 bits. And if you don't stop there, what's the advantage? > The << and >> bitshift operators even on a 64bit number are only using 6 bits of their operand, so even on an 8-bit-centric architecture you’re not realizing any great synergy with the powers of two. 6 bits is still cleaner than the 6.58 bits required to encode shifts for this hypothetical 96-bit architecture, just use the lowest 6 address lines. And in general I think there are more places where stuff like this comes up than is apparent at first glance. How many bytes in a page? How many pages in a RAM chip? How many address lines and data lines? In the current era, RAM chips are agnostic about word size (as long as it's a power of two) because what they actually address are these much larger pages that chips can cut up in any way they want. Perhaps if everything standardized to 12 bits as the base at once, you could solve that or find workarounds, but I think would be mathematically tedious at every turn. It's so easy to just chop off a few bits and not worry about it.
- jameshart 4y ago
  To elaborate on “12bit bytes also work great for encoding RGB values for video”: I just mean that it’s easy to encode an RGB value as three four-bit values in a 12-bit number. Aligning ‘memory addresses’ to ‘pixels’ would simplify video hardware. Historically, 4096-color modes based on 12-bits-per-pixel were used (notably on the Amiga), in spite of byte-alignment issues. And of course 24-bit pixels would map to the common 16m colors we all know and love. 8, 16 and 32 bit architectures have always had compromises of one sort or another for storing three color channels - I half feel like the ubiquity of ARGB in modern graphics is down to our finally accepting that storage and memory are now cheap enough we should stop worrying about waste, pad out pixels with another channel, and just find a use for it. Transparency? Sure, why not. Regarding how RAM is laid out… a lot of early computers used ram chips striped by bit - so they’d have eight ram chips all wired to the same address bus, with each responsible for storing one data line for each address. Twelve bit memory is just laying four more data lines and adding four more chips. In my hypothetical counterfactual universe, obviously if 12 bit bytes win, later memory architectures are built around 12/24/48/96 bit data buses, so whatever paging and slicing they do would be within that model.
digitailor 4y ago
This is exactly what happened in digital audio signal processing and recording, where word size represents amplitude. 12-bit audio was the first word size that provided a pretty good noise floor by the late 1980s, a real improvement over 8-bit. And by the mid-80s the CD format was already providing 16-bits for playback, which really is good enough for most playback scenarios. The 16-bit DSP era was just a few years longer than the 12-bit and quickly gave way to 24-bit, which provides a noise floor good enough for almost anything audio processing and recording related and is still the standard after more than 20 years. I have gear that defaults to 32-bit now, obviously just for power-of-2 convenience in software dev, which is annoying because the file sizes are bigger for basically no reason. (The master buses in DAWs and digital hardware use even larger word lengths these days, but it's not really the same thing, that's a summing and calculation process)
Dylan16807 4y ago
> maybe now we’d be talking about the end of 48-bit systems as the 96-bit processors start coming to market? Notably, all our CPUs have had 48-bit memory addresses since the introduction of 64 bit chips, and chips that bump up to 57 are in the middle of being introduced. But in part they're bumping that up because it's easy. The 48 bit mode was an optimization, and they left room. With 48 bits as a hard limit of what fits into a register, and that representing 256 terabytes / 384 tera-octets of memory, I suspect we would stick with 48 bits for many more years.
- zamadatix 4y ago
  Notably x86-64 canonical form uses the full 64 bit address when referring to memory and that's what's in the registers it just doesn't handle addresses in the middle of all places (i.e. it counts addresses in two halves, one half from FFFF... down and one half from 0000... up, not just the first 48 bits of addresses).
  - Dylan16807 4y ago
    I'd say it does use just the first 48 bits, but in a sign-extended way. You could sign-extend to any size you want, even beyond 64 bits. And it forces the program to do the sign extension, so it'll be forwards-compatible with chips that use more bits. But once those bits are verified they get immediately discarded.
    - zamadatix 4y ago
      The method would scale to any number of bits but the actual registers and addresses passed to the MMU really are 64 bit in real processors, as in you can actually set it to some other non-sign extended 48 bit value with your program today and you’ll just get an MMU exception when you go to use it. After all the CPU doesn’t know something in a register is to be treated as a memory address until after the value is already loaded into the register. The advantage of 48 but addressing in x86-64 is fewer levels of page lookups (speed up), not abbreviated addresses.