return to main page

Undocumented Instructions :-((

Users of early computers often discovered Undocumented Instructions. These were machine instructions (codes) that were not in the specifications, instruction books, ... but that were discovered (accidentally or by search) and often later used as very helpful.

These Undocumented Instructions tended to be a curse to the further development of the computer. Engineering corrections, additional features, any changes at all, tended to "break" existing programs. This irritated customers and programmers who utilized these unintended "features" either deliberately or accidentally. A program that worked perfectly before some logical change no longer worked correctly, even though the machine passed all existing diagnostic tests which tested specified, known instructions. The resulting lost time and frustration was non-trivial!

In the 1950s and early 1960s, programmers searched for and used "illegal" or "undocumented" op-codes. In 1961, while in the field for General Electric Computer, I met a a programmer who worked at General Electric Space and Missiles Division (Ruben Munz) whose story included finding the (I think) "Store and Clear Accumulator" instruction on the IBM 704. According to him, he submitted the find to IBM, received no acknowledgement, but the next edition of the manual included this instruction.

After many bloody noses, hardware designers eventually added instruction decode logic to "trap" these un-implemented codes to help prevent later headaches. This trend occurred in the mid-1960s. The specifications for the IBM 360 included trapping un-implemented instructions - intended to, among other things, prevent exactly this effect.

(You could also trap instructions not implemented in this particular machine to subroutines to perform the locally unimplemented instructions - such as floating point. With current super cheap logic and microcode, this option is rarely used now.)

Evidently, the IBM 1401, designed in the late 1950s, did not search for and trap Undocumented Instructions. This was extra work, extra logic, extra cost, and extra documentation.

The following is a series of e-mails "in no particular order" discussing IBM 1401 Undocumented Instructions. 

> 
> ----- Original Message ----- 
> From: "David Macklin"  
> To: "Ed Thelen" < 
> Cc: "Neal Macklin"  ; "Gary Mokotoff-"  ; "John Wertheim"  
> Sent: Wednesday, January 25, 2006 4:49 PM
> Subject: Undocumented 1401 instructions
> 
> 
> > Ed, et al,
> > http://morgan.weibeltech.com/~david/code/ibm1401/manual/
> > 
> > does NOT document the seven-character 'branch and store B-register'
> > .
> > It is heavily used in 1401 Fortran. It was discovered and tested
> > by Stan Smillie, in 1960-1.
> > 
> > I assume this simulator is the one you employ.  
> >  
> > David Macklin
> > 

From Van Snyder 1/25/2006
Cc: "Garner, Robert" ; "ron.mak" ; dmacklin; "supnik" 

On Wed, 2006-01-25 at 17:27 -0800, Ed Thelen wrote:
> does simh implement this instruction?

I noticed this in Autocoder.  I investigated how the branch decision
might work by looking at the dataflow manual (G24-1477-0), concluding
that it takes the branch if the character at the B address is the same
as the last character of the address.  When I visited the 1401 at
Sindelfingen, I ran a program that verified this.  Having done that, I
wrote to Bob Supnik, who made sure that simh simulated it correctly.  I
don't remember whether simh already had it right, or needed repair.

Another aspect of it is that eight-character branch decrements the B 
address register if it doesn't branch.  I assume that seven-character
branch does also.  Of course, if your purpose is to decrement the B
address register using this instruction, you ought to make sure that the
character at B cannot be equal to the last character of the B address!
I haven't checked whether simh simulates this action on the B address
register.

I also noticed that four-character MN and MZ are also not documented in
A24-1403-5 (the "Brownie Book").  It appears that they are functionally
NOP instructions that have the side effect of decrementing the A and B
address registers, which happen to have the same value.  The Fortran
compiler also uses this idiom, and it appears that simh gets it right
(but I haven't investigated carefully yet).

Van
return to main page