🚀 go-pugleaf

In article <9105210333.AA09960@ucbvax.Berkeley.EDU>, jbs@WATSON.IBM.COM writes:
>           Herman Rubin also writes:
> So why not have increased integer accuracy?  It is no harder to do this, and
> the same units can be used.
> 
>           I believe there is a good argument for 64 bit integers.
> However as someone already pointed out 64x64 bit multiplies can
> not be done with a 53x53 bit floating point multiplier.

Given that the same posting has already beaten Herman Rubin over the
head with the IEEE standard, this doesn't go down well.  IEEE extended
precision (and the IEEE standard does recommend that it be provided)
uses 64-bit signifcands, so a "full" implementation of IEEE 754 would
include a 64x64 multiplier, not a 53x53 one.  Don't the 80387 and the
68882 chips offer extended precision?  What size of multiplier do they
use?

>           Well when a architect leaves something out he is not say-
> ing it is useless, he is saying its benefits do not match its
> costs.  Btw I suspect to be a good designer you need a bit of arrogance.

Good architects these days may be like that.  But a lot of older machines
seem to have been designed on the "we want to take customers from Brand X
and the Brand X has a Y instruction, so we'd better have one too" principle.
Does anyone know the real story behind the IBM Series/1?

I once heard a talk by an Amdahl architect about the way IBM move OS
functionality in and out of "370" hardware/microcode.  The theme of
the talk was "what they keep doing to us!  But we're better than good
enough to overcome!"

How many chips had run-time byte sexing before MIPS?  Did MIPS judge
wrong about costs and benefits, or was it everyone else?  Just because
an architect leaves something out, we don't have to _believe_ him that
its benefits do not match its costs, until he shows us his data.

As far as I am concerned, there is only really one major problem with
Herman Rubin's requests:  without considering what the rest of the
hardware already has, it's hard to assess the costs, and it's next door
to impossible to assess the benefits.  That's not really his fault; how
_do_ you go about measuring the possible benefits of a class of
instructions which are so rare that benchmark programs have already been
written to avoid the situations where they would have paid off?
There's a data base project here which would _love_ high-speed bit-string
operations.  A C compiler wouldn't recognise an opportunity to use them.
An Ada compiler probably would, and so would a Lisp compiler, because
those languages can express operations on entire bit strings.  Indeed,
Lisp can express "find next set bit" directly.
	(declare (type fixnum n) (type simple-bit-vector b))
	(let ((next-bit (position 1 b :start (1+ n))))
	    (if next-bit #| next-bit is the number of the next bit |#
		         #| else there is no next set bit |#))
so we can process all the set bits thus:
	(do ((n -1))
	    ((setf n (position 1 b :start (1+ n))))
	    (declare (type fixnum n))
	    #| n is the number of a bit in b which is set |#)

My own experience of helping to port a compiler to about a dozen
machines was that I often ended up cursing architects for things
that they could have provided at low cost, the absence of which
made life painful for us (fast dispatch on bits in a register,
for example.  Why were they omitted?  Because the architects only
examined C (and possibly Fortran) programs.  Bah.  (_Love_ the 88k.)

This is just a suggestion, but I wonder whether Herman Rubin would
consider writing an article "Lost Beauties of Computer Architecture"
(I've imitated the title of "Lost Beauties of the English Language")
describing some of the things he has occasion to do in his algorithms
and what kinds of hardware support used to be available or would be
useful for helping him.  I'm sure ACM's SigArch publication would take
it, and it would keep net bandwidth down if we could keep pointing to
a paper.
-- 
There is no such thing as a balanced ecology; ecosystems are chaotic.