Ken Shirriff writes about restoring and reverse-engineering vintage computers, especially the IBM 1401, along with early compilers and hardware.
HN commenters praise the IBM 1401 animations as a learning resource, and link the 1401 emulator and the Fortran compiler pages.
It's all about memory devices.
IBM had been doing arithmetic electromechanically for decades, and mechanical digital calculators go back centuries. It was clear by the 1940s that you could do arithmetic with vacuum tubes; IBM produced the IBM 603 Electronic Multiplier[1] as a product in 1946, and they'd been working on that before WWII. It was clear that you could have programmed sequence control of arithmetic, if you could figure out how to store and access the program. But nobody had a cheap random-access storage device yet.
There were lots of ideas, most of them marginal. IBM had been using plugboards for decades. Atanasoff used capacitors, but had to use a mechanical drum type rotary switch to connect to them. The ENIAC used tubes, plugboards, and rotary switches. The Manchester Baby used a Williams tube, a CRT-derived storage device, but they only got 32 words of 32 bits out of it. Bigger Williams tube machines were built later, but the size was huge for the data stored. EDVAC used mercury tank delay lines, as did UNIVAC I. Metal delay lines, long metal rods with transducers at each end, were tried. Some low-end computers with drum main memory were built. Of these, only the Williams tube was random access.
In 1951, MIT built Whirlwind, the first computer with magnetic core memory. This was the first good memory component. Good speed, true random access, more compact than the alternatives. But not cheap. Core memory was very expensive to manufacture (a million dolars…
In this context I'm wondering about the theoretical possibilities rather than the practical risk; I think the analysis that I'm referring to assumed the probability was negligible in practice (or can be made negligible in practice), so the question is whether it is still true that there is some analog input (even from a key on the keyboard) that in principle makes the machine misbehave even though no physically realistic process can typically actually generate that input.
The debouncing examples in the article you linked to don't seem to eliminate the risk in a theoretical sense. The RC circuit is taking an analog function of an analog function to apply some smoothing and significantly decrease the effects of transients on the observed voltage at the ADC, increasing the proportion of the time it will spend in a well-defined range if driven by a noisy switch. There must still be some set of analog inputs that would keep the voltage in an ambiguous range, though. The SR latch can itself experience metastability. (And the software solution should be right out, because it starts from the assumption that each individual digital measurement of the switch state has produced a well-defined binary value that can be safely used as input to expressions and functions at the software level.)
Wikipedia says that chaining latches together merely (dramatically) reduces the probability of this behavior, rather than actually eliminating it, because each latch could in principle (though…
The techniques in the Dragon Book are scientific and let the run-of-the-mill systems programmers build compilers consistently. Before that the field was fragmented, formal grammar not well understood, and compilers faced difficult hardware constraints. So each compiler was hand built, often by exceptional developers, and techniques used were all over the place.
This one is legendary
https://ibm-1401.info/1401-IBM-Systems-Journal-FORTRAN.html
which is sliced into a huge number of passes so the compiler could fit inside a tiny memory footprint (e.g. a "mainframe" with the memory capacity of an Altair)
Another interesting if not so high performance compiler was the first FORTRAN IV compiler for the PDP-11 which used a stack machine instead of register allocation . DEC wasn't interested in making the best possible FORTRAN but instead in making a product that was competitive on the market so they started out with that, then developed a floating point processor designed specifically for that compiler, and then evolved from there.
Although machines from the IBM 360 were broadly competitive they varied from 4k of 16M of RAM and core and had very different implementations which varied in performance by orders of magnitude. Back then it was common for a hardware vendor to publish several compilers for a machine aimed at different balances of compile time and run time. It's not like we don't have some of that now, but anybody who was developing compilers in 1970 was…
I started programming around 1967-1968. In my high school, there was an old keypunch machine used for school administration purposes. I had a friend that was able to submit any program I keypunched to the school district's IBM computer; I never saw the computer but it's likely that it was something like an IBM 1130. My my friend would bring the output back a couple of days later; so fixing even one typo required a few days.
This old keypunch machine was a model 026, not the much nicer model 029 that was ubiquitous while I was in college. The 026 had a very basic keyboard, see [1], one could punch the columnar code for the upper case letters and numerals along with a handful of symbols: #@,%$./ and space. This isn't enough to even program in early FORTRAN, the language I was trying to use.
To type say an equals sign one had to use the multi-punch key that allowed punching a combination of the basic symbols that would properly encode the equals sign. It was slow going. One mistake and the card (corresponding to a line of code) was ruined and had to be redone.
I had just finished reading a book on solving linear programming problems, which come up often in operations research, using the simplex algorithm (I still have this book too). Naturally, I decided that that would be the first program I ever wrote. That definitely wasn't the best "hello world" program to try first. I wish I still had a listing of that program; it would be good for a few laughs.
The first working…
The 1401 was designed as a stored-program alternative to IBM's never-shipped WWAM World Wide Accounting Machine. WWAM was designed in IBM Europe in 1955. WWAM was to be a low-cost plugboard-programmed transistor computer to handle the same card tasks as IBM's existing and popular relay-based punch-card accounting equipment. WWAM was IBM's reaction to the threat of losing its many punch-card customers to a low-cost computer Gamma 3 made by French company Bull. 1401 uses the same ALU etc as WWAM, but with newer standard circuit modules. Both use arbitrary-length decimal fields, just like the punch card machines before them.
Several incompatible IBM machines in the 7000 series also used arbitrary length decimal numbers, not binary words.
At Burroughs, the "Medium Systems" B2500-B4800 series were similarly decimal only with arbitrary length numbers. They got extended with fixed-length decimal accumulator and index registers, and competed with IBM's mid range 360 and 4331 systems. Building a decimal-addressed memory using binary-addressed chips got increasingly kludgy.
https://ibm-1401.info/1401Origins.html#Motivations-1
It's actually bi-quinary. Inside the ALU, numbers are represented by two fields: an odd/even field with two dedicated signals for odd and even, and a field of 5 quinary "Q#" signals for 0/1, 2/3, 4/5, 6/7, 8/9. So it's a 7-bit representation as in Q8-Q6-Q4-Q2-Q0-B1-B0. There are two separate adders, one for each field, with borrows and overflow handled after partial results. Apparently, this helps with error checking in the ALU with limited circuitry. (There's exactly one Q# bit and exactly one B# bit high at any time. E.g., `0` is Q0 high and B0 high, `9` is Q8 and B1 high.) Negative numbers are represented in 9's complement.
Values are converted from BCD to bi-quinary as they enter the adder and the result is translated back again. So, to the programmer, it's still a character-oriented machine and the ALU operates on a single character (= decimal digit) a time. (Apparently, IBM didn't even communicate any of this.)
Ken Shirriff has you covered on this, as well: http://www.righto.com/2015/10/qui-binary-arithmetic-how-1960s-ibm.html
See also for a bit of history on this: https://ibm-1401.info/qui-binary.html