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?
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.
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
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 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.
This is at least written in most RISC vs CISC pages I have read, none
really give any advantige for the CISC.
Can't we combine this with Timothy's MISC idea? Have a "CPU" with
load/move/store, and a bunch of functional units that can each perform
a complex (think Altivec/3DNow!/SSE3 or even more complex than that,
like a dot product) instruction. Newer processors can simply have more
functional units, and could be backwards compatible with their
predecessors.
What about VIM (Sparcs version of "Altivec/SSE") ? ;)
Something I did like with Transmeta was the possibility to load different
cores into it, sad they just made 586 and no PPC/.../...
On Sat, 15 Apr 2006, Timothy Miller wrote:
he problem is that any more than a few general purpose registers
would make every pipeline stage a massive amount of logic, limiting
the number of stages. But the idea is to get great throughput at a
low clock rate. We cannot design something to run at 500MHz.
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).
--
//Aho
------------------------------------------------------------------------
E-Mail: [EMAIL PROTECTED] URL: http://www.kotiaho.net/~trizt/
ICQ: 13696780
System: Linux System (PPC7447/1000 AMD K7A/2000)
------------------------------------------------------------------------
EU forbids you to send spam without my permission
------------------------------------------------------------------------
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
