Another Tale of IBM I (AS/400) Hacking (2022) | Hacker News Reader

Another Tale of IBM I (AS/400) Hacking (2022)

blog.silentsignal.eu

61 pointslouislang13 comments

One interesting thing about the AS/400 is that all or almost all of the userland programs were distributed/stored in TIMI (Technology-Independent Machine Interface) format. It's a bytecode that gets AoT-compiled to native code when performing the AS/400 equivalent of setting the executable bit. This allowed IBM to go through several generations of incompatible CPUs without customers visibly needing to recompile binaries. TIMI was a remarkable amount of forward thinking on IBM's part.

These days, the Android Runtime does something similar at application installation time, but TIMI was quite a bit ahead of its time. As far as I know, IBM never added ART-like continuous profiling and re-optimization features to the TIMI runtime, but it would be technically possible.

Quite a few systems did that, check also Burroughs B5000, still sold as Unisys ClearPath MCP, Xerox PARC workstation OS (the bytecode was basically "Assembly" as the CPUs were microcoded and loaded on boot), the whole P-Code ecosystem and so forth.

Another thing where IBM innovated, their compiler toolchain for PL/8 used for RISC research, was quite similar to how LLVM was designed decades later.

One of the great joys of retrocomputing is to learn these ”forgotten” technologies very few people talk about.

It’s funny that 8-bit computers from Atari and Commodore placed storage on daisy-chain serial buses with the drives running the filesystem management on their own CPUs.

I wonder how much data processing one could do back then by loading small programs in the drive RAM to, say, deduplicate or sort lines in a text file.

I used to work with a guy ("R.D.") who was one of the earliest COBOL compiler developers, who said that the primary COBOL compiler running on a massively fast (and expensive) IBM mainframe in the 1960s was horrifically slow -- so he and fellow tiger-team workers implemented their own compiler, generating instructions for an imaginary COBOL-specific CPU running on an emulator.

However, ultimately this was running on one of the I/O co-processors for that same mainframe, which had only about 10 simplistic instructions, so they implemented an emulator of a more usable CPU on that I/O co-processor, and then there was some extra complexity caused by the very limited RAM on the co-processor, so they had some extra layers of emulation that were swapped in and out, so the whole emulation stack was at minimum 3 layers deep and got worse from there.

The punchline is that the resulting COBOL compiler with many layers of emulation ran faster on the pathetically small and slow I/O processor than the primary COBOL did on the mainframe without emulation.

This appeared to be simply because the I/O processor tiger team understood efficiency tradeoffs, while the mainframe COBOL team took the attitude that the mainframe was infinitely fast and had infinite memory.

There are multiple morals to that; one of the more obvious ones is that nothing stays fast if you fritter it away by actively not caring about speed -- something which comes up over and over in today's world.

Another one is that peripheral processors are cool, both on big iron and on tiny iron. :) But see Ivan Sutherland's Wheel of Reincarnation regarding that. [0] [1] [2]

[0] http://catb.org/jargon/html/W/wheel-of-reincarnation.html

[1] http://cva.stanford.edu/classes/cs99s/papers/myer-sutherland...

[2] https://news.ycombinator.com/item?id=21133389

I heard of one program for the C-64 with two drives. You load the code into the drives, and it would copy a disk without the C-64 being on.

Not only could you that, you could also have program running on the disk drive send a text file to the printer. so you could print without the computer if you could write the small 6502 program you needed to install into the disk drive.

Wouldn't it be cool if our modern computers, with their couple dozen smaller computers pretending they aren't there, could do these things in a supported and portable way?

Imagine I want to select data from a Parquet file and I could load a program into the storage device to only return me the entities I want instead of reading data into main memory and have my CPU do that?

Pretty sure Fast Hack'em could do this.

Probably not exactly what you had in mind, but there were things like

https://www.c64-wiki.com/wiki/SpeedDOS which went into that direction.

Was mostly a hardware modification to make the serial bus parallel, though.

But it did extend some commands to handle floppies and their contents, running on both sides.

You can get a feel of AS/400 UI at https://pub400.com/

unable to signup, sadly.

> Currently there are issues sending mail to hotmail, gmail and yahoo (they use outdated nospam-block lists). Please use a different provider.

protonmail address doesnt seem to work either.

For context --- and from 1992 (!) --- here is a delightfully of-its-time explanatory video created by IBM UK about AS/400 https://www.youtube.com/watch?v=5pY6Xxptp9A

The emperor's clothes are made of unobtanium thread, and are thus covering the emperor's naughty bits.

Reply on news.ycombinator.com