From: pcg@aber.ac.uk (Piercarlo Grandi)
Newsgroups: comp.arch
Subject: Re: Natural Word Size (was Re: 32 => 64 Transition
Date: 26 Aug 92 01:10:22 GMT
	<1992Aug24.191322.14510@bcars64a.bnr.ca>
	<DOCONNOR.92Aug24135056@potato.sedona.intel.com>
Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
Organization: Prifysgol Cymru, Aberystwyth



(Paul Taysom) writes:

Tayson> If at all possible, I want local variables stored in the natural
Tayson> word size of the machine.
			 ^^^^^^^

(Stanley T.H. Chow) writes:

Chow> The question is: "What is the natural word size" of any given
Chow> machine or architecture family. More importantly, as Joe Average
      ^^^^^^^ ^^ ^^^^^^^^^^^^
Chow> Programmer, when should I expect the natural size to change? [ ...
Chow> ] Clearly, for an archtecture family, there is *no* natural word
Chow> size. At best, there is a "prefered" size that is defined by the
Chow> architecture that may or may not get "better optimization" in any
Chow> implementation.

O'Connor writes:

O'Connor> This may be true for some CISC architectures, but it is
O'Connor> decidedly untrue for many RISC architectures. The Intel
O'Connor> i960(tm) architecture, for example, [ ... ] almost all
O'Connor> register-to-register operations are done on 32-bit values.
O'Connor> There are a few 32/64 bit operations. To my mind, this means
O'Connor> all the i960 family members have a natural word size: 32 bit.

Sorry for this long series of quotes, but context is important...

While O'Connor says correctly that an *architecture* may have a fairly
obvious natural word size, Chow's point, based on this comment by
Tayson:

Tayson> [ ... non naturally sized writes to memory can lose because ... ]
Tayson> The write is placed in the write buffer but because it is only a
Tayson> partial write of a word, the write has to complete to memory
Tayson> before the read can be allowed to proceed.  With deep write
Tayson> buffers, this can take tens even hundreds of cycles (i've seen
Tayson> one case where this took ~200 cycles).

Is that performance wise it is the implementation's natural size that
matters. And we cannot disagree on this.

The reason for which this is true is that many/most implementations of
an architecture are stricter than the architectures themselves, i.e.
they are improperly (in a purely technical sense) designed.

Tayson's example amounts to saying that many implementations use caches
entries as poor man's (1-deep, very wide) memory queues, which is easy,
but can have horrid performance implications.

And this is not limited to CISC architectures, actually it is even more
tied to RISC architectures, whose caching strategies are vital. Consider
the the amazing variation (almost an order of magnitude!) in performance
on RS/6000 machines at varying array strides, and at the similar if less
pronounced effects of cache organization on many other RISC
implementations.

*Iff* implementations were always done "appropriately" then the system's
"natural" word size would coincide with that of the CPU's architecture.
But because of cost effectiveness, or worse, reasons this is rarely
true, and then it is the system's natural word size that matters.
--
Piercarlo Grandi                   | JNET: pcg@uk.ac.aber
Dept of CS, University of Wales    | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk