J.O. Aho wrote:
On Sat, 15 Apr 2006, Lourens Veen wrote:
On Friday 14 April 2006 22:23, Timothy Baldridge wrote:
So what benifits are you going to have in using CISC over RISC?
Smaller code sizes I guess, at the the expense of complexity.
It depends on how varied your task is. For graphics, I think quite a
small number of CISC-style operations would suffice.
Ain't the later x86 RISC that "emulates" CISC?
There is no such thing as x86 RISC.
You are probably thinking of the x86 microarchitecture, which decodes
CISC instructions into one or more RISC-like micro-ops inside the CPU.
This enables out-of-order execution, increasing parallelism.
RISC don't ned to reload data in the same manner as CISC has to, which
in the long run I belive will give the edge to the RISC.
I don't think you know what you are talking about, here.
Data dependencies exist regardless of RISC or CISC, which is why modern
RISC and CISC processors all have prefetch instructions and other data
speed-ups.
For example, you
are going to do loads and loads of dot products (matrix multiplies in
vertex shaders, normal calculations for per-pixel-lighting, bump
mapping, and so on). Doing all the adding and multiplying one at a time
means more instructions and more pressure on the scheduling hardware.
The CISC commands uses a lot more cycles than what the RISC does, in
Largely false, for the most common instructions.
x86 instructions like 'mov' or common ALU instructions typically execute
in a single cycle. In fact, with multiple ports, _multiple
instructions_ can be executed in a single cycle.
And don't forget that RISC blows your i-cache out of the water. x86 is
essentially a compressed instruction set, with the most common
instructions requiring only 8-bits to describe, versus 32 bits for a
normal RISC instruction.
general they do take the same amount of time as CISC
X-function*XX-cycles while RISC XX-functions*X-cycles. The draw back for
the CISC is that it empties the registers and if next funxtion needs to
"empties the registers"? You have no clue what you are talking about.
use the same data this has to be reloaded to the register, while the
RISC will still have the data in the register as it only empties the
register when it needs to.
Registers are registers. They store values for use by multiple
instructions, on either CISC or RISC. That's what registers do.
32-bit x86 even has _far more_ registers than the ISA suggests. Google
for "register renaming" sometime. 64-bit x86 solved this problem, by
adding a ton of registers to the ISA.
Finally, optimal register usage is a function of the compiler and the
code being compiled. Code with heavy data dependencies will use few
registers, constantly loading new data into the same registers for
calculations in loops and whatnot. There is a ton of literature on
optimizing register usage, and there is no one right way to do things.
Isn't a shortening of the pipelines a good idea? This is what has been
done on both Sparc and PowerPC, both has a lot shorter pipelines than
what AMD has on it's which is shorter than Intels. IMHO the old Apple
video called "The MHz Myth" shows the benefits of shorter pipelines.
Don't know how things would be with even shorter pipelines than IBM's
and Freescales PowerPC has (eXponental had longer pipelines and did less
on higher MHz than the ones from Freescale).
Again, you cannot make a blanket statement like "shorter pipelines are
better."
Jeff
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
