2007/3/18, Timothy Normand Miller <[EMAIL PROTECTED]>:
On 3/18/07, Petter Urkedal <[EMAIL PROTECTED]> wrote:
> I'd like to lift some ideas for the processing pipeline. I found it
> easiest to sketch out the whole pipeline based on Tim's post and earier
> model http://lists.duskglow.com/open-graphics/2006-August/006968.html
> and incorporate the ideas there.
>
> To summarise the pipeline stages:
>
> 1. Instruction fetch
> 2. Register fetch and branch condition
> 3. ALU
> 4. Memory IO
> 5. Write-back
>
> The ideas are
>
> * Move cheap unary operators from stage 3 to stage 2, e.g. istead of
> implementing {add, sub} in 3, implement only {add} and optional
> negation on one of the operands. The motivation is that parallel
> functions in the ALU sits idle while one is working, and by moving
> some computation to the previous stage we can instead exploit more
> combinations.
I like this idea. I'm not sure how well it'll work for an FPGA.
Beside that, register read could be much slower than an ALU op.
<...>
> * Only basic one-cycle operations goes in the CPU. If we need any
> multi-cycle operation (div?), we could add it as IO ports, using
> the "modularised RISC" idea,
> http://lists.duskglow.com/open-graphics/2006-April/005307.html.
Oh, yeah! Good idea.
Be carefull of all the lost cycle to read/write data to the good
memory register. 3 (or 4, one more to execute the instruction) access
for a div at least + the div it-self. You can't also assume that a
memory access will be one cycle latency because the memory adress
decoder for such register could be hudge and slow.
For example, ARM use "coprocessor" interface. It's basicaly an other
pipeline that could come with it's own register set, and a way to pass
register value.
A memcpy operation could be handle with this kind of coprocesseur
(quite usefull for a dma). This could be asynchronous with a kind of
busy system.
Regards,
Nicolas Boulay
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
