News for hackers. Stuff that matters.
Re:Rust: Not So Great For Codec Implementing by wahern on Tuesday August 01, 2017 @07:19PM (#14906402)
At least one extant (or recently extant) system has to emulate unsigned, modulo arithmetic. This can be handled by the C compiler transparently, however. From the C compiler documentation:

  | Type          | Bits | sizeof | Range                                  |
  +---------------+------+--------+----------------------------------------+
  | ...                                                                    |
  | unsigned long | 36   | 4      | 0 to (2^36)-2 (see the following note) |

  ...
  Note: If the CONFORMANCE/TWOSARITH or CONFORMANCE/FULL
  compiler keywords are used, the range will be 0 to (2^36)-1.
  See the C Compiler Programming Reference Manual Volume 2 for
  more information.

  -- Section 4.5. Size and Range of C Variables of the Unisys
  C Compiler Programming Reference Manual Volume 1.
  https://public.support.unisys.com/2200/docs/cp16.0/pdf/78310422-012.pdf
Re:Rust: Not So Great For Codec Implementing by deathanatos on Wednesday August 02, 2017 @03:39AM (#14908644)
A range of 0 to (2^36)-2 implies that there's one bit combination not mentioned here (that range has only 2 ^ 36 - 1 values; 36 bits can store 2 ^ 36). What's the last combination used for?
Re:Rust: Not So Great For Codec Implementing by wahern on Wednesday August 02, 2017 @08:06AM (#14909814)
I don't know off-hand. AFAIU the Unisys machines use ones' complement representation. My guess is that the native unsigned set of values includes the representation for both positive and negative 0. Or there could be a trap representation that is hidden in unsigned mode, which presumably would also make these machines examples of hardware that traps on signed overflow.
Re:Rust: Not So Great For Codec Implementing by bsder on Friday August 04, 2017 @04:11PM (#14931790)
Wow. 9-bit words with 1's-complement arithmetic.

I wonder if it still does end-around carry...