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

Chuck Guzis cclist at
Sat Aug 22 21:31:32 CDT 2015

On 08/22/2015 06:26 PM, Paul Koning wrote:
  than the usual rule).
>> I recall the "integer multiply" feature (i.e. optional) available
>> on the 6000.  IXi  Xj*Xk, but it didn't provide any more precision
>> than the usual unnormalized double-precision multiply  DXi  Xj*Xk,
>> but saved some time spent fiddling with exponent fields.
> ???  Never heard of any such thing.  IXi Xj*Xk is a defined opcode,
> but it's simply a synonym for Dxi Xj*Xk.

Well, we were always the guinea pig for QSEs in SSD.  It's not described 
in the Cyber 70 docs, but we had Cybers fitted with the option.  It did 
make its way into the 170s however:

In 60456100A, re: the 42 instruction (page 4-24, second column):

"This instruction is used in multiple-precision floating-point 
calculations.  This instruction also provides for integer multiplication 
capabilities where both operands have an exponent value of plus or minus 
zero and neither coefficient has been normalized.  The integer result 
sent to Xi is *48 bits with a 60-bit sign extension* (emphasis mine)."

A minor change that saved perhaps a few cycles.

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

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, you could pack a call to a subroutine to do 
the equivalent thing in the lower 30 bits for the 74.  Worked pretty 
cool until the 170.  There, different models supported different subsets 
of CMU instructions (or not at all)--and attempting to execute one not 
implemented was greeted with an error stop.  The 170 people really 
screwed that one up.


More information about the cctech mailing list