When and why did hexadecimal representation become more common than octal for displaying and printing out multi-bit binary fields?

  • 25
    I'd say around the time when word sizes of 36, 18 and 12 bit transitioned to the multiple-of-8-bit sizes we have today. That should also explain the "why". :-)
    – dirkt
    Commented Aug 20, 2019 at 18:31
  • 4
    In DEC, even the PDP-11 culture was still using octal, even though it didn't fit very well. The VAX people used Hex. Commented Aug 20, 2019 at 19:58
  • 3
    Re, "instructions that fit...nicely into...octal" If a peg fits nicely into a hole, should we thank the maker of the peg? or should we thank the maker of the hole? Commented Aug 20, 2019 at 19:59
  • 11
    I was a software intern at CDC back around 1990. I remember complaining about an octal dump to one of the senior engineers, who responded, "what else would you use, hex?" with scorn and disbelief. Having grown up with an Apple II, it was in fact exactly what I wanted. :-)
    – fadden
    Commented Aug 20, 2019 at 22:26
  • 4
    Upvoted because the varied answers and comments demonstrate the lack of a precise answer; it depends on your particular computing culture. (Saying there's no precise answer does not imply criticism of the question; quite the reverse, it has promoted interesting discussion)
    – dave
    Commented Aug 21, 2019 at 22:51

5 Answers 5


Addressing the "why" part of the question - from my point of view as an assembly-code programmer on PDP-11 and VAX, the "standard" radix is most usefully chosen to match the instruction layout.

PDP-11 had 8 registers and 8 operand-mode indicators. Its double-operand instruction layout was

1 bit generally byte/word indicator (b)
3 bits opcode (o)
3 bits source mode (s)
3 bits source register (r)
3 bits destination mode (d)
3 bits destination register (R)

making octal the perfect way to express it:


The VAX, on the other hand, had 16 registers and 16 bits for operand mode (though some combinations were used for short literals). A basic operand specifier, in the variable-length instruction format was

4 bits mode (m)
4 bits register (r)

thus hex was perfect to express these.


Of course, the larger address space used on VAX gives other advantages to hex: fewer characters in an address. This might have some bearing on "when".

  • 7
    x86 instruction set is also more usefully thought of as octal-encoded (see e.g. here), but hex is still the most common non-decimal non-binary radix in assembly programs written for it. Some assemblers don't even have a syntax for creating octal literals.
    – Ruslan
    Commented Aug 21, 2019 at 8:33
  • Not sure that applied to Prime. I think that was just "what they were used to". Commented Aug 21, 2019 at 13:26

The when and why of use of hexadecimal over octal representation is intimately tied in with where and what: the use of one over the other depended greatly on environmental factors, as well as the machine itself, with programmer preference mainly being developed by the influence of these.

As Raffzahan points out, IBM 360 environments used hexadecimal from their start in the early 60s. This did not particularly influence other computing environments (particularly minicomputers) because IBM at that point was still its own separate world within computing for both technical reasons (e.g., using EBCDIC instead of ASCII) and because, despite the 1956 consent decree, they were still successfully using various measures to stifle compatibility and competition. (This wouldn't start to change in a serious way until the various lawsuits started pouring out in 1968 and 1969.)

Octal was a good fit for DEC minicomputers and early "micro-sized" machines (such as the PDP-8) because of their word sizes (18, 36 and 12 bits). Existing systems were naturally used to help develop new platforms, and thus new platforms after these would tend to inherit the octal versus hexadecimal choice from the existing ones. Famously, early versions of Microsoft Basic were assembled on a PDP-10 using MACRO-10, which didn't support hexadecimal, and so the source code used octal throughout where the bit values were considered important to the programmer, despite hexadecimal being the preferred number base for all of the first three CPUs (8080, 6800, 6502) for which it was written.

The same was true of the PDP-11, which was DEC's first major computer where the various word sizes were all multiple of 4 bits rather than 3. Even though software development rapidly moved to being done on the PDP-11 itself, DEC environments up to that time had been entirely octal, and so with programmers of DEC equipment mostly being more comfortable with that, it "stuck." (While other-dave points out that the bitfields in the instructions tended to be 3 bits wide, I don't buy this as a major factor; by 1970 hand-assembly was rare for machines of minicomputer size and up, in which category the PDP-11 indubitably fell.)

My guess is that the "it's what I'm used to" effect was at least part of the reason for the front panel of the original Altair 8800 being clearly organized for octal, despite Intel using hexadecimal throughout the 8080's documentation. However, there were a number of instructions, particularly MOV, with three-bit fields aligned with octal, so perhaps they did also have in mind that people might be hand-assembling to octal for this reason. (The typical Altair owner was unlikely to have another, larger computer handy for cross-development.)

Altair 8800 front panel (Source: Wikimedia Commons.)

That said, the awkwardness here is apparent if you open the image in a new tab and look at the upper set of markings ("SENSE SW" and "DATA") underneath the switches themselves; the split between the two 8-switch halves falls in the middle of one of the groups of three. (The owner of this system was obviously annoyed enough by the octal layout that he added tape to the front panel to visually indicate four groups of four!)

The 6800-based Altair 680B, released barely a year later, had already switched to panel markings that grouped the switches in fours, rather than threes.

By the late 70s the 8080/6800/6502 and their various progeny were starting to dominate the computing landscape, at least as far as numbers goes, and because they in particular tended toward use of hexadecimal it became more likely that's what a programmer would be comfortable with if he were not equally comfortable with both. But as fadden points out in a comment, even into the 90s there were still environments where octal was the norm and hexadecimal was generally rejected.

This continues to this day in certain areas where it's unlikely ever to change because octal is significantly easier to read than hexadecimal. For example, the POSIX file permission bits are a group of two bits for sgid/suid followed by three groups of three bits for owner/group/other permissions of read/write/execute: these are normally and most easily specified (both for command line tools such as chmod and when programming) as four octal digits.

So if you're going to try to treat the computing community as monolithic, and just go on the number of programmers that preferred one over the other, I'd agree with Chromatix that the "shift" happened in the mid- to late-70s. But I think that is probably too simplistic a way of looking at it to be a particularly valuable insight.

  • 2
    Me again! by 1970 hand-assembly was rare Indeed it was, but debugging kernel code tended to use a little lights-and-switches work on the front panel, and a lot of poring over memory dumps. Kernel debuggers (XDT on 11M) did not disassemble code, so hand-disassembly was an occasional thing. Lastly, I don't want to over-sell it, but the ability to think hmm, that alleged data sure looks like instructions was a useful skill.
    – dave
    Commented Aug 21, 2019 at 12:13
  • "IBM at that point was still its own separate world within computing" Not really, if at all, IBM was the continental force, while there were islands that maintained difference. _"using EBCDIC instead of ASCII" - again not really, as EBCDIC was only used within the mainframe system. External communication was done by default in ASCII. This included not only all terminal peripherals, but any kind of third party sub system connection. Heck, the mainframes itself could be switched to ASCII handling. So while IBM did everything they could to stop competition, shuning ASCII wasn't one of them.
    – Raffzahn
    Commented Aug 21, 2019 at 13:05
  • Nice point with the Altait and even more so nice lighted picture- sourced from where? Oh, and +2 for the 'monolithic' remark.
    – Raffzahn
    Commented Aug 21, 2019 at 13:09
  • @Raffzahn Good point: the URL of the image itself isn't a good source attribution. I've added a link to the Wikimedia Commons category where I found it. Looking there, later panels did clean up the labeling slightly, but that doesn't help much. Toggling a few small programs into this simulator demonstrated to my satisfaction that the grouping into 3s is more of a pain than a help when entering instructions, even when working from an opcode list in binary, because of S7 being in the middle of a group of three.
    – cjs
    Commented Aug 21, 2019 at 13:39
  • Oh, it's not just the 8080 that reads nice in octal. The 6502 would do as well, asit's encoding follows a basic 3-3-2 scheme
    – Raffzahn
    Commented Aug 21, 2019 at 17:50

When and why

That is quite close tied to the IBM /360 and its introduction in 1964. The /360 is based on the use of an 8 bit byte, 32 bit word (16 bit half word) and 24 bit address. Thus all basic memory items were multiples of 8 bit units - which are, without any remainder, best be displayed in hex. In addition displaying bytes in hex correlates well with the main reason to use 8 bit bytes as well: the usage to store two BCD in one byte (*1). A hex dump will show them as easy readable numerals - while the rest is code anyway. The same way it works for (half, double) words. In a dump they can be read and decoded as what they are without any additional concern (*2). In octal a word displayed as bytes, like in a dump, will get a different numeric expression than displayed as a (half, double) word (*3). Effectively the same reasoning why decimal isn't used in the first place (*4).

Before that size of bytes, half words and words were (more often than not) multiples of 3, which works quite fine with octal. After all, grown up with decimal it's way less mental work to not use two numbers, than to learn six more. It seams more natural, doesn't it?

After that next to all new designs switched to 8 bit bytes to allow easy data exchange with IBM mainframes. This happened even faster for mini computers as they where usually supplementary systems to (/360ish) mainframes.

Additional thought about the transition and it being different due environment.

Another-dave made the point that he'managed to cope with octal [on a PDP-11]', noting the prevalence of octal in an DEC envirionment even way later. Thinking of, the PDP-11 is a rather late comer to his as being from 1970. At that time the 6 to 8 bit byte was done history - likewise the switch to hex - for major suppliers. In fact, the PDP-11 marks that spot in DEC history. But DEC as a company (and its machines users) made a rather smooth transition from 6/12/36 bit computers to 8/16/32 bit - DEC did not only continue to support their existing line, but also continued to sell and even develop new models of their 36 bit line well into the 1980s.

In contrast with IBM the switch was done in a brutal manner as the /360 not only almost killed the company but in turn replaced any other (mainframe) architecture. After that 8 bit (and hex) was rolled out across all new products and everything else eliminated quite fast. Some 'islands' remained with existing supercomuter installations into the early 1970s but got moved either to /360 or non-IBM (often CDC/Cray). Some of the later carrying on for more years with octal representation.

Almost anyone entering the market after 1964 did start with 8 bit bytes and hex notion for binary data. This is (as Curt notes) especially true for micro-computers, as next to all of them started with 8 bit bytes and their OSes/UIs preferring hex notation.

So while the general turning point it quite clear and fixed in time with IBMs choice for an 8 bit byte holding two BCD, adoption did vary across manufacturers, its user base and application areas.

Adoption of changes by humans are always gradual .. keep in mind, even after 100+ years of road regulation and harmonisation, there are still countries with right-hand traffic :))

See also this question about the rational of 36 bit designs. While not a true duplicate, it's quite related here.

*1 - Previous machines (often) stored one decimal per 6 bit byte, thus wasting more than 1/3 of memory when handling decimal (which was a major task - after all, accountants always got the computers first, not scientists). By switching to 8 bit bytes, holding two nibbles with one decimal each, memory usage was close to optimum without resorting to base 100 (7 bit byte) or base 1000 (10 bit byte).

*2 - Beyond byte sex that is

*3 - For example the Number 1024(Dec) is 0401(Hex Word) and 04 01 (Hex Byte) but002001 (Oct Word) and 004 001 (Oct Byte)

*4 - BASIC programmers on home computers offer an additional nice example here, as many of them used assembly as series of PEEKs and POKEs expressed in decimal numbers. I met more than one who was fluent in 6502 assembly, still I had a hard time understanding their all decimal opcode numbers :))

  • Being a PDP-11 hack (16-bit virtual, 18- or 22-bit physical), I sincerely don't understand the "multiple of 3" argument. We managed to cope quite well with the high digit being no greater than 1 or 3.
    – dave
    Commented Aug 21, 2019 at 3:08
  • @another-dave Yes, but even in your own words you "managed to cope," rather than saying you felt octal worked as well or better. Beyond what you described in your answer, within DEC there were good reasons to use octal over hex (e.g., the MACRO-10 assembler, which was at least sometimes used to cross-assemble for other platforms, didn't support hex). But if you look at just the display of data for power-of-2 word sizes, with no other factors involved, would you ever chose octal over hex?
    – cjs
    Commented Aug 21, 2019 at 8:06
  • @another-dave the multiple of 3 argument is in favour of octal, meaning that people tended to create architectures that used byte/word sizes as multiples thereof. It's not any comment about the usablity of octal itself on other architectures - the argument is (like most historical) non reversible.
    – Raffzahn
    Commented Aug 21, 2019 at 11:20
  • "Managed to cope" is English sarcasm, sorry about that. The multiple-of-3-bits argument seems to me like saying decimal is not well-suited to represent the number of eggs in a box, because it's not a power of ten.
    – dave
    Commented Aug 21, 2019 at 12:08
  • 1
    @EdwardBarnard After all, Cray(ish) machines did do multiple of 3 words for quite a long time, didn't they?
    – Raffzahn
    Commented Aug 27, 2019 at 8:06

Minicomputers and mainframes typically used octal, as many early mainframes had word sizes that were a multiple of 3 bits, and so did some minis. Operators and engineers within those environments became used to this, so even power-of-two word size minicomputers kept using octal.

Microcomputers, however, almost always had power-of-two word sizes for both address and data buses (or at least, a multiple of four bits), and there was a whole new generation of users who were not mentally locked into the mainframe/mini way of thinking. It was thus natural to start using hexadecimal instead.

You'll probably find, therefore, that hexadecimal rose to prominence about when microcomputers did, in the mid to late 1970s.

  • 4
    Nah, we were using hex in the late 60s on IBM/360 and 370 systems. Commented Aug 21, 2019 at 7:04
  • We were using octal on Prime in the early 80's. Commented Aug 21, 2019 at 13:27
  • 1
    :) We were usiing octal on Soviet clones of PDP-11 in the early 90's
    – tum_
    Commented Aug 21, 2019 at 17:54
  • Well, there are always exceptions from the norm. The question was about what the norm was.
    – Chromatix
    Commented Aug 21, 2019 at 18:04
  • Now, the norm iseasy to point out: IBM, what else :))
    – Raffzahn
    Commented Aug 22, 2019 at 21:44

As others stated, of course this is related to word size on your machine.

I started learning higher programming languages on a WANG 2200T in 1977, and everything was hexadecimal there. My "Junior Computer" in 1980 was programmed in 6502 assembly, and everything was hexadecimal there as well. The first time I heard about octal notation was when I learned C with the K&R book in 1982. And my understanding was that on older machines you would prefer octal to hexadecimal.

  • This doesn't strictly answer the question; it's more of an anecdote. Could you review How to Answer, and edit your answer to improve it?
    – wizzwizz4
    Commented Aug 21, 2019 at 20:47
  • 2
    But it's not, or at least not only, related to word size. Octal was the standard for the PDP-11 despite it having 16-bit words. The Altair 8800 front panel and all documentation shiped by MITS used octal exclusively, despite the Intel 8080 using 8- and 16-bit words and Intel using hexadecimal in manuals and data sheets on which MITS relied.And the IBM 360 was a much older machine than any of these yet there you preferred hexadecimal to octal.
    – cjs
    Commented Aug 22, 2019 at 5:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .