34

I found this question asking about the origin of 0x to denote hexadecimal to be interesting.

However, when I cut my teeth programming on 8-bit 65xx systems in the early 80's everything I saw used a $ to denote hexadecimal digits (assemblers, monitors, books, magazines, etc). It wasn't until I got my first Amiga 1000 and started to learn C that I even knew the 0x prefix was a thing.

If the 0x prefix clearly predates the 8-bit revolution, then (1) why was $ adopted so widely? And the opposite, (2) having become ubiquitous for a whole generation of 8 bit programmers, why was it abruptly dropped? (Not that it matters, but I still use $ when commenting code or scribbling on dead trees.)

user3840170
  • 23,072
  • 4
  • 91
  • 150
Geo...
  • 10,177
  • 28
  • 82
  • 6
    I know that Intel used 12H for hex, while Motorola used $12, so that explains why it was adopted widely for 8-bitters. But I am not sure if Motorola invented it, or copied it from somewhere else. – dirkt Aug 16 '20 at 10:44
  • $ prefix is still in use in a lot of assemblers, because old assembler syntax only allows $ – Jean-François Fabre Aug 16 '20 at 12:34
  • 3
    It's also C vs Pascal - C uses 0x whereas Pascal (Turbo) uses $. – No'am Newman Aug 16 '20 at 12:43
  • 1
    @No'amNewman: Consider writing an answer. – DrSheldon Aug 16 '20 at 13:58
  • @No'amNewman That's only true for Turbo Pascal and related implementation. Pascal itself does only doe decimal. Wirth only introduced hex notation with Modula, where he choose a postfix of H. – Raffzahn Aug 16 '20 at 14:53
  • Note that some of us had our first microcmputer programming experience with Basic. Some of the early Basics used $ to denote a string variable, % to denote an integer variable, and anything else was float. (And you thought type casting was a later innovation. ;) $M could be mother's name, etc. – RichF Aug 16 '20 at 19:41
  • 2
    I'm an old IBM 1130 programmer: hexadecimal literals should start with "/". – John Doty Aug 16 '20 at 21:10
  • 1
    I remember that widely used HiSoft's DevPac (GENS) assembler for the ZX Spectrum (and some other Z80-based computers) uses the # mark for hexadecimal numbers: #CAFE – Martin Maly Aug 17 '20 at 05:39
  • FWIW, BBC BASIC uses an ampersand (&) prefix for hexadecimal literals. – Andrew Morton Aug 17 '20 at 12:52
  • 1
    I suspect that finding what company or organisation that first used prefix $ for hexadecimal is possible. To find the reason why will be harder. That type of design reasons are seldom well documented. – UncleBod Aug 17 '20 at 13:37
  • 3
    @MartinMaly Use of # for hex numbers is still in very common usage today, e.g. in HTML or CSS. Most commonly it's used to designate colors, e.g. #FF0000 for red. – Darrel Hoffman Aug 17 '20 at 15:37
  • @DarrelHoffman: Color selection in HTML canvas is crazy. I am simultaneously bewildered at how browsers can quickly process the Javascript necessary to form a color string from an RGB value and then decode it, and the design methodology that would have made the use of such a complex sequence of operations necessary in the first place. – supercat Aug 17 '20 at 22:08
  • $ for hex numbers (and, BTW, # for immediates, which overlaps with the PDP-11) seems to be a convention first used by Motorola. – tofro Sep 23 '21 at 07:43
  • @dirkt, using 12H for hex would be ambiguous in a FORTRAN environment. It would normally indicate that the next 12 characters were part of a Holerith constant (a fore-runner of string types). –  Jun 21 '22 at 13:42

1 Answers1

29

Short Answer:

Motorola used it for their 6800 and MOS (6500) inherited it from Motorola. After all, the 6500 team members came out of the 6800 project so they were already used to it.

Long Answer:

If the 0x prefix clearly predates the 8-bit revolution,

It doesn't, really. Motorola used the $ prefix already with the 6800 of 1974. Unix had only recently (1973) been rewritten in C, which added the 0x convention around that time, and shown outside of AT&T.

then (1) why was $ adopted so widely?

Because of Motorola's 6800/02/09 line as well as MOS' 6500 series used in many lower-end micro (home) computers. Most notably by Acorn, Apple, Atari and Commodore. All of them were quite successful in the mass market. Naturally, everyone using them/writing software for these machines/CPUs would use its notation and create a strong sense for being the 'natural' way.

Later on, it got amplified by the popularity of the 68000 used, for example, with Atari ST and Commodore Amiga line of machines.

And the opposite, (2) having become ubiquitous for a whole generation of 8 bit programmers,

Now this does very much depend on your 'processor bubble', as it's only true for users of 65xx/68xx(x) based machines. Whoever grew up with an x80 (8080, 8085, Z80) or x86 based machine, like Altair (S100), Tandy TRS-80 and the whole MSX world, will disagree. They'll be quite firm in that a H suffix was the only valid way and everything else is quite exotic :))

why was it abruptly dropped?

It wasn't. There is no worldwide ruling body outclassing it. After all, using either prefix (or suffix) isn't inherent to hex code, but defined by the language used. Motorola/MOS assemblers want a $ prefix, Intel a H suffix, C a 0x prefix and others again want a more mathematics-like prefix of 16# (Ada) or 16r (Smalltalk).

The going out of style is thus more due x86 taking over and C bing the prime (low level) Language.

(Not that it matters, but I still use $ when commenting code or scribbling on dead trees.)

And so do many other (*3).

Bottom line: the language one uses defines the notation - and, as always, the first leaves the deepest impression.

Advantage of Prefix over Postfix

Classic mathematics uses a postfix notation of having the radix trailing a number. Which Intel followed with their nnnnH notation. For compiler writing, this brings the downside that a whole word (constant) has to be read first, before it could be decided how to interpret it. This means a buffer is needed holding the whole string, as it can only be converted after advancing until the postfix.

By using a prefix, it's clear from the beginning of a number sequence how to interpret the following characters. Thus there's no need to buffer (*2). This gives an advantage in parser design and does simplify the assembler a lot. This was especially helpful for fast creation of early cross assembler tools as first bootstrap.

Some History

  • Hex notation was rather uncommon in the early years. Instead, octal was the thing, as most machines were build to a multiple of 3 word size, as well as characters were usually handled as 6 bits.

  • Of the few machines/systems that very early on offered hex, many used various letters/symbols, like the last 6 in the alphabet UVWXYZ (*2), often even non-continuous.

  • IBM introduced a prefixed string format (X'nnnn') with the /360 in 1965

  • Datapoint used octal with a prefixed Zero

  • Intel's 4004 used hex with a suffix of h

  • Intel's 8008 used all octal in manuals and documentation, written as nnnO

  • By 1973, both assemblers were made to use the same B/O/H suffixes.

*1 - Caring for a few bytes of buffer might seam strange today, where the whole source is usually loaded into memory, but RAM was a scare resource back then. As a result, algorithms were preferred that could read data, like from paper tape, and directly work on each symbol read without buffering.

An optimal assembler allows to read any item a character at a time and process it right away with no need to look ahead. Using a prefix supports this.

*2 - A convention often used in engineering when needing symbols.

*3 - Here on RC.SE I try to use notation according to each topic, so $for 65/68 related, H for Intel, and so on...and when there is no clear relation, I'll fall back to /370 notation x'nn', as that was what I used most, despite having used $ first.

