On 2007-04-21, Timothy Normand Miller wrote:
> Very nice.
>
> Is it time for me to run it through the synthesizer?
I looks like I need to do some debugging after adjusting the instruction
format.
Another thing, I realised that the only instructions which require a
bit-bucket are branches. After changing the format, we have one free
bit in the branching instruction words. We could use that to
enable/disable the write-back, it's a simple test which can be done in a
non-critical place. The question is this only saves us one out of 32
registers, so is there any better use of this bit?
> Also, I'm thinking we don't need the move with shunts. Say we're
> doing DMA of 160 words from host memory to graphics memory. Here's
> what we do:
>
> (1) Ask the DMA engine to fetch 64 then 64 then 32 words. Those are
> three commands pushed into fifo 3, one after the next.
>
> (2) Feed the FB writer three requests to accept data words of 64 then
> 64 then 32. Three commands into fifo 7.
>
> (3) Tell the crossbar to move 64 then 64 then 32 words from fifo 4
> (the return fifo for DMA reads) to fifo 8 (the write data fifo) (those
> commands go into fifo 16).
>
> (4) Busy-wait for it to finish, monitoring for errors.
>
> You get the idea. I doubt that we'd need more than one concurrent
> move going through the crossbar. Some other cases require that we
> read data into the CPU and process it, so we can't use the crossbar
> for those.
Where do I find the definitions of these fifos?
But, what's the relation to the shunts. The above operates on 32 and 64
bit words. The current shunts have 8 bit granularity, and was more
intended for shuffling around colour components of pixels, and as a
substitute for the lack of 8 bit and 16 bit instructions. The same
thing take be done with one or two {shift, and, or}, so it's probably
not that useful. I'll take it out. Then, there will be 5 bits free in
the move instruction, so we'll reserve those for enumerating additional
unary instructions we might need.
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
