Ken Shirriff

Part of why I love the IBM 1401 is because of how mechanical it is. So much of what the computer does is done in hardware. You can see and feel the machine running. If you are able, I highly recommend visiting the 1401 exhibit at the Computer History Museum: http://ibm-1401.info/#how-to-visit The "ibm-1401.info" site is maintained by the IBM 1401 restoration team. It contains nearly everything you'd ever want to know about the machine. It's a pretty dense website, so I suggest visiting these links first: http://ibm-1401.info/1401GuidePosterV9.html http://ibm-1401.info/IBM1401_IEEE_SSCS_Mag_Jan2010-100DPI.pdf I also really enjoyed learning how to program the 1401. I wrote instructions on how write a "Hello world" in the the "ROPE" simulator environment: https://github.com/jpf/ROPE

These animated cases are an incredible learning resource. A picture is worth a thousand words but a cool animation is worth a thousand pictures. I spent years repairing IBM rotating chain mainframe printers (1403) in the field in the 80s, and I never really understood what I was doing. When I saw Ken Shirriff's animation of how hammer timing works, I instantly got it. http://ibm-1401.info/KenShirriff-1403Animation.html

The IBM 1401 emulator we use is ROPE: http://ibm-1401.info/#1401-Software The Computer History Museum in Mountain View, CA does demos of the real 1401 (at least until the coronavirus hit), so once things open up again, anyone who is nearby should check it out.

Great! It might be interesting to code this in FORTRAN for the 63-phase compiler for the 1401 [1]. I wonder how the generated code would compare? [1] http://ibm-1401.info/1401-FORTRAN-Illustrated.html

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…

When I started at IBM back in the 80s in NZ, there were plenty of 1403 printers still in operation, though no 1401 CPUs. Since they were old even then, and NZ was something of a computing backwater (on a training course I met a guy who's territory of 3 or 4 floors of the world trade center had more machines than my territory of half of the North Island) there were no formal training courses on them, and I was on my own with the manuals and the insights of the gray beards in the company lunch room. It wasn't until I found Ken Shirrif's magnificent animated explainer https://ibm-1401.info/KenShirriff-1403Animation.html many decades later that I really understood how the machines I had been fixing worked.

> a bygone era where computers executed 1 instruction per cycle without pipelining or prediction 1 instruction per cycle? What luxury bygone era did you grow up in? Wikipedia tells me the algorithm is from 1962 on an IBM 1401 (https://en.wikipedia.org/wiki/Bresenham's_line_algorithm#History) That definitely didn’t have many single cycle instructions. Skimming https://ibm-1401.info/A24-6447-0_1401_1460_Instruction_and_Timing_Summ… I couldn’t find any. Certainly, in the era of 8-bit CPUs like Z80 and 6502 programmers would have been lyric about “1 instruction per cycle” Actually, did any CPU ever “execute 1 instruction per cycle without pipelining or prediction” (or, slightly looser “had fixed time instructions without pipelining or prediction”)? RISC introduced fixed time instructions, but also pipelining.

Whatever you do, do not read the META II paper, especially not Figure 5, which is the META II compiler written in itself. You may lose two months of your life: http://www.ibm-1401.info/Meta-II-schorre.pdf :)

Meta II by Dewey Schorre http://www.ibm-1401.info/Meta-II-schorre.pdf

Sparkler Filters [1] in Conroe, TX is still using an IBM 402 for daily operations and bookkeeping. [1] http://ibm-1401.info/402.html#SparkleFilters https://www.youtube.com/watch?v=pxCZ35y3O04

Ahh..META II [1]. This is awesome. Was just mentioned again in the "Joe Armstrong interviewing Alan Kay" talk [2][3]. One of Alan's favourite papers. Joe: "Dan said if you look at this, you will lose a month of your life. And I did" Or words to that effect. Also the basis for OMeta[4]. I have to admit I've been avoiding it so far in order not to get diverted from architectural insights[5] but this may just be accessible enough to dive on in. [1] http://www.ibm-1401.info/Meta-II-schorre.pdf [2] https://www.youtube.com/watch?v=fhOHn9TClXY [3] https://news.ycombinator.com/item?id=13033299 [4] http://www.tinlizzie.org/ometa/ [5] http://objective.st

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

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

I really liked what was done in STEPS project. I learned a lot from their repors. For example, this Ian Piumarta's paper is absolutely beautiful [1]. I also spent a lot of time learning oMeta [3] system by Alessandro Warth. And, honestly, now I see nothing really new in Ohm. Basically, it's just some tweaking of the same tech. Moreover, Ohm was made for isolated parsing task. For me it's a step back. My point is that the parsing alone is not very interesting thing, for making DSLs you need to have other tools too. In the Ian Piumarta's paper we had a minimalistic program transformation system [2]. Remember original META II [4]? It was a compiler-compiler (metacompiler), not just a parser generator. I'm really curious to know why the authors decided this time to limit themselves by only parsing. [1] http://www.vpri.org/pdf/tr2010003_PEG.pdf [2] https://en.wikipedia.org/wiki/List_of_program_transformation_systems [3] http://www.vpri.org/pdf/tr2008003_experimenting.pdf [4] http://www.ibm-1401.info/Meta-II-schorre.pdf

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…

META-II paper: http://ibm-1401.info/Meta-II-schorre.pdf