Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

x86 Is an Octal Machine (1995)

gist.github.com

Post reply on HN
Print view View original

41–50 of 51 posts

Re: x86 Is an Octal Machine (1995)

#41

Post by pcwalton »

woodruffw wrote: post #4

I remember seeing a copy of this Usenet post years ago! It's one of my favorite "secrets" about x86's encoding. The "core" (non-E/VEX, non-SSE, etc.) x86 encoding is wonderfully clever and terrible by modern standards, and Volume 2 of Intel's SDM is a great reference for how x86 manages to pack remarkably complicated addressing, operand, etc. semantics into just a handful of bytes. The result is a format that's remar…

Not sure if x86-64 REX prefixes count as "core" by your definition, but REX prefixes are incredibly wasteful and basically throw away all the code size gains that x86 would otherwise get over competing instruction sets. For most instructions, 4 bits are wasted to signal REX, and usually at least 1 more bit is wasted on register extensions not used by the instruction, particularly the SIB index extension. If you limit yourself to 32-bit x86, then yeah, x86 is pretty compact.

Re: x86 Is an Octal Machine (1995)

#42

Post by ggm »

At some level this feels like a consequence of a design decision heading to the instruction decode logic. You can map from the Octal groups to the ALU wires and traces and gates in the 8080. They don't have to line up any more, we've moved. beyond that, but if you had the original chip naked and ran it, or ran a simulation, a "mechanistic" relationship between the octal groups might emerge visually?

It also feels like how the 'hidden' instructions get found.

Re: x86 Is an Octal Machine (1995)

#43

Post by woodruffw »

pcwalton wrote: post #41
woodruffw wrote: post #4

I remember seeing a copy of this Usenet post years ago! It's one of my favorite "secrets" about x86's encoding. The "core" (non-E/VEX, non-SSE, etc.) x86 encoding is wonderfully clever and terrible by modern standards, and Volume 2 of Intel's SDM is a great reference for how x86 manages to pack remarkably complicated addressing, operand, etc. semantics into just a handful of bytes. The result is a format that's remar…

Not sure if x86-64 REX prefixes count as "core" by your definition, but REX prefixes are incredibly wasteful and basically throw away all the code size gains that x86 would otherwise get over competing instruction sets. For most instructions, 4 bits are wasted to signal REX, and usually at least 1 more bit is wasted on register extensions not used by the instruction, particularly the SIB index extension. If you limit…

Yeah, I was talking about 32-bit x86. REX is indeed very wasteful :-)

(Even then, there's a lot of waste in the "legacy" prefix bytes, and I've always wondered who hacked those into the ISA instead of designing something more compact.)

Re: x86 Is an Octal Machine (1995)

#44

Post by fsckboy »

just throwing this out there, all the Digital/DEC PDP stuff used octal notation, and that equipment was quite popular in universities and labs, so engineers would have been quite used to it in the 70's. But they equally could have been responding to the same constraints the Digital engineers did. Just as there wasn't as much memory back then, there weren't as many registers and they didn't have as many bits.

A more agile way to think of it in your head is not as "octal vs hex vs decimal", but bit patterns. For example, if you decompose a byte into subfields and use a subfield of 3 bits to refer to one of 8 registers, you're going to naturally use octal. chmod on the unix command line is still easiest to use in octal because of the 3 rwx bits for ugo. It's not octal, it's bits and how many do you have.

Re: x86 Is an Octal Machine (1995)

#45

Post by userbinator »

pcwalton wrote: post #41
woodruffw wrote: post #4

I remember seeing a copy of this Usenet post years ago! It's one of my favorite "secrets" about x86's encoding. The "core" (non-E/VEX, non-SSE, etc.) x86 encoding is wonderfully clever and terrible by modern standards, and Volume 2 of Intel's SDM is a great reference for how x86 manages to pack remarkably complicated addressing, operand, etc. semantics into just a handful of bytes. The result is a format that's remar…

Not sure if x86-64 REX prefixes count as "core" by your definition, but REX prefixes are incredibly wasteful and basically throw away all the code size gains that x86 would otherwise get over competing instruction sets. For most instructions, 4 bits are wasted to signal REX, and usually at least 1 more bit is wasted on register extensions not used by the instruction, particularly the SIB index extension. If you limit…

I've always thought x86-64 was a very weird "not quite 64-bit" extension of x86 that was done awkwardly, unlike the 16- to 32-bit transition. The fact that AMD designed it and not Intel may have been one of the reasons. Then again, "full 64-bit" wasn't really necessary (and even now, a lot of code is fine with 32-bit ints).

Re: x86 Is an Octal Machine (1995)

#46

Post by grahamlee »

int_19h wrote: post #37
kens wrote: post #30

Earlier quoted context omitted.

One thing I forgot to mention: the 6502 microprocessor also uses groups of 3 bits in its instructions. However, they group them in the "wrong" way, aaabbbcc, so looking at the instructions in octal doesn't help you at all. Also, after using the Xerox Alto, which uses 16-bit words, I realized that octal is terrible. The problem is that if you're looking at two bytes in a word, the values make no sense in octal. For ex…

That's just a consequence of us sticking to 8-bit bytes (and derivative word sizes), no? Octal would have made a lot more sense if it was, say, 12-bit.

