From: jcmorris@mwunix.mitre.org (Joe Morris)
Subject: Undocumented (mis-)operation codes
Organization: The MITRE Corporation
Date: Mon, 14 Sep 1992 12:35:03 GMT

"Joseph M. Newcomer" <jn11+@andrew.cmu.edu> writes:

>The best set of such features, however, was on the 360 series, and quite
>possibly their derivatives.  The instruction hex 83, "diagnose", was
>specified as being "model-specific diagnostic functions".  It turns out
>you needed to sign a nondisclosure to find out what it did; on the
>360/67 it was an instruction whose effect was to cause a microcode
>branch using the instruction's effective address as the microstore
>address.  

No nondisclosure agreement was needed on any of the S/360 systems I
used (which included a /65 but not a /67).  The standard field circus
documentation package for the S/360 and early S/370 systems included 
full assembly listings of the microcode; these listings were usually kept
on the CE documentation cart or in the fiche viewer in the CE's room.

Also routinely provided were the source listings for many of the FE tools
I recall finding an error in one of them (MIDAS, which was an acronym for
a title the text of which escapes me at this moment) which was using an
incorrect DIAGNOSE to read the console switches on the computer.  I then
discovered that there was no mechanism for a customer to file an error
report against a CE diagnostic tool, but that's another story.

I wrote and distributed a macro to read the console switches on an S/360
system using DIAGNOSE, but one of the requirements was that you tell the
macro what CPU type it is running on.

Incidentally, the DIAGNOSE instruction is privileged, meaning that you
must be in supervisor mode for it to execute.  Unless you've got an
escape hatch in your system that means that users should never be
able to use it to do nasty things.  It is most visible today in the VM/CMS
system where a DIAGNOSE opcode is used to communicate between user programs
running in unprivileged mode and the CP kernel.  The hardware executes
a privileged-opcode exception, which passes control to CP where the
DIAGNOSE is recognized.  From the user's standpoint DIAGNOSE is a valid
opcode under CMS, but since no CMS user ever runs in supervisor mode
(even if the user is a guest operating system like MVS) there's no
exposure caused by using DIAGNOSE for this purpose.

>About once every three days the 360/67 running TSS/360 at CMU would
>stop.  [...] 
>The only way this could be done was by the operator hitting the STOP key.
>But the operator didn't hit the stop key.

>It was finally discovered.  Due to the utterly horrible decision to (a)
>write the kernel in assembler and (b) allow each intermodule call to 
>define its own calling convention, a particular subroutine would 
>occasionally clobber a register it was not supposed to modify [with
>the result that a DIAGNOSE to stop the system was accidentally executed]

One can argue about the wisdom of using nonstandard intermodule call
protocols, but the choice of assembler for the nucleus was reasonable.
Remember that the price of memory in the 60s wasn't high, it was HIGH.
As late as 1970 I paid about $330,000 for 256K of 600 nsec memory (and
that was after educational discount!); it came in a box roughly 6'H x 7'L
x 2-1/2'W, and required 208V 3-phase power just to supply the memory
power requirements.  It's not unlikely that writing the kernel in
a high-level language would have significantly increased the memory
requirements and cost of a system of any given power...especially given
the compilers available in the early 1960s when TSS and OS/360 were
being first written.

The systems were slow by today's standards, and any programming decision
which resulted in longer code chains extracted a significant penalty in
performance if the chain was in a popular path.  

Yes, there were systems in the 1960s which used high-level languages
for the operating systems.  The Burroughs MCP (Master Control Program)
on the 5xxx and 6xxx series systems, for example...and everyone knows
what a roaring success those systems were.  (The Burroughs systems didn't
even *have* an assembler...if the Algol compiler used for the MCP code
could not perform some function, the necessary routine was hand-coded in
machine language.  The Burroughs salesmen bragged about this...)

I think that you'll find that the majority of computer operating
systems of the 60s, however, used assembly language to implement their
operating system.  By today's standards the code was poorly designed,
buggy, inconsistent, etc. etc. etc. (add in your favorite condemnation 
here) but keep in mind that the mainframe industry (both hardware and
software) was still very immature.  The use of high-level languages
in traditional assembler-based applications was growing (FORTRAN H
was written in itself, and FORTRAN G was written using a high-level
macro language via assembler) but for most systems programming in
the early 1960s assembler was still the most common tool.  TSS had
a number of problems (not the least of which was the high cost of the
IBM hardware to run it on) but its problems were certainly far from
unique in the industry.

Joe Morris / MITRE

Newsgroups: alt.folklore.computers