Raffzahn
  • 222,541
  • 22
  • 631
  • 918
  • 2
    I'm not convinced this answers the question. How did Motorola choose the $? – DrSheldon Aug 16 '20 at 13:57
  • 5
    @DrSheldon In my memory this starts with Motorola (and their engineers) - if you know more, I'd be glad to read and upvote your answer. Mine is about how it came to know and why it changes or not. Why a certain symbol was chosen is always hard to tell, at least unless there are reliable reports from that decision. The same question can be made why they did choose % for binary, @ for octal and ' for character. In the end it doesn't really matter which character it is. The important idea is to use prefix notation to simplify the parser. – Raffzahn Aug 16 '20 at 14:47
  • 1
    _“Most notably by Apple, Atari and Apple.”_  While Apple may well be important enough to list twice, this is missing a perfect opportunity to mention Acorn :-) – gidds Aug 16 '20 at 22:56
  • @gidds Damn, sorry. One shouldn't reorder entries. And yes, Acorn/BBC was, at least on the island, a quite notable influence. – Raffzahn Aug 16 '20 at 23:05
  • 4
    … and of course, BBC BASIC used & throughout, possibly inspired by MBASIC's &H – scruss Aug 17 '20 at 00:57
  • 1
    An annoyance with the Intel format is that it requires a leading zero for values whose first leading nybble would otherwise be A-F. – supercat Aug 17 '20 at 06:29
  • 11
    @supercat, exactly. And while we are at it, whoever invented leading 0 as the octal prefix should be shot. It's just mathematical nonsense that 012 must not be exactly equal to 12. – Zeus Aug 17 '20 at 08:04
  • 4
    Pascal (at least the Borland-dervied variants, not sure about others) uses $ too, though I don't know if and how that fits into the history. – Peter Green Aug 17 '20 at 13:23
  • 1
    @PeterGreen Borland (turbo) Pascal is of 1983, so way later. Although, being developed for Z80 first the selection of $ is a rather funny trait. Then again, it makes sense to go for a prefix notation if the goal is a small compiler. – Raffzahn Aug 17 '20 at 13:53
  • @Zeus: If I had my druthers, C and other C-inspired languages would add a proper octal notation (perhaps 0o123, 0q123, or 8x123, with the latter generalizing to any numeric base up to 36), and deprecate the use of a leading zero for octal, adding a directive to specify that such numbers should be accepted as octal, rejected outright, or accepted as decimal, with conforming implementations free to apply by default whichever of the first two treatments their users would find most helpful. – supercat Aug 17 '20 at 15:44
  • 1
    "In the end it doesn't really matter which character it is. The important idea is to use prefix notation to simplify the parser."

    I can't help but notice that $ is just above the 4 on my keyboard. Perhaps it is meant to suggest 4-bit nibbles?

     – phs Aug 18 '20 at 03:16
  • 2
    @phs I wouln'd try to hard to find a reasoning. Of the available ASCII characters, most are already taken for other use (Letters, Numbers, arithmetic and other markers), are parentesis, are punctuation that would look rather ridiculous, or not available in all ISO 646 variants. This leaves essentially only five '!@$%&' to pick the three needed from. So Motorola ended up using '%@$' as numeric prefixes. – Raffzahn Aug 18 '20 at 08:27
  • Does anybody remember what DEC used? They would have preceded any micros. – Mark Ransom Aug 24 '20 at 16:41
  • 1
    @supercat D which is a C derived language removed completely octal from the language. It is now only imlemented as a library template type. D being very strong with templates and compile time evaluation, it has absolutely no impact on the runtime if you need it (except for Posix file rights and 8080 instruction set encoding I don't see any need for octal anyway). – Patrick Schlüter Aug 26 '20 at 11:59
  • @PatrickSchlüter: I don't use octal often, but there are times when I do use it deliberately because something will end up with a repeating three-bit pattern. I think it's easier e.g. to recognize the repeating 011 pattern within 0q133333 than within 0xB6DB. What would perhaps be even nicer would be if a language had four characters that were not be used as binary operators that could be used to mark base 2, 4, 8, or 16, so as to allow constants to be assembled from 1, 2, 3, and 4 bit fields so as to nicely match the way chip vendors lay out mixtures of different field widths. – supercat Aug 26 '20 at 14:42
  • @MarkRansom DEC introduced(?) the "#" for immediates, which was adopted by Motorola as well. The PDP-11, being essentially an "octal" machine, doesn't really have a notion for hexadecimal numbers (this also seems to be the reason that leading zeroes mark an octal number in C, BTW - It probably seemed natural for a programmer used to the PDP-11). – tofro Sep 23 '21 at 07:48
  • @Raffzahn Actually, $ is a character that is not available in all ISO 646 variants. – TeaRex Sep 23 '21 at 08:54
  • 1
    @TeaRex You mean the $ glyph was not assigned - right? - as the code point at $24 was of always assigned to some usable glyph. So that's what was to be typed and seen when printed. Keep in mind, back then it was never about glyphs but codes. No code translation happened anywhere. Most programs were simply not made to even notice any difference. IIRC, $ was assigned in essentially all 646 variants used during the 1970s, except for IRV (related) which used that coin symbol. Works as well. – Raffzahn Sep 23 '21 at 11:26
  • @Raffzahn Borland (Turbo) Pascal was far from the first Pascal compiler. I used it in the 1970's on a Control Data mainframe. – Mark Ransom Sep 23 '21 at 15:40
  • @MarkRansom And? So did I on /370 machines. Never said otherwise. – Raffzahn Sep 23 '21 at 15:52
  • @Raffzahn just saying that your remark to Peter Green was a bit off the mark. While Turbo Pascal may date from 1983, the $ convention was probably adopted a lot earlier. Unfortunately I don't have a Pascal manual from those days to confirm. – Mark Ransom Sep 23 '21 at 16:07
  • 1
    ISO Standard Pascal does not have any hexadecimal literal notation, $ or otherwise. As far as I know that was a Borland innovation. – Mark Reed Nov 02 '23 at 21:44