Newsgroups: comp.arch
Path: utzoo!henry
From: henry@utzoo.uucp (Henry Spencer)
Subject: amusing opcodes
Message-ID: <1988Aug7.013526.7798@utzoo.uucp>
Organization: U of Toronto Zoology
References: <5458@ecsvax.uncecs.edu> <1876@looking.UUCP> <753@applix.UUCP> <3884@sequent.UUCP> <719@mcrware.UUCP> <5440@june.cs.washington.edu>
Date: Sun, 7 Aug 88 01:35:26 GMT

In article <5440@june.cs.washington.edu> pardo@uw-june.UUCP (David Keppel) writes:
>All seriousness aside, if you ever get a chance to look at the
>UMichigan list of opcodes (Circa 1970, since reprinted elsewhere) you
>really should...

For the purposes of comp.arch, let us at least stick to *real* opcodes,
not imaginary ones (amusing though they can be...).

>HACF  # Halt And Catch Fire

As is now moderately well-known, some of the Motorola 8-bit chips actually
have such an instruction, sort of:  there is a test opcode which makes the
CPU just sit there endlessly incrementing its address lines.  Nothing short
of powerdown will shake it out of this.  Some third-party opcode charts
show this as HCF.  The Motorola spec sheet that I remember doesn't give it
a name, but does have a footnote warning you about it.

Another real-life example is that the Burroughs 6700 series had some opcodes
for interprocessor communication in multi-CPU systems.  There was one for
atomic access to memory, which had some boring name.  The fun pair were for
actually attracting another processor's attention:  there was one that
interrupted *all* processors, and another that would give you the processor
number of the current processor.  So you would set up some sort of message
in shared memory and then interrupt everybody, and each processor would
get its own processor number and then inspect the message to find out if
it was the addressee.  The instructions were HEYU and WHOI, I'm told.
-- 
MSDOS is not dead, it just     |     Henry Spencer at U of Toronto Zoology
smells that way.               | uunet!attcan!utzoo!henry henry@zoo.toronto.edu