• Please review our updated Terms and Rules here

Disassembly of IBM System/360 (attempt)

voidstar78 said:
Yep, I hadn’t seen an S3 analysis yet, so I was gearing up with practice on what we knew so far on the S370 side. Actually I wasn’t certain on S360 vs S370 content - and was wondering if we could narrow it down to a more specific model ( and maybe find the original source that it came from ).

So if it’s S370 based then it’s some model 150 series? Also weird to think of a “weaker system” emulating a more powerful system ( ie 16bit PALM emulating 32bit mainframe ), but maybe that just shows how arbitrary categorizing the “bit-ness” of a system is. ( I think we talked before how the 1-bit Datapoint could still do a good amount of general purpose stuff )
Click to expand...
Most S/360 code runs on a S/370. Most S/370 code runs on any S/370. The whole point of S/360 was that any code could be ported to a bigger machine without change. The exception was the 360/20 but most folks don't consider that a S/360. Even if you had floating point code on a machine without floating point hardware there were simulators you could load to allow it to run, so its pretty pointless trying to decide which model an arbitrary piece of code came from.

The ability to emulate another system is a fundamental of property of any Turing Complete computer. So if a computer is Turing Complete and basically when we use the word computer in the modern sense its really shorthand for "Turing Complete Computer" it can emulate any other Turing Complete computer. Of course this assumes sufficient store is available and the result might be slow but it will eventually work
 
FYI, in case the person who started the thread doesn't know about it
computerhistory.org

The APL Programming Language Source Code - CHM

Thousands of programming languages were invented in the first 50 years of the age of computing. Many of them were similar, and many followed a traditional, evolutionary path from their predecessors. What eventually became APL was first a mathematical notation, not as a computer programming language.
computerhistory.org computerhistory.org
 
Narrowing down the "vintage" or Model used might trace or confirm some of the people involved. But true, the particular assembler that was used could target quite a different system than what the development was done on.

Example: In the APL source mentioned, it uses the mnemonic "BNE" which I didn't find in the S/360 principles of operations. Then I didn't find it in the S/370 principles of operations either. I found it later in "extended mnemonics" of the S/370 (and all of those extended mnemonics map to the "BC" op code, branch on condition - which is present on the S/360). Certainly assemblers evolved to have macros to help express certain things more easily, while not necessarily relying on any new opcodes. But it tells us that to compile that code, you'd have to find a post-1970 system running OS/VS or VM/370 (but the resulting binary might work on a pre-1970 S/360).

In the comments of the source are also notes about possible timing issues on the Model 40 (unclear to me if related to realtime clock or file read/write section), and something about "combat imprecise interrupts on the model 91".

Neat that PUNCH is a mnomonic.

What are the number sequences at the right side of the assembly? Like 87660000, 15750000, 98800000, 11970000? I don't think it's the corresponding object code.
 
The IBM has several papers on the development of APL. The ones from 1973 can be downloaded from IEEE. "Implementation of a High Level Language Machine" describes work done on a 360 Model 25. "Direct Execution of APL on an IBM/370" from 1973 details the development of APL/CMS on a 370 Model 145. The APL used by the 5100 is typically listed as APL.SV, a slightly improved version of the original APL/360. The paper describing that development is not available for free download so I don't know if it lists the models used.
 
voidstar78 said:
Example: In the APL source mentioned, it uses the mnemonic "BNE" which I didn't find in the S/360 principles of operations. Then I didn't find it in the S/370 principles of operations either. I found it later in "extended mnemonics" of the S/370 (and all of those extended mnemonics map to the "BC" op code, branch on condition - which is present on the S/360). Certainly assemblers evolved to have macros to help express certain things more easily, while not necessarily relying on any new opcodes. But it tells us that to compile that code, you'd have to find a post-1970 system running OS/VS or VM/370 (but the resulting binary might work on a pre-1970 S/360).

In the comments of the source are also notes about possible timing issues on the Model 40 (unclear to me if related to realtime clock or file read/write section), and something about "combat imprecise interrupts on the model 91".
Click to expand...

Ok so BNE isn't in the POP but its just short hand for a conditional branch to a particular condition code. To compile it you don't need a system running OS/VS or VM/370 you simply need a BNE macro. The code will run on a S/360. If you check


you will find that this assembler both runs on S/360 and understands the BNE extended op code. The imprecise interrupts on the model 91 were a PIA.

S/360 stand for 360 degress so generally every model ran every bit of code...
 
Well, BNE was just one example - towards the end of the code, there is stuff about multi-user and file access permissions, so there may be other "OS related stuff" in there (true, those concepts were also in the earlier pre-1970 APL/360).

The IBM 5100 APL manual mentions quite a bit about shared variables, so it might be the subsequent 1973 IBM APL.SV that was use as their baseline.

It's interesting that on some of these systems, even NOP is actually a "pseudo-code" macro to some other benign instruction.
 
voidstar78 said:
Well, BNE was just one example - towards the end of the code, there is stuff about multi-user and file access permissions, so there may be other "OS related stuff" in there (true, those concepts were also in the earlier pre-1970 APL/360).

The IBM 5100 APL manual mentions quite a bit about shared variables, so it might be the subsequent 1973 IBM APL.SV that was use as their baseline.

It's interesting that on some of these systems, even NOP is actually a "pseudo-code" macro to some other benign instruction.
Click to expand...
The OS specific stuff probably isn't OS specific either. Code written for the earliest operating system still runs on the latest. So on a S/360 you probably ran OS/MFT to start with, or OS/MVT if it was a big machine. On a 370 you could run OS/VS1 or OS/VS2 which became MVS, MVS/SP and then MVS/XA etc. but again user mode code from MFT still runs on the latest "Z" boxes. Whilst I don't think this happens now, many sites ran the MFT compilers under later versions of OS (and on VM/CMS, which includes MFT emulation) as these were "public domain" whereas the later compilers had to be paid for.
 
