23

In the early history of computing before the mid-1960s, there was no universal, de-facto standard for the written representation of a hexadecimal number, different computer systems used their own written presentations. Wikipedia has some examples.

  • The ILLIAC I (1952) computer used the uppercase letters K, S, N, J, F and L for the values 10 to 15.

  • The Honeywell Datamatic D-1000 (1957) used the lowercase letters b, c, d, e, f, and g whereas the Elbit 100 (1967) used the uppercase letters B, C, D, E, F and G for the values 10 to 15.

  • The Monrobot XI (1960) used the letters S, T, U, V, W and X for the values 10 to 15.

  • The Pacific Data Systems 1020 (1964) used the letters L, C, A, S, M and D for the values 10 to 15.

I was reading alt.folklore.computers today and found a claim: The IBM S/360 was one of the major computer systems that used 'A' to 'F' to represent a hexadecimal number, and S/360 was largely responsible the popularization of this de-facto standard due to its success.

How true is this claim?

比尔盖子
  • 3,114
  • 1
  • 14
  • 32
  • 4
    Wasn't A, B, C, D, .... universally used in mathematics for digits in positional bases above 10? See e.g. Egmont Colerus: Vom Einmaleins zum Integral from 1934. – Radovan Garabík Jun 06 '20 at 12:41
  • 2
    @RadovanGarabík: I've seen a variety of notations for digits above nine, especially when using things like base 11 or 12 (which just need one or two extra symbols) or base 20 (which sometimes used normal and altered forms of digits 0-9). No doubt people have used A-F to represent digits with values 10-15 for a long time, but older papers I've seen that talk about number bases always seemed to regard the choice of digits as arbitrary, rather than suggesting that there was a standard convention. – supercat Jun 06 '20 at 17:14
  • Gotta say your research is excellent. – zarchasmpgmr Jun 07 '20 at 01:16
  • 2
    @RadovanGarabík What is Mathematics by Courant & Robbins (1941) uses lower case Greek letters. There seems to have been no standard notation in the way there is today. – Michael Graf Jun 08 '20 at 14:35
  • I gotta say, if I needed a symbol for each of 10, 11, 12, 13, 14 and 15, then ABCDEF are the first I'd think of. Even BCDEFG seems like a strange choice, unless maybe they had reason to skip A. But who on earth came up with KSNJFL and LCASMD and why? – Omar and Lorraine Oct 27 '22 at 08:43

1 Answers1

11

TL;DR:

How true is this claim?

It's true. While others used it before, it was the success of the /360 making it the default way around the industry.

The long read:

[Preface: I love the shown research]

I was reading alt.folklore.computers today and found a claim: The IBM S/360 was one of the major computer systems that used 'A' to 'F' to represent a hexadecimal number,

True. While A-F has been used before, it didn't get much used as architectures were largely based around word sizes with a multiple of 3, making octal the best representation.

One major goal for the /360 architecture was fast (and easy) handling of decimal data without much conversion. For that byte (and word) size as multiples of four is the most obvious and storage efficient size. With an 8 bit byte two (numeric) punch card columns can be stored in one byte, 7 to a word and 15 to a double word (plus sign). As a result they needed symbols for the remaining six combination and went for A-F.

(Also, on a side note, the /360 was not simply 'one of' the 'major computer systems' but has essentially blown everything else away)

and S/360 was largely responsible the popularization of this de-facto standard due to its success.

Exactly. IBM did bet it's company on the /360 and won. Right after introduction it became an incredible success, making IBM the IT giant it has been thruout the 70s and 80s. It became the de facto architecture for mainframes, sucking in everyone able to spell at least two letters of C/O/B/O/L in arbitrary order as programmer. All manuals and training documentation presented only hex notation (*1), making it the de facto way to talk about binary.

While mini computers did take a slow change from octal to hex, basically all micros started out in Hex. Even CPUs like the 8080, with an instruction set clearly designed in octal, got published with all hex documentation. And as they say, the rest is history.

