11

I've had an IBM 9404 B-10 for some time and I'm curious about its assembly language. I'm fully aware the AS lines were designed with portability in mind as much IBM didn't seem to provide assembly language references as they did with the S/36 and S/38. I've searched for some time but couldn't find it even in archive.org.

Therefore, I would like to ask if someone had some sort of reference about its opcodes and mnemonics, as well as basic program structure.

Improve this question
4
  • 2
    The problem is that the AS/400 implements a "VM" (virtual machine) interface much like many other IBM systems and they did not support program development against the "native" ISA. Of course this allowed IBM to vary the machine's architecture (at they did when they transitioned to the POWER ISA) without impacting application software.
    – jwh20
    Jan 7 at 11:33
  • Yes, that's what I refering to with portability. It's been nearly 35 years since the AS were first deployed and it still seems nobody knows the underlying system under the VM.
    – Borg Drone
    Jan 7 at 13:02
  • 4
    I'm not sure I agree with "nobody" here but the point is the underlying ISA did not matter. Yes, IBM knows it since they had to write compilers and such for it but the publicly-documented ISA is the virtual machine's. IBM refers to the native ISA as "microcode" in the same way that current CPUs have undocumented microcode that implements the public ISA. It's my understanding that the IBM System/38 is very similar to the original AS/400 ISA. You might do some research on that system and see what you can find out.
    – jwh20
    Jan 7 at 14:01
  • Well, it is the micro code here. The base idea about AS/400repeatingt the /360's single ISA platform for mid size. This time leaving out the over and over again run time translation of ISA code by hardware. One might think of it as a continuum between modern x86, translating each instruction on the fly, via the Transmeta way of doing so as well in the CPU but caching the result in memory for some time during program run, to IMPI further reducing resource need by doing that translation only a single time and caching the result in the file system.
    – Raffzahn
    Aug 22 at 13:08

2 Answers 2

Reset to default
7

Compilers used outside of IBM (and, most likely, the majority of those inside IBM) did not need to know anything at all about IMPI (internal micro-programmed interface, which is what I assume you mean by the "opcodes and mnemonics").

Instead they worked with the platform-independent TIMI (technology-independent machine interface). Even IBM's OS code was written and run this way.

The only place IMPI had to be known was in the program loader or execution engine of IBM i. This was responsible for translating the TIMI into a suitable format for the platform (be that IMPI or any other future choice) and caching it with the original program. This would happen either:

  • the first time it was run; or
  • whenever it was detected to be running on a different platform to the cached code.

If anyone had managed to get a hold of the IMPI specification and figured out a way to generate that directly, their program would cease to run on a platform change as the "IMPI" would be different. Unless, of course, they'd generated the TIMI as well in which case the IMPI generation is totally unnecessary (i.e., it would be done as needed, when running the program).

I'd be surprised if anyone outside of a very small subset of the IBM i group (the people responsible for SLIC, the system licensed internal code) could generate IMPI directly.

The use of this translation scheme meant that, even though the IMPI on a 9404 is likely to be vastly different to the "IMPI" on IBM's latest hardware, the TIMI code of bygone days will continue to run just fine on new platforms, without ever having to be recompiled (just one translation the first time it runs on that new platform).

That was, after all, the intent of having the split(1), giving the ability to replace the underlying hardware in its entirety without needing to re-compile all the applications that ran on it. Instead, the platform simply needed a specific layer that would first throw away any existing IMPI code if it was for a different platform, then generate IMPI code from TIMI (if the former did not exist).

(1) When IBM decided to "bet the farm" on the IBM 360 architecture, this was, in part, to get away from the situation where both:

  • they had to develop a large amount of system software every time they introduced a new machine; and
  • their customers had to rewrite their applications similarly.

That cost them quite a bit of money so almost certainly influenced the requirements behind the AS/400 as well.

Improve this answer
2
  • 1
    In the end it's the idea of byte code and just in time compilation (improved by long time caching and a fine tuned OS interface) many others tried later and made a big fuzz about :))
    – Raffzahn
    Aug 21 at 13:35
  • 3
    @Raffzahn Once again, IBM got there first.
    – Wayne Conrad
    Aug 21 at 17:27
4

This is for the System/38, but it should be similar, and you may be able to find AS/400 versions.

GA21-9331-1_System_38_Functional_Reference_Manual_Feb81 https://archive.org/details/bitsavers_ibmsystem3unctionalReferenceManualFeb81_34128808

SC21-9037-3 IBM System/38 Internal Microprogramming Instructions, Formats, and Functions Reference Manual. https://archive.org/details/bitsavers_ibmsystem338InternalMicroprogrammingInstructionsFo_12606509

Improve this answer
5
  • Maybe not. If this is below the TIMI then I expect that it won't be the same. The O/S was similar but the hardware was very different. The transition from S/38 to AS/400 was the first proof of the value of the system. Just restore a S/38 program onto an AS/400 and run it. Behindvthe scenes, the IMPI was dumped and rebuilt.
    – badjohn
    Oct 10 at 8:46
  • 1
    But interesting anyway.
    – badjohn
    Oct 10 at 8:46
  • If you're talking about the CISC AS/400s, the CISC AS/400 is a System/38; if you're talking about the RISC AS/400s, then what you said. I once attended a presentation given by Frank Soltis, in which he said that less than 0.1% of the operating system code had to be changed for the move to RISC. BTW—I compiled a program in 1990 that's currently running on a Power System with IBM i. It's never been recompiled: Just moved from one machine to another to another.
    – tim.smith
    Oct 11 at 21:35
  • I have to disagree. The original CISC AS/400 can reasonably be regarded as a better S/38 but the hardware was very different. Programs needed to go through conversion. IBM did not support removing observability on the S/38 but some 3rd party products offered it. If one of these had been used then a restore of a S/38 program to the AS/400 would fail. I got a preview of the AS/400 before launch and tested my company's S/38 software on the AS/400. However, if observability has not been removed then an S/38 program could still be running today. I have also met Frank.
    – badjohn
    Oct 12 at 11:55
  • The conversion was automatic. You did not need to request it. It just happened so it would be easy to not notice. I don't recall that CISC to RISC story but it is believable. Most of the O/S was above the TIMI layer and so it also was protected from hardware change.
    – badjohn
    Oct 12 at 11:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .