22 Jun
2016
22 Jun
'16
6:15 a.m.
From: Dwight Kelvey
The RIS[C]/CISC is really not even relevant in todays
processors since
the main limiting factor is memory access bandwidth and effective use
of caches.
Memory bandwidth has often been the limiting factor over the complete
timeline of CPU's/systems. (It would be interesting to draw up a timeline,
showing the periods when it was, and was not.) Yes, caches can help a lot,
but inevitably they will miss (depending on the application, more or less
often).
The RISC/CISC thing actually is kind of relevant to this, because RISC
focuses on getting the CPU cycles to be as fast as possible, and that kind of
implies simpler instructions --> more instructions to get a particular task
done.
That was part of the motivation for microcoding, back when it was invented; at
that point in time, logic was fast, memories were slow, so more complex
instructions made better use of memory bandwidth - especially since this was
pre-caches. (It also made binary code 'denser', which was important back then,
with much smaller memories.) However, more complex instruction sets made the
CPU more complicated; microcoding helped deal with that.
The 801's breakthrough, at a very high level, was to see the whole system,
and try and optimize across the compiler as well as the instruction set, etc,
etc. They also realized that people had been going CISCy for so long that
people had to some degree forgotten why, and that that assumption needed to
be re-examined - especially in light of the then-current logic/memory speed
balance, which had shifted towards memory at that particular point in time.
Noel
22 Jun
22 Jun
9:01 a.m.
On Jun 22, 2016, at 9:15 AM, Noel Chiappa <jnc at
mercury.lcs.mit.edu> wrote:
I can't think of an obvious example where memory speed wasn't a concern. Possibly
a reason is that memory would be tailored to the rest of the system (cheaper lower cost
core if the CPU didn't need it faster). But, for example, making the memory run well
is a large part of why the 6600 looks the way it does.
From: Dwight Kelvey
The RIS[C]/CISC is really not even relevant in
todays processors since
the main limiting factor is memory access bandwidth and effective use
of caches.
Memory bandwidth has often been the limiting factor over the complete
timeline of CPU's/systems. (It would be interesting to draw up a timeline,
showing the periods when it was, and was not.) Yes, caches can help a lot,
but inevitably they will miss (depending on the application, more or less
often). The RISC/CISC thing actually is kind of relevant to
this, because RISC
focuses on getting the CPU cycles to be as fast as possible, and that kind of
implies simpler instructions --> more instructions to get a particular task
done.
One consideration is that a RISC CPU requires vastly less silicon. So you can do RISC in
very small/cheap chips, or on a larger chip spend far less on the CPU core and leave more
room (at constant die cost) for other stuff like caches or auxiliary components. One
place you can see this is in the various MIPS or ARM based "system on a chip"
products, which have some CPU cores plus memory controllers, cache, UARTs, I/O buses,
flash interfaces, crypto cores, RAID coprocessor cores, etc. etc. Or you might find chips
with very large core counts, like the Tilera 100-core processors. (For that matter, the
DECmpp many-core machine was a RISC machine for the same reason.)
paul
4:18 p.m.
I guess we are talking apples and oranges. I'm not talking
chip that can be implemented in tiny sizes. I'm talking chips of the complexity
of current Intel and AMD chips. The instruction decode and its effect are a small
part of the overall size. The ARM64 is an example of poorly implemented RISC.
They put too much of the legacy stuff into it.
Dwight
________________________________
From: cctalk <cctalk-bounces at classiccmp.org> on behalf of Paul Koning
<paulkoning at comcast.net>
Sent: Wednesday, June 22, 2016 9:01:56 AM
To: General Discussion: On-Topic and Off-Topic Posts
Cc: jnc at mercury.lcs.mit.edu
Subject: Re: CDC 6600 emulation - was Re: How do they make Verilog code for unknown ICs?
On Jun 22, 2016, at 9:15 AM, Noel Chiappa <jnc at
mercury.lcs.mit.edu> wrote:
I can't think of an obvious example where memory speed wasn't a concern. Possibly
a reason is that memory would be tailored to the rest of the system (cheaper lower cost
core if the CPU didn't need it faster). But, for example, making the memory run well
is a large part of why the 6600 looks the way it does.
From: Dwight Kelvey
The RIS[C]/CISC is really not even relevant in
todays processors since
the main limiting factor is memory access bandwidth and effective use
of caches.
Memory bandwidth has often been the limiting factor over the complete
timeline of CPU's/systems. (It would be interesting to draw up a timeline,
showing the periods when it was, and was not.) Yes, caches can help a lot,
but inevitably they will miss (depending on the application, more or less
often). The RISC/CISC thing actually is kind of relevant to
this, because RISC
focuses on getting the CPU cycles to be as fast as possible, and that kind of
implies simpler instructions --> more instructions to get a particular task
done.
One consideration is that a RISC CPU requires vastly less silicon. So you can do RISC in
very small/cheap chips, or on a larger chip spend far less on the CPU core and leave more
room (at constant die cost) for other stuff like caches or auxiliary components. One
place you can see this is in the various MIPS or ARM based "system on a chip"
products, which have some CPU cores plus memory controllers, cache, UARTs, I/O buses,
flash interfaces, crypto cores, RAID coprocessor cores, etc. etc. Or you might find chips
with very large core counts, like the Tilera 100-core processors. (For that matter, the
DECmpp many-core machine was a RISC machine for the same reason.)
paul
3105
days inactive
3105
days old
2 comments
3 participants
participants (3)
-
dkelvey＠hotmail.com -
jnc＠mercury.lcs.mit.edu -
paulkoning＠comcast.net