*1 - L'esprit de l'escalier: IBM did add decimal/octal conversion tables to some early manuals.

Raffzahn
  • 222,541
  • 22
  • 631
  • 918
  • 4
    “ sucking in everyone able to spell at least two letters of COBOL” – zarchasmpgmr Jun 07 '20 at 01:16
  • 2
    A reason not mentioned is, that it is a noticable advantage (for base conversion routines) , to have consecutive character encodings for the additional "digits"; this eliminates all irregular examples from the question. IBMs EBCDIC encoding had lots of ugly gaps. – guidot Jun 17 '20 at 14:58
  • 1
    @guidot ?? Neither EBCDIC nor ASCII has a consecutive order between digits and letters. Both have them in separate blocks. But more important, binary to readable-hex on a /360 was never done by calculation, it's a simple two instruction unpack and translate ( UNPK TEXT(9), WORD(5) + TR TEXT(8),ETOHEX-240 + ETOHEX DC "0123456789ABCDEF"). No calculation ever, so no need to be consecutive in any way. – Raffzahn Jun 18 '20 at 13:16
  • 2
    @Raffzahn: Misunderstanding; Yes, one gap between digits and the first letter is practically not avoidable, but the following letters should be on subsequent positions., which fails for K, S, N, J – guidot Jun 18 '20 at 13:44
  • 1
    @guidot Erm, yes, but having the letters consecutive isn't of any help. Code transformation should always be made as abstract as possible, no matter if using Assembly or any other language. Keep in mind, there are codes where neither letters nor numbers are in sequence. Above sniplet can be compiled with any character code (oops, should read ETOHEX-'0'). Similar in BASIC the core line would be TEXT$ = TEXT$+ MID$("0123456789ABCDEF",DIGIT,1) and so on. Avoid assuming a code set wherever possible. It's the compilers job to get around that. – Raffzahn Jun 18 '20 at 14:03
  • Those conversions only work if you have well behaved hex numbers. I just imported data from an ancient document where l (lowercase L) and I (uppercase i) were used in place of 1 in some places. – cup Oct 26 '22 at 14:12
  • @cup which conversations? The ones shown is hex to letter, and I do not think how anyone could press a non hex digit into 4 bits :)) Beside, the other way around is always best done as well using a translate and define a value (or making a non value) for each and every input character. Doing so means covering i/I for 1 or o/O for 0 a simple task. What was it, bad OCR? – Raffzahn Oct 26 '22 at 15:58
  • It was the one about MID$ ... Possibly bad OCR - a bit strange because some of the 0 are filled in like on a typewriter. This is the DES spec which was written in 1998. – cup Oct 26 '22 at 16:10
  • 1
    @guidot - but against your argument consider that the /360 family has both the "translate" instruction TR and "translate and test" TRT which makes any non-consecutive and even non-ordered alphanumeric encoding of any base - up to base-256 - easy to decode! Use TRT to find invalid characters in your field or to find the end of the field (first invalid character for your encoding) and then use TR to convert your encoded field into "digits" of the target base and then multiply it out to get the number that was encoded. Easy-peasy. (Do the reverse to encode for output ...) – davidbak Oct 26 '22 at 20:39
  • 1
    (See here for a description of TR and TRT.) – davidbak Oct 26 '22 at 20:42
  • @cup That mid$ example is as well about translating an existing value of 0..15 into a rintable character, not the other way around, which is your use case. And yes, back then many (especial in the US) typewriters did not feature a 0 (Zero) key or type, people were using the letter 'O' or 'o' for zeros. In fact it was even seen as advantage to do trailing zeros with lower case 'o', to improve readability of large numbers. – Raffzahn Oct 26 '22 at 20:48
  • @davidbak In fact, x86 also features an according XLAT instruction fine to be used with string instructions, so TR/TRT like operation is quite tive to x86 as well. Not using that may be rather an issue of programming languages and education. – Raffzahn Oct 26 '22 at 20:51