Re: P64 Math
On Wed, 16 Aug 1995, Penio Penev wrote:
> On Fri, 11 Aug 1995, Mike Losh wrote:
>
[ 32/64 bit maths ]
>
> As I understand it, the push to wider busses is to alleviate the _memory_
> bottleneck problem, which will drive "peak advertised MIPs" up to (SRAM
> cycles/sec)*[(bus width)/5].
Don't forget the memory and network processors, constantly competing with
the CPU for memory bandwidth. Moreover, broader buses allow virtual
memory. Broader instruction slots make for a bigger opcode space.
> On the other hand, one shouldn't change their data types. If I need/care
> about 6 bits do describe a quantity in a solution to my problem, why would
> the change to a faster processor change my representation to 32 or 64
> bits?
Because you can get several of them with _one_ memory access from
slow store. Because there are applications, requiring 64 bit
scaled-int precision.
>
> I would rather have some fast bit-field packing/unpacking instructions
> rather than carry prediction, which most probably I will never (with
> probability measure close to zero) need.
The carry prediction boosts the ADDs/second. One can't have too
many ADDs/s. Packing several small data types into one
broad word is a prerequisite of SIMD. (Don't tell me you don't
need SIMD. Everybody needs SIMD).
Why don't you pick your data types with AND masks and shifts?
Apropos shifts. How many shifts can we have e.g. during 12 ns?
Is there a barrel shifter in planning? Jeff?
-- Eugene
> --
> Penio Penev <Penev@venezia.Rockefeller.edu> 1-212-327-7423
>
>
