Some comments on that data. There are a bunch of one's complement machines. CDC 6000 series has already been mentioned. Electrological EL-X1 and EL-X8 are another example. Both the CDC and the EL-X8 have another interesting property: the floating point format is one's complement, and the mantissa is an integer rather than a fraction. F.E.K Kruseman Aretz in his paper on the EL-X8 floating point implementation calls this "Grau representation" (A.A. Grau. On a floating?point representation for use with algorithmic languages. Comm. ACM 5 (1962) 160.). One's complement in the sense that negating a float was done exactly like negating an int: by complementing it. And in the EL-X8 the exponent field was a one's complement integer also (unlike CDC where is's an excess-02000 value). One interesting property of one's complement machines is whether they "prefer +0" or "prefer -0". If you use an adder, then x+(-x) produces -0 -- the only way to get +0 is as the result of 0+0. Cray apparently didn't like that, so the CDC 6000 series use a subtractor, so add is done as a-(-b). If you do that, then you get "prefer +0" -- x + (-x) is +0 if x is non-zero, and the only way to get a -0 result is to start with a -0 input. But EL-X8 is "prefer -0". I don't know about other one's complement machines. Interesting point. Not true for the CDC 6000 series PPUs because they had an 18 bit accumulator, so a 24 bit add (which was fairly common) would look like: ldm foo adm bar stm result shn -12 shift carry into lower bits adm foo+1 adm bar+1 stm result+1 As for sign/magnitude, there's the IBM 1620. Not binary, but sign/magnitude decimal. paul

On 08/22/2015 04:40 PM, Paul Koning wrote: 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. There was no corresponding Integer divide. So the integer adds would give the usual 60 bits of precision, while the integer multiply gave 48. On the other hand, the unnormalized integer mantissas could be very useful. One such is an integer divide by a constant. Good enough for small magnitude numbers. All of that went out the window on the STAR, however. A more traditional normalized two's complement format was used. --Chuck

On 08/22/2015 06:26 PM, Paul Koning wrote: than the usual rule). 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. --Chuck