(\ x 0) revisited, revisited, revisited

[Alan Bawden <ALAN at MIT-MC>]

The IDIV instruction deals with division by zero by doing nothing.  AC and
AC+1 are left with their original contents, and the Overflow and No Divide
bits are set.  This may be the right thing for division, but since the IDIV
instruction is also the way to get a remainder, and since the remainder is
perfectly well-defined for the 0 case, this means that there is a hole in
the basic instruction-set.  I would say that AC+1 should get loaded with
the contents of AC in this case.  So this really is DEC's bug!

Now I presume that the contract of "\" is to "do what the hardware does",
just like "+" is defined to do what the ADD instruction does.  This is a
pretty strange contract given that the hardware just hands you back
whatever happens to be in AC+1, which could be anything!  This is
exactly what code produced by COMPLR is doing.  But the "\" SUBR
returns the first argument in this case.

This has NOTHING to do with generic vs. specific arithmetic functions.
Nobody has yet mentioned the REMAINDER function.  It is simply a bug.  The
"\" function does different things interpreted and compiled.

An easy fix is to change the "\" SUBR to return a randomly chosen value if
you tried to remainder by 0.

A harder fix is to fix COMPLR to output the extra instruction necessary to
make the check in compiled code.

Actually another discrepancy I just noticed is that 
(eq (get '\ 'subr) (get 'remainder 'subr)) => T!  So we can also haul up
the "\" SUBR on charges of not doing enough error checking!