Comment by rep_lodsb | Hacker News Reader

Comment by rep_lodsb | Hacker News Reader

Great article, especially the opcode charts! Almost all you find online are unfortunately in hex, which obscures the encoding.

The strangest feature inherited from the 8008 is probably the parity flag. There are some uses other than 7-bit ASCII comms for it, but this kind of code is probably heavily 'pessimized' on modern CPUs:

    TEST AL,0xc0
    JZ   quadrant0    ;both bits clear
    JPE  quadrant3    ;both bits set
    JS   quadrant2    ;only bit 7 set
    JMP  quadrant1    ;only bit 6 set

And to this day, even the reserved lower flag bits have the same values as they did on the 8080 ('S Z 0 A 0 P 1 C'). I wonder if there is actually code out there that depends on bit 1 being set.

One nitpick:

>The ModR/M byte has been changed in 64-bit mode so the BX (originally HL) register is no longer special when accessing memory

It was 32-bit mode that made EAX, ECX and EDX usable for addressing, though not the 16-bit lower half registers. And nothing with that changed in the transition to 64 bits.

you might be interested in my opcode map for the 8080 in Dercuano (temporary online copy at https://dercuano.github.io/notes/8080-opcode-map.html ); it not only uses octal but also uses the digit order 0, 2, 4, 6, 1, 3, 5, 7 to bring out the structure of the instruction set better

datapoint's manuals for the 2200 instruction set use octal, but intel's 8008 manual uses hex, maybe due to some kind of misguided admiration for ibm

That digit order is an interesting choice to bring out more structure. The downside is the registers and RST instructions get weirdly permuted. (By the way, your link is broken because the closing parenthesis gets appended; I recommend a space before it.)

My suspicion is that Intel's manuals used hex because octal was kind of obsolete by that point.

thanks for the note; i've made the suggested correction

i agree about the registers and rst instructions

i don't see how octal could be obsolete; computers still use binary, and octal is just as useful for doing binary arithmetic as it ever was. as you point out, it's considerably more useful for instruction sets with 3-bit fields. moreover, the great advantage of hexadecimal was that bcd was easy to read, but that stopped mattering around the time the 8008 was introduced

i'm interested to hear if your experience differs, but i think it's a lot easier to do mental arithmetic in octal than in hex; it's a lot easier to remember 5 + 6 = 13, or figure it out if you forget, than d + c = 19, and both the addition and multiplication tables are one fourth the size

as far as i can tell, octal just went out of style. if anything, hexadecimal became obsolete, because its killer advantage went away, while its drawbacks remained

arm leaned into the hexadecimal wave and designed their instruction set to be easily readable in hex. we probably don't have to worry that a possible wide adoption of risc-v will initiate a transition to base 32, though; its instruction formats, while much simpler than thumb, resists any such easy numerical readability

btw, i don't remember if i ever told you this, but thank you for xfractint

Octal is nice with a 12-bit machine but octal is absolutely awful when using bytes on a 16-bit machine. The problem is that the two bytes are encoded differently in octal. For example, the string "AB" is 4142 in hex while "BA" is 4241; the two bytes are easy to decode. In octal, "AB" is 40502 while "BA" is 41101; you can't see what's going on.

yes, that's true; multiplying a byte by 400 to form a word is kind of a pain

i had a heathkit h8 which had an unusual approach to this problem

it displayed memory addresses on its front panel in octal, from 000000 up to 377377

In the context of a CPU's memory model, I wouldn't call it style because a byte--as an abstract term for the smallest addressable unit--is subdivided into nibbles (digits), where the size of a nibble dictates what base makes sense.

A 9-bit byte is subdivided into three 3-bit nibbles/digits (2^3=base-8) [000, 777].

An 8-bit byte (octet) is evenly subdivided into two 4-bit nibbles/digits (2^4=base-16) [00, FF].

In documentation--given that the majority of computers use 8-bit bytes--the base we choose to represent 3-bit fields is a separate topic, and could be called style.

there's something to that

as a side note, i have a quibble with your definition of 'byte'. lots of computers have been word-oriented, with words being generally the smallest addressable unit

word sizes in word-addressed computers have included 12 bits (pdp-8), 16 bits (nova and tandem), 18 bits (pdp-7 and ga144), 20 bits (mup21), 32 bits (zuse z4, chifir, and maybe some ti dsps, not sure), 36 bits (pdp-10, ibm 704, ibm 709), 60 bits (cdc 6600), 64 bits (cray unless you count the parity bits), and so on

it was not normal practice to describe any of these words as a 'byte'; more commonly, you would divide the word into (possibly variable-size) 'bytes', each representing one character, even though you couldn't load those bytes individually from memory

I wonder if there is actually code out there that depends on bit 1 being set.

Almost certain there is. Demoscene and emulator detection code come to mind.

Thanks, I've fixed that.

Reply on news.ycombinator.com