voidstar78 said:
NOTE: This code *should be* related to an APL parser for the S360. Anyone know which S360 models supported APL?
(the reason I don't think it is a Model 20 is because I think this code was late 1960s, and the reason I don't think it was a Model 40 is something gave me the impression that the Model 40 had a more limited instruction set -- but I could be wrong on both points)
Click to expand...
According to pdf page 40 of this document, APL\360 could run on the Model 2040H, ie. the Model 40 CPU
http://www.bitsavers.org/pdf/ibm/apl/GH20-0850-1_APL_360_OS_DOS_General_Information_Manual_Dec70.pdf

And on page 13 of the APL under MVT Users Manual, page 13, it shows the APL keyboard for the IBM 1052-7 printer keyboard.
https://wotho.ethz.ch/mvt4apl-2.00/users_manual.pdf

Now I am racking my brain but unfortunately remember where I saw a 360 document with a list of what variants of the 1052 were standard for each 360 CPU console (ie. varying switches and buttons), but feel fairly certain that the 2040 / Model 40's console was usually the -7 which could have a 988 PTT/BCD APL typeball on it.
 
1944GPW said:
According to pdf page 40 of this document, APL\360 could run on the Model 2040H, ie. the Model 40 CPU
http://www.bitsavers.org/pdf/ibm/apl/GH20-0850-1_APL_360_OS_DOS_General_Information_Manual_Dec70.pdf

And on page 13 of the APL under MVT Users Manual, page 13, it shows the APL keyboard for the IBM 1052-7 printer keyboard.
https://wotho.ethz.ch/mvt4apl-2.00/users_manual.pdf

Now I am racking my brain but unfortunately remember where I saw a 360 document with a list of what variants of the 1052 were standard for each 360 CPU console (ie. varying switches and buttons), but feel fairly certain that the 2040 / Model 40's console was usually the -7 which could have a 988 PTT/BCD APL typeball on it.
Click to expand...
If you consult the 1968 manual :-


it says you need a 27xx terminal control unit. This is as expected as it was multi-user with a cut down DOS and the console would be needed for the OS.
As you can see it says it will run on anything from a 40 upwards, including a 44 with the feature to emulate the missing instruction.

I only ever used APL under MTS on a 360/67 at Newcastle Upon Tyne University. Great fun....

1683971812284.png
 
Thanks gugm that makes perfect sense that the 1052 console would be left as-is for critically operating the machine. I did see a further remark on pdf page 6 of the APL\360 DOS System Generation Manual stating the minimum configuration of a 2040 with 192K memory, 1052-7, reader, punch, 3x 2311, 2400 and the 2701/2/3 you mentioned, plus terminals.
I have my Dad's green 360 reference card in front of me at the moment and it has a pile of instructions crossed out and annotated in ballpoint, with '2044' added at the top. I can only suppose as a Mod 40 specialist/CE Instructor he crossed paths with a Model 44 at some point.
 
Here is the jump vector table for the S/360 opcodes supported on the IBM 5110. This all looks good (the cells in blue-ish are just ones that repeat more than once, implying cases where some opcodes are implemented in the same way). The red cells are ones that appear to be not supported (they all jump to the same implementation that is essentially a "bad or unsupported instruction" call) - they didn't need to emulate the entire S/360 system, just enough to perform the APL support (constrained also by how many ROS chips they could fit into the portable system).

Two opcodes 0D and FF seem to be "undocumented" in the S/360 manuals that I could find at the time. Is anyone familiar with an S/360 Model or variant that supported 0D or FF as an opcode? (edit: found docs on 0D which are saying "Model 67" only)

1685859570867.png




I then did the same thing for the IBM 5100, where the jump vector table is at the very end of its APL NX ROS. "added" means support for that opcode was added in the subsequent IBM 5110 system. "removed" means a jump location for that opcode was no longer present in the IBM 5110 - i.e. they had code to support it, but it apparently got removed (maybe just to make space in the ROS chips for the new codes they had added support for). ("agree" means in the vector table for both the 5100/5110, they both "agree" it wasn't an opcode that needed to be supported and didn't need to be implemented in the emulation.

The same two "undocumented opcodes" 0D and FF have valid jump offsets in this table just like the 5110, so that's interesting. (in that it wasn't something added post 1975)

But what REALLY stands out to me: opcode 50 isn't pointing to a valid jump address in this table (as it does in the 5110). For the S/360, I think this opcode 50 (hex) was a rather important ST (store?) opcode - and what's unsettling is that the APL NX for the 5100 does appears to invoke that opcode (or at least it is present). I don't play with the APL stuff very much even in the emulator -- although it is supported, there isn't a convenient way to input the APL keystrokes (that's on a todo-list to improve in the emulator someday). But my point is, I haven't verified which addresses or code portion of the APL NX actually get emulated (as I have done on the BASIC side of things). It could be the portion containing the opcode 50 aren't actually being used (at least, those portions in the IBM 5100) - but given limited room for ROS chips, I don't think they'd put much wasted code in there. OR, there is something wrong in this analysis. But aside from this concern, everything else lines up very well between these two vector tables.



1685859764454.png
 
Last edited:
Ah, 0D == BASR just missed it in the reference I was using at the time. That just leaves FF, which I suspect is probably just a placeholder handler.
 
You must log in or register to reply here.
Back
Top