4 ms·
On the other hand, reading octal and seeing ASCII is really tricky. One thing I've realized from working with the Xerox Alto is that octal is really awful and h
by kens 10y ago
On the other hand, reading octal and seeing ASCII is really tricky. One thing I've realized from working with the Xerox Alto is that octal is really awful and hex is much better.
In octal a 16-bit word doesn't split up evenly into bytes, so even recognizing ASCII is difficult. For example, the string "AA" in hex is 0x4141, where each 41 is 'A' - pretty easy. But in octal, it's 040501; 0101 is 'A' but gets multiplied by 4 in the upper byte. (One thing in defense of octal: the 8080/Z-80 instruction set makes much more sense if you look at it in octal.)
- userbinator 10y agox86 is also octal-structured, and I can mentally assemble and disassemble most of the basic instructions from a hexdump by converting between hex and octal: https://news.ycombinator.com/item?id=13045558 https://news.ycombinator.com/item?id=13045558 In octal a 16-bit word doesn't split up evenly into bytes, so even recognizing ASCII is difficult. That's true only if your hexdump is in 16-bit words; in bytes, it's just as straightforward: A-Z is 101 through 132, and a-z is 141 through 172. Incidentally, these are also where x86 puts the single-byte inc/dec/push/pop instructions.
- tyingq 10y agoI believe most linux distros come with 'od', which can dump octal by byte. $ echo 'ABC' | od -bc 0000000 101 102 103 012 A B C \n 0000004
- ChuckMcM 10y agoAs I recall some DEC utilities supported 'split octal' which was base 8 on 8 bit boundaries. With a 16 bit value of 0xffff was represented as 377377 rather than 177777. But their (DEC's) love of octal was why you got 18 bit and 36 bit machines. It is a good example of how language effects design, than the use of hexadecimal vs octal and its impact on computer architecture.