johnl@iecc.cambridge.ma.us (John R. Levine) (01/08/91)
In article <44558@mips.mips.COM> wje@redwood.mips.com (William J. Earl) writes: >In article <1991Jan04.205635.16420@iecc.cambridge.ma.us>, I wrote: >> The [360/20] was a strange case, it was a desk-sized machine whose >> architecture was an almost compatible subset of the larger machines >> although the I/O was entirely different. > The 20 was a bit more than "desk-sized." It was more like "Xerox >7000 series copier-sized," and it was not really compatible, in that it >would not run any non-trivial S/360 program. You must have a smaller desk than mine, it was indeed about the same size as a large copying machine. But the instruction set was indeed an almost compatible subset of the full 360, and it was not hard to write some 360/20 code that would work unmodified, except for I/O, on larger machines. You couldn't go the other way, the 360/20 provided a rather small subset. To achieve the subset compatibility, IBM did some interesting hackery. The 360 line had (still has in its 390, 43xx, and 30xx incarnations) 32 bit words and 16 32-bit registers. The 360/20 had 8 16-bit registers numbered from 8 to 15. Registers 0 through 7 didn't really exist. 360s compute addresses by adding a 12-bit displacement in the instruction to the contents of a base register, with the base register number being immediately to the left of the displacement in the instruction. If the high bit of the base register was a zero on the 360/20, the low 15 bits of the base-displacement were taken as a direct address. (The /20 maxed out at 16K.) The assembler didn't support direct addressing directly, but you could fool it by telling it that base registers 0, 1, 2, and 3, contained addresses 0, 4K, 8K, and 12K. The 360 has half-word load, store, add, and subtract instructions, so that's what the 360/20 had. The /20 did not have a load register instruction, because the 360 LR instruction loaded a full 32 bit register into another, and the 16 bit register copy the /20 could do wouldn't have the same semantics. The 360 subroutine call instruction BALR had a nearly useless feature that loaded 8 status bits into the high byte of the return address register, since the return address was only 24 bits. The 360/20 BASR loaded a 16 bit return address into a 16 bit register. Unless your program was one of the 0.0001% that looked at the status bits saved by BALR, BALR and BASR were equivalent, but since the semantics were different, the /20 had a different instruction. The much larger 360/67 had full 32 bit addressing to go along with its virtual memory, and also had a BASR that saved a 32 bit address in a 32 bit register. Hence it would be more correct to say that the 360/20 was, except for the I/O, a subset of the 360/67. More practically, you could define a CALL macro and write code that could trivially be assembled either for the /20 or larger models, or maybe define BASR, which was undefined in the regular 360 assembler, as a macro that generated a BALR. Even 16-bit direct addressing was sort of portable, since early 360/30s and 360/25s often had only 64K of RAM, and it was common albeit morally indefensible to write DOS/360 (no relation to PC-DOS except that it was also inelegant, kludgy, small, fast, and extremely popular) applications that failed if they were loaded above 64K. The model 20 was odd, but it was a sincere effort to provide an entry-level model that let users preserve their software investment when they upgraded. I personally ported 360/20 code to a 360/91, a flying leap from one end of the product line to the other. The main portability problem was that although the /20 implemented the decimal instructions, the /91 didn't and simulated them in software; hence in many cases a program wouldn't run a heck of a lot faster on the /91 than it did on the /20, at least not without rewriting it to avoid decimal instructions. >At the site where I encountered it, it made a nice RJE batch station, >with card reader, card punch, and line printer. Same here, I used a bunch of them at Princeton where they were used as RJE stations to the aforementioned 360/91 and as card duplicators and listers. Princeton had a little package called THOR that you could load into the /20 to do local card jobs. -- John R. Levine, IECC, POB 349, Cambridge MA 02238, +1 617 864 9650 johnl@iecc.cambridge.ma.us, {ima|spdcc|world}!iecc!johnl " #(ps,#(rs))' " - L. P. Deutsch and C. N. Mooers