“Us sticking to 8 bit bytes” is a consequence of having preferred BCD to octal in the past, so the causation is reversed (“12-bit words would have made a lot more sense if it was, say, octal.”) [Edited: actually 12 bit words would make sense in either case, as it's three BCD digits or four octal digits]

The Intel 4004 used four bits to manipulate a single BCD digit. The 8086 had BCD instructions. There were many reasons for preferring BCD when designing computer architectures, though my favourite which was already becoming less relevant at 8086-time was that it meant a full column on a punchcard wouldn’t be “all holes” and reduced the likelihood of the cards tearing.

Re: x86 Is an Octal Machine (1995)

#47

Post by madmoose »

kens wrote: post #12
klelatti wrote: post #3

Earlier quoted context omitted.

Thanks for these links - very interesting. Astonishing to think that we can see traces of the 8008 still today and that it wasn’t actually an Intel designed ISA (came from CTC / Datapoint).

The Datapoint 2200, the source of the 8008 instruction set, is an interesting machine. The CPU was built from TTL chips. To decode instructions, they used decimal BCD decoder chips, specifically the 7442. But they'd use them as octal decoder chips, only using 8 outputs. The Datapoint 2200 documentation gave the opcodes in octal, so they were clearly thinking in octal. The 8008 documentation, however, didn't use octal…

I implemented an 8086 emulator using the 1981 "iAPX 86, 88 USER'S MANUAL". It specifies the opcodes in bit patterns, so add is specified as "0 0 0 0 0 0 d w | mod reg r/m", where d is direction (mem to reg or reg to mem) and w is width (byte or word). Since this kind of pattern is used across many instructions it makes the code fairly easy to comprehend (to me at least).

Extracting the alu function from bits 4-6 means that you can group together the implementation of add, or, adc, sbb, and, sub, xor, to and from memory, for bytes and words into one function.

The code's not as fast as the "one code block per instruction" approach of something like DosBOX but at least it doesn't cause me dread to look at.

Re: x86 Is an Octal Machine (1995)

#48

Post by segfaultbuserr »

fsckboy wrote: post #44

just throwing this out there, all the Digital/DEC PDP stuff used octal notation, and that equipment was quite popular in universities and labs, so engineers would have been quite used to it in the 70's. But they equally could have been responding to the same constraints the Digital engineers did. Just as there wasn't as much memory back then, there weren't as many registers and they didn't have as many bits. A more a…

To put it in the larger historical context, in the 1970s, octal was the preferred number system due to the prevalence of 36-bit, 18-bit and 12-bit architectures. 0xFFFFFFFF is elegant only for a 32-bit machine, for a 36-bit machine, 0o777777777777 is more natural.

A generation of programmers from the 1960s and earlier were trained to use the octal notation. This can be seen in the original Unix assembler - all numbers were assumed to be octal by default, no prefix is needed. It's also why the C programming language uses a single "0" to detonate octal numbers because it was considered convenient.

The IBM S/360 (1964) was the first major computer systems to break this pattern, switching to a 32-bit system with hexadecimal as its preferred notation, all the official documentation was only written in hexadecimal. This extremely successful machine was highly influential, and was likely the first exposure to hexadecimals to many. The standardization of ASCII in the mid-60s also marked the beginning of this transition from a 6-bit byte, which was the previous status quo, to an 8-bit byte. Then in the 1970s, several popular 16-bit and 32-bit minicomputers started to dominate the market. PDP-11, for example, was a 16-bit machine. Although octal was still its officially preferred number system due to habit and the fact that its instruction encoding was designed with 3-bit subfields, but the departure from 36-bit and 18-bit meant the days of octals was numbered (no pun intended), hexadecimals are simply more natural for dealing with integers.

The final death blow of octal was the microcomputer revolution. After 8-bit and 16-bit CPUs started to dominate the computing world in the late 70s and early 80s, the octal notation has gone and mostly fell out of favor. The x86 was a natural product of this era - it's officially documented in hexadecimal (although, like the PDP-11, octal was natural for its instruction encoding).

Re: x86 Is an Octal Machine (1995)

#49

Post by klelatti »

kens wrote: post #22
klelatti wrote: post #17

Earlier quoted context omitted.

Do you know if Federico Faggin copied the logic design of the 2200 or implemented the ISA using his own design?

The implementation of the 8008 is completely different from the 2200 (as is Texas Instruments' forgotten TMX 1795 implementation). It would be extremely inefficient to copy the TTL implementation, since that depended on what chips were available. But the biggest difference is that the Datapoint 2200 was a serial machine that used serial shift-register memory while the 8008 had a "normal" 8-bit datapath.

Thanks - even in 1972 we had multiple radically different implementations of the same ISA!

Re: x86 Is an Octal Machine (1995)

#50

Post by int_19h »

grahamlee wrote: post #46
int_19h wrote: post #37

Earlier quoted context omitted.

That's just a consequence of us sticking to 8-bit bytes (and derivative word sizes), no? Octal would have made a lot more sense if it was, say, 12-bit.

“Us sticking to 8 bit bytes” is a consequence of having preferred BCD to octal in the past, so the causation is reversed (“12-bit words would have made a lot more sense if it was, say, octal.”) [Edited: actually 12 bit words would make sense in either case, as it's three BCD digits or four octal digits] The Intel 4004 used four bits to manipulate a single BCD digit. The 8086 had BCD instructions. There were many reas…

I'm thinking of earlier times, before microprocessors in general. 6-bit bytes were a thing for a while - fairly logical, too, given that it was just enough bits to encode the entirety of ITA2 without needing any control codes to switch between character banks.
Post reply on HN