[Open-graphics] Multipliers in oga1hq
Timothy Normand Miller
theosib at gmail.com
Sat Sep 1 13:23:36 EDT 2007
On 9/1/07, Petter Urkedal <urkedal at nbi.dk> wrote:
> So, let's consider integrating Farhan's version in the nanocontroller.
Farhan would need to officially give us (Traversal specifically)
rights to use his work.
> code? (Does DMA require multiply at all, other than powers of 2?)
Doubtful. But if I'm wrong, we maybe should reserve an opcode or two
for some instruction we don't yet know about.
> I'd go with the non-blocking out-of-band approach. That is, the
> programmer will count instructions before fetching the result.
I generally prefer this myself.
> As a slight variant, we can hard-code the multiplication result to r31
> and drop the fetch-product instruction. That's just as easy to
> implement, and it saves one cycle, since it means the product can be
> directly used as an operand to the ALU.
I'm not sure we want to add additional MUXing after the REG stage. It
might be better to move it into the MEM stage. This is especially not
a problem since we have gobs of time to schedule when the product is
Having a special instruction to initiate the multiply would save us
one cycle (worth it?). Otherwise, there would be two moves into the
scratch/io space. But the product is only a single word fetch.
Putting it into r31 would save a cycle, because we wouldn't have to
move it into a register first before using it as an operand to another
My main concerns are the extra multiplexing logic hurting our max clock rate.
> The introduction of interrupts, if needed, will not cause problems as
> long as interrupt handlers don't use the multiplier. Moreover, if an
> interrupt handler needs to use the multiplier, this is also possible:
> When the interrupt handler is sure any pending multiplication is
> finished, it can save the result R. Then it can do it's own
> multiplication. Before returning to normal code, it must perform a
> multiply R*1 and wait long enough for the result to be available.
I think we may in fact need interrupts, and I'm struggling with it.
The problem is VGA graphics modes. In 640x480x16 and such,
framebuffer reads and writes are not simple accesses. You can apply
raster operators to writes, and you can make reads fill a blt buffer
larger than your word size so that when you write, it causes more than
a word size to get written out. This way, you can bitblt faster than
you can move data over the bus.
Now, for VGA mode, mostly what the controller does is read VGA text or
pixels and convert them in the background into pixels suitable for our
video controller. At the same time, we want the controller to handle
the extra smarts of VGA. One way to do this is to support interrupts;
when a PCI access comes in, we can intercept it and do the extra
stuff. While writes could be queued for us to process periodically,
reads have to be processed as soon as possible.
Interrupts won't stall lower parts of the pipeline, but they would
divert the instruction flow. We need to determine how this will
affect our static instruction scheduling.
Correct me if I'm wrong, but a subroutine call stores the return
address into r31, right? Of course, since that's under main program
control, no problem! But with interrupts, I think we should dump the
return address into a redefined address in the scratch memory.
What about context switches? Should we require the ISR to copy
registers to the scratch memory? That's a fair amount of overhead,
depending on how many we need to clobber. How about doubling the size
of the register file? The lower half for normal execution, the upper
half for interrupts. (Like how the Z80 did it.) (In this case, the
interrupt return address appears in what we might internally call
r63.) Oh, and don't forget the delayed branch issue and how it'll
affect interrupt--one extra instruction from the main program will get
executed, so the return PC must account for that, and be sure to
consider the situation where the interrupt arrives at the same time as
a branch instruction is being fetched in the main program.
Timothy Normand Miller
Open Graphics Project
More information about the Open-graphics