5 ms·

One problem with this theory that ASCII killed off octal is that ASCII was introduced in 1963, while octal was popular into the mid-1970s. The real reason that

by kens 4y ago

One problem with this theory that ASCII killed off octal is that ASCII was introduced in 1963, while octal was popular into the mid-1970s. The real reason that hex beat octal is 16-bit words. It's trivial to break a 16-bit word into two bytes with hex, but it's a mess in octal. To make this concrete, suppose we have the bytes 1, 2, 3, 4 in 16-bit memory. In hex, this is 0102 0304. In octal, this is 000402 001404. Hex makes it trivial to see the bytes, extract them, byte-swap, etc. In octal, you need to sit down and think. I've worked on a 16-bit octal machine (Xerox Alto) and after about 2 minutes it's obvious why hex won.

jameshart 4y ago
All of which makes sense since you know eight bit bytes and sixteen bit words are going to win the day. But when twelve bit words are still in contention, it isn’t so cut and dried. And ASCII is what pushes you towards preferring eight bit bytes.
- codeflo 4y ago
  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.
- kens 4y ago
  What pushed computing toward eight bit bytes is the IBM System/360 (1964) which dominated the computing industry at the time. It used 8-bit EBCDIC (with ASCII as an afterthought). If ASCII didn't exist, we'd still be using byte-based systems and hexadecimal. Prior to System/360, business data processing typically used 6-bit characters (e.g. IBM 1401), which only gave you upper case. Scientific processing used whatever word size gave the desired accuracy, so it was totally reasonable to have a 15-bit computer or a 26-bit computer. Powers of two for the word size are convenient for slicing up words into smaller pieces and for specifying a bit in the word. But you also have systems like the Four Phase, which used 24-bit words consisting of 3 bytes. (Which turned out to be a mess when you try to extract bytes from words.)
  - jameshart 4y ago
    But you only care about the difficulty of extracting eight-bit bytes from words because you need to do things like interoperate with protocols or storage media based on eight bit bytes, or eight bit parallel interfaces. If everything were based on a different basic ‘byte’ size that objection would go away. Sure, oddball things that used 8-bit data would exist and you’d need to work with them - but in our 8-bit world oddball things based on 10-bit protocols exist and we live with the impedance mismatches that causes.
    - Dylan16807 4y ago
      But what other byte sizes are viable? 6 bits isn't enough. 7 bits is viable for characters but at that point there's strong pressure to move up to 8 as a power of two. 9 fits neatly into octal but there's little advantage over 8 so you're probably going to prefer either 8 or 10. Between 8 and 10, I could see 10 winning. But either way octal isn't doing very hot.
      - lokedhs 4y ago
        36 bits is very neat, and used by several machines including the PDP-10. The smallest unit doesn't have to be a single character.
userbinator 4y ago
On the other hand, x86 (and 8080/5/Z80) instruction encodings look far more sensical in octal, due to their 2-3-3 field arrangement, yet the official documentation has always used hex.
- kens 4y ago
  I agree with you 100% there. The Datapoint 2200 (which the 8008 cloned) used octal for its instructions and the instruction decoding is almost trivial to understand. Unfortunately, Intel used hexadecimal for the documentation. In hex, you can kinda see some patterns in the opcodes. The 6502, on the other hand, arranges the fields 3-3-2, so octal is no help even though the fields use bit triples. Discussion of "x86 is an octal machine": https://news.ycombinator.com/item?id=30409100 https://news.ycombinator.com/item?id=30409100

by kens 4y ago

jameshart 4y ago

All of which makes sense since you know eight bit bytes and sixteen bit words are going to win the day. But when twelve bit words are still in contention, it isn’t so cut and dried. And ASCII is what pushes you towards preferring eight bit bytes.

codeflo 4y ago
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.
kens 4y ago
What pushed computing toward eight bit bytes is the IBM System/360 (1964) which dominated the computing industry at the time. It used 8-bit EBCDIC (with ASCII as an afterthought). If ASCII didn't exist, we'd still be using byte-based systems and hexadecimal. Prior to System/360, business data processing typically used 6-bit characters (e.g. IBM 1401), which only gave you upper case. Scientific processing used whatever word size gave the desired accuracy, so it was totally reasonable to have a 15-bit computer or a 26-bit computer. Powers of two for the word size are convenient for slicing up words into smaller pieces and for specifying a bit in the word. But you also have systems like the Four Phase, which used 24-bit words consisting of 3 bytes. (Which turned out to be a mess when you try to extract bytes from words.)
- jameshart 4y ago
  But you only care about the difficulty of extracting eight-bit bytes from words because you need to do things like interoperate with protocols or storage media based on eight bit bytes, or eight bit parallel interfaces. If everything were based on a different basic ‘byte’ size that objection would go away. Sure, oddball things that used 8-bit data would exist and you’d need to work with them - but in our 8-bit world oddball things based on 10-bit protocols exist and we live with the impedance mismatches that causes.
  - Dylan16807 4y ago
    But what other byte sizes are viable? 6 bits isn't enough. 7 bits is viable for characters but at that point there's strong pressure to move up to 8 as a power of two. 9 fits neatly into octal but there's little advantage over 8 so you're probably going to prefer either 8 or 10. Between 8 and 10, I could see 10 winning. But either way octal isn't doing very hot.
    - lokedhs 4y ago
      36 bits is very neat, and used by several machines including the PDP-10. The smallest unit doesn't have to be a single character.

userbinator 4y ago

On the other hand, x86 (and 8080/5/Z80) instruction encodings look far more sensical in octal, due to their 2-3-3 field arrangement, yet the official documentation has always used hex.

kens 4y ago
I agree with you 100% there. The Datapoint 2200 (which the 8008 cloned) used octal for its instructions and the instruction decoding is almost trivial to understand. Unfortunately, Intel used hexadecimal for the documentation. In hex, you can kinda see some patterns in the opcodes. The 6502, on the other hand, arranges the fields 3-3-2, so octal is no help even though the fields use bit triples. Discussion of "x86 is an octal machine": https://news.ycombinator.com/item?id=30409100 https://news.ycombinator.com/item?id=30409100