🚀 go-pugleaf

In article <TMB.92Nov17181419@arolla.idiap.ch> tmb@arolla.idiap.ch (Thomas M. Breuel) writes:



Lot's of stuff about double-length multiplies deleted, then:

   If anything, if you are going for efficiency, the C approach is more
   portable, saying that "int" is whatever is fastest and "long" gives
   you extra bits. "int" essentially used to mean "CPU register size" and
   "long" was largely intended to mean "probably twice CPU registers
   size, which coincidentally is what multiply may give you, unless
   that's too inconvenient". The only problem with this approach was
   that the early C compilers for 32bit machines messed up and didn't
   make "long" 64bits.


If only it was that simple.  Ten years ago, I was working part-time
for a company building a bit-slice mini.  It had a 32-bit alu and was
quite capable of performing 32x32=>64 and 64/32=>32,32.  I wrote the
great majority of the microcode, and played a significant part in
defining the architecture.  I also did a lot of multi-precision
integer work, and argued that longs should be 64-bits; partly for
elegance, partly for performance reasons.  I wrote the microcode to
support those instructions.

We then came to port an operating system (BSD 4.0 I think, though
itmay have been 4.1).

It was a real eye-opener to find out how many pieces of code *knew* a
long was 32 bits long.


Faced with the unsurmountable opportunities of changing hundreds of
kilolines of kernel and utilities, we chickened out.  It was bad
enough, fixing everything that knew address zero was readable and
contained zero; and others that knew stacks grew towards lower
addresses; and others that knew it was safe to calculate addresses
outside of arrays, so long as you didn't use them before calculating
another offset to bring them back in bounds, and ...

Still, I was able to have an instruction which returned the smallest
prime factor of a 64-bit unsigned integer operand on the stack, even
if I did have to load my own ucode and use an asm statement 8-)


Paul
--
Paul Leyland <pcl@oxford.ac.uk>          | Hanging on in quiet desperation is
Oxford University Computing Service      |     the English way.
13 Banbury Road, Oxford, OX2 6NN, UK     | The time is come, the song is over.
Tel: +44-865-273200  Fax: +44-865-273275 | Thought I'd something more to say.