On 2007-04-22, Timothy Normand Miller wrote:
> On 4/22/07, Petter Urkedal <[EMAIL PROTECTED]> wrote:
>
> >Another thing, I realised that the only instructions which require a
> >bit-bucket are branches.
>
> For writes. Do none require the bitbucket to read zero? Or are you
> always using immediate for that?
The only case where we needed a zero-tied reg was for loading an
immediate into a register, in one instruction rather than by e.g.
and r0, value, r0
or r0, value, r0
but after adding "move", that is no longer needed. Futher, the only
instructions which can unintentionally modify registers are branching
instructions. We could even drop the write-back of the return address
on jumps, since this is already know at compilation time, and can be
loaded explicitely as in
jump subroutine ; jump to subroutine...
move my_return_addr, r0 ; ...after saving return address
my_return_addr:
It saves us the pc+1 logic at the expense of one extra instuction for
subroutine calls.
> >Where do I find the definitions of these fifos?
>
> There are no such definitions. I made them up randomly on the spot.
> When we design the surrounding logic, we'll give them numbers.
Your precise descriptions of what the various pipes where used for was
what really convinced my that they already existed.
> One thing we'll do when processing command packets is some sort of
> bit-picking thing where we do something or not depending on the value
> of a bit in a register value. For instance, the packet header can
> contain a set of flags for option registers. We'll walk down the list
> in order and whenever a flag bit is set, we'll pop another word out of
> the DMA fifo and write it to the correct register in the GPU.
I remember you already suggested we can shift the bit to the sign
position and branch-if-negative for this, so then I think we're fine
with the bit-shuffling functionality.
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
