CASTalk.com

Paul A. Clayton · Guest

In the CISC vs. RISC debate, it seems that the design principles
behind each are generally not considered in their historical
context.

ISTM that a major concern for CISC was memory capacity. This
concern is expressed in efforts at code density (variable length
instructions, complex instructions [often targeting the
'common case' of higher level programming, meshing with semantic
gap theory], implicit arguments [leading to special-purpose
registers], and fewer registers [fewer bits to encode]), hardware
support of unaligned loads (to improve data density), and
finer-grained memory protection (segment-based rather
page-based). In earlier hardware the cost of unaligned loads may
have been smaller due to the smaller width of memory interfaces.
The cost of ROM relative to RAM (especially fast RAM) may have
tended to encourage the use of static micro-code even beyond the
general code density advantage. Earlier systems may also have
used fewer segments per application and less dynamic resizing,
possibly making segmentation more efficient.

Also earlier semantic gap theory may have seemed more reasonable,
making compilers (and assembly-level programming) simpler when
programming effort was perhaps a greater consideration (and as
mentioned above it meshes well with targeting code density).

OTOH, the main RISC design principles are pipelinability (leading
to fixed-sized instructions, few instruction formats, simpler
memory addressing modes, etc.), compiler optimization ('reduced'
operations can be independently scheduled, a relatively large
number of [fast] registers allows software to cache data [e.g.,
Common Subexpression Elimination] and use faster/less expensive
procedure interfaces), and simpler/faster hardware (in addition
to pipelinability aids, aligned memory accesses [which can
simplify a usually time-critical path] and 'reduced'
instructions [particularly separation of memory accesses from
other operations]).

The design principles of RISC place more burden on the compiler,
which may allow system developers to take advantage of
late-binding. It would certainly seem to allow system developers
to leverage a greater volume of software developers relative to
hardware developers.

At current hardware budgets, the aligned memory access
requirement is probably the least useful of the RISC mechanisms.
The largish number of general purpose registers may become more
burdensome if microthreading becomes more common, but the
benefits of this mechanism still seem to outweigh the
disadvantages significantly. With the exception of some embedded
systems (for which two-sized instructions are common),
fixed-sized instructions seem to provide more benefit than cost.
The emphasis on scalar decode may be considered a weakness of
RISC in the world of superscalar processing, though the simple
generally explicit encoding of RISC does help somewhat even
there.

CISC design principles may be said to depend too much on
expensive memory capacity to remain practical in most modern
circumstances.

Paul A. Clayton
(a 'Dysthymicdolt' reachable at aol.com)

Guest

"At current hardware budgets, the aligned memory access
requirement is probably the least useful of the RISC mechanisms."

I, respectfully, disagree.

At current hardware budgets, the least useful RISC mechanism is the
fixed length instruction format. Both Intel and AMD have shown that
they/we can decode just as many instructions per unit time as the RISC
guys.

Consider a x86 machine like an Athlon (or P3 or P4). How much
performance is sacrificed by having to decode multibyte instructions?
Answer; with modern branch prediction, the added pipe stages extract a
penalty around only 1%-2% compared to fixed length machines! Yet these
decoded multibyte instructions contain more semantic units of work that
the equivalent 4-ish wide RISC decoders. But, in neither catagory of
machines is the basic throughput significantly dependent upon the
performance of the decoder(s)!

I could address the rest of the statements piecemeal, however, the
general premiss is wrong. The evolution of x86 is proceeding faster
than the evolution of other CPUs bacause of the amount of cubic dollars
that can be thrown at teams of designers to solve yesterdays problems
and develop tomorows monster machines. Cubic dollars beats
architectural cleanliness everytime.

Mitch

Paul Rubin · Guest

MitchAlsup@aol.com writes:

Nick Maclaren · Guest

In article <1105559795.307333.292340@c13g2000cwb.googlegroups.com>,
<MitchAlsup@aol.com> wrote:

Stephen Fuld · Guest

"Nick Maclaren" <nmm1@cus.cam.ac.uk> wrote in message
news:cs41hi$62t$1@gemini.csx.cam.ac.uk...

snip

David Wang · Guest

Paul A. Clayton <carchreader@aol.comnomail> wrote:

Andi Kleen · Guest

nmm1@cus.cam.ac.uk (Nick Maclaren) writes:

Nick Maclaren · Guest

In article <17hFd.8944$7N1.38@bgtnsc04-news.ops.worldnet.att.net>,
Stephen Fuld <s.fuld@PleaseRemove.att.net> wrote:

Nick Maclaren · Guest

In article <m3acrez0xi.fsf@averell.firstfloor.org>,
Andi Kleen <freitag@alancoxonachip.com> wrote:

Maynard Handley · Guest

In article <cs41hi$62t$1@gemini.csx.cam.ac.uk>,
nmm1@cus.cam.ac.uk (Nick Maclaren) wrote:

Andrew Reilly · Guest

On Thu, 13 Jan 2005 02:46:34 +0000, Maynard Handley wrote:

Terje Mathisen · Guest

Nick Maclaren wrote:

Jan Vorbrüggen · Guest

Nick Maclaren · Guest

In article <pan.2005.01.13.03.00.01.273325@areilly.bpc-users.org>,
Andrew Reilly <andrew-newspost@areilly.bpc-users.org> writes:
|>
|> I would say that modern-day audio and video compression standards are a
|> good example of file (and communication) formats done *well*, by Nick's
|> standards, as they are universally (in my experience) defined in terms of
|> packed bit-strings, rather than fwrite(c-struct) /* and-hope-it-ports-ok,
|> later */, which was what Nick was complaining about (I believe).

Precisely.

Regards,
Nick Maclaren.

Nick Maclaren · Guest

In article <cs5815$p3o$1@osl016lin.hda.hydro.com>,
Terje Mathisen <terje.mathisen@hda.hydro.com> writes:
|>
|> A recent post in c.l.a.x86 made me go back to C string.h functions, as
|> well as the *BSD-inspired strl*() replacements.
|>
|> Efficient handling of C strings pretty much requires you to process a
|> full register's worth of data (usually 4 or 8 chars), while you cannot
|> depend on either the source or destination to be properly aligned, right?

Well, there are other approaches, but I agree that is one of the
few that works on most current hardware.

|> Besides alignement, another key problem is that the terminating zero
|> byte in the source string could well be the last byte in a memory block,
|> meaning that any access past this point will cause a trap.
|>
|> Handling both of these at the same time pretty much requires either
|> unaligned load and/or store operations, together with the capability to
|> do non-trapping (speculative) load operations past the end of allocated
|> memory, or you need to re-invent the Alpha:

Well, no, it doesn't. Look at BSD libraries for examples of how
you can (semi-portably) use only aligned loads and stores.

Also, you are asking for MUCH more than just unaligned operations.
For example, you are relying on two features that are generally
not the case:

1) EFFICIENT unaligned loads and stores, whether in terms of
cycle counts, cache use or TLB use.

2) The non-trapping aspects you mentioned, which can be very
important indeed.

3) No error detection in such operations. This is less obvious,
but I have almost never seen code that operates that way (including
relying on non-trapping aspects) AND correctly traps when using a
genuinely invalid location.

Regards,
Nick Maclaren.

RISC vs. CISC design principles Goto page 1, 2, 3, 4, 5, 6, 7, 8 Next

	CASTalk.com Forum Index -> Computer Architecture	All times are GMT Goto page 1, 2, 3, 4, 5, 6, 7, 8 Next
Page 1 of 8