🚀 go-pugleaf

> [ Lots of good arguments for the use of 64-bit integers ]
> 
> To summarize, there are many current applications that use, or would
> like to use, 64-bit words.  When chip makers start building chips
> with 64-bit internal data paths, the chips will sell, and the 64-bit
> data paths will be useful.
> 
> -- Chuck

Nobody is arguing that there isn't a use for extended precision integers
and faster handling of double-precision floating point operands.  There's
nothing to prevent the implementation of a 64-bit type in any processor, be
it mainframe, mini, or microprocessor, and 64-bit operations can be executed
in a fraction over twice the time of comparable 32-bit operations (except
multiply, divide, etc.).  The harder question is: "Is a 64-bit datapath with
64-bit registers the best use of silicion area in order to attain higher
performance over a reasonable range of applications?" If you were faced with
a choice between going 64-bit and including an I-cache or a pipelined TLB,
there's little doubt that you would choose the latter (unless this machine
was going to do nothing but run double-precision Fortran programs all day).
When there're enough transistors to go around, then things get a bit more
interesting, and then you're looking at the tradeoff between increased logic
propagation delay from the deeper decoders, carry lookaheads, etc. vs. the
increased performance possible with single-cycle 64-bit operations.

In fact, the choice of 64 vs. 32-bit datapaths is a lot more complicated
than many people are willing to admit.  Application mix (which depends on
the market for the machine), chip area and yield considerations, on-chip
delays (both logic and length-related), board area available for buffers/
latches/wider caches, and connector density going off-board must all play an
important part in the decision for any given processor.  Computer architecture
is an N-dimensional task, where N is extremely large and all the dimensions
intersect in strange ways.

	Mark Papamarcos
	Valid Logic
	{ihnp4,hplabs}!pesnta!valid!markp