Sign magnitude, one's complement, two's complement

Jeff Woolsey jlw at jlw.com
Thu Sep 3 01:05:52 CDT 2015


This isn't quite the way I remember the CMU instructions working.  Nor
is it exactly how I've implemented them in my emulator.

>Another oddball thing was then then-new Cyber 72/73 CMU.  An interesting 
>beast, but not present on the 74.

Presumably because an instack loop could move data faster.   I always
wondered, though, if you could put a CMU in the serial CPU on a 74-2x.
Probably too messy.

>It was possible initially to write code with the 46xxx CMU instruction 
>in first 2 parcels of an instruction word.  All Cyber 73 CMU 
>instructions were 60 bits, 

No, the IM instruction is 30 bits.  It's supposed to be forced upper.  I
don't recall whether the 72/73 were that picky and it would work in the
first 3 parcels, or work only in the first one (thus being 60-bit
equivalent) and pass in the others (with the rest of the instructions
becoming arbitrary).

>you could pack a call to a subroutine to do 
>the equivalent thing in the lower 30 bits for the 74.  Worked pretty 
>cool 

Looks like it would.  Aren't there some variant OSes that would put the
monitor call parameters in the lower 30 bits of an XJ instruction?   You
could probably also pack a parameter in the B register, and another in
the address, since those would mode out anyway (or be ignored in user
mode)--you'll get to CPUMTR no matter what.   ECS instructions would
execute the lower 30 bits if the transfer failed; this all in user mode
with no monitor intervention.

You could probably do the same thing with a conventional XJ instruction.
 6000s lacking ECS hardware and CEJ/MEJ treated all 01x instructions as
010 (RJ).  Probably can't get away with that on a 70.

>until the 170.  There, different models supported different subsets 
>of CMU instructions (or not at all)

It was all-or-nothing, no subsets.

>--and attempting to execute one not 
>implemented was greeted with an error stop.  The 170 people really 
>screwed that one up.

464xx and up were illegal on machines that did not (171) or could not
(175) have the CMU option, or in other parcels on any 170. 46000-46377
were pass instructions.   I don't know why they did this either, since
there were no 170s with unmatched CPUs (like the 6700 or 74-2x).  Also,
some dual-CP machines (including the 72/73) could have 1 or 2 CMUs. 
Needed some special code in CPUMTR to avoid using the CMU for storage
moves if there were fewer CMUs than CPUs, lest it be busy in the other
CPU and we had to wait for it in monitor mode.

It's possible that on 180s, 46100-46377 were illegal instructions,
though the design goal for 170 mode was a 173.  Perhaps the
175/740/750/760 did that too.  Note also on 180s with CMUs (emulated),
the instruction was limited to data in the first 262K; in particular
CPUMTR couldn't use it for storage moves unless it played games with
RA/FL in program mode (and it would still have to drag the instruction
around into each segment).  Too much of a kludge, I expect.

-- 
  Jeff Woolsey
  jlw at jlw.com


More information about the cctalk mailing list