On 3/25/07, Nicolas Boulay <[EMAIL PROTECTED]> wrote:
2007/3/25, Timothy Normand Miller <[EMAIL PROTECTED]>:
> On 3/22/07, James Richard Tyrer <[EMAIL PROTECTED]> wrote:
> > Timothy Normand Miller wrote:
> > Isn't it more usual to have a load store architecture with 2 address
> > operations? OTOH, there are supposed advantages to register set
> > processors (no accumulators).
>
> The idea is to have a load-store architecture, except that the "main
> memory" is only 512 32-bit words, and the graphics memory is accessed
> via I/O ports.
Don't you think you will win 1 or 2 cycles with a specific kind of load/store ?
I don't know what you mean. Are you suggesting more types of
load/store instructions? Perhaps a way to get at graphics memory
directly? The latency for getting access to graphics memory will be
up to hundreds of cycles (if it's busy) or as low as tens of cycles
(if it's not). Either way, it's a win to do it as an I/O op.
>
> > > This is also where we need to deal with branches. If the instruction
> > > is a branch, the condition needs to be resolved, and the address needs
> > > to be fed back to stage (1). This is why RISC processors typically
> > > have a delayed branch. The possible branch conditions are reg-value=0
> > > and reg-value!=0.
> >
> > Were you planing to have a skip on condition instruction?
>
> Not as such. Does MIPS have that? (Not to say that we have to be
> tied to that.) We COULD have it...
>
Conditionnal op could avoid few branches and few load/store. If we use
2 or 3 bits for contionnal execution like for conditionnal branchies,
you could win few cycle more.
Unfortunately, that would require another set of "condition"
registers. Part of the elegance of the MIPS design is that we don't
have to have them, which makes the design simpler. And we don't want
to reserve another 8 bits in the instruction word for this. And if we
apply this only to some instructions we'll start to get a somewhat
unwieldy unorthogonal instruction set.
The idea here is to maximize the clock rate at the expense of having
to use some extra instructions sometimes.
> Speaking of saving state, that reminds me. We could have interrupts.
> Having exceptions that are caused by part of the instruction pipeline
> complicates things horribly, but we could easily enough allow for
> interrupts, as long as they're always initiated from FETCH, and they
> never occur right after a branch instruction.
Does interrupt is an absolu necessity ? It complexify everything.
The one case where we could use them is when we're emulating a VGA
graphics mode. Reads and writes have to be processed through our CPU.
So either we poll, or we do interrupts. And truthfully, when doing
VGA, all we'll be doing is waiting for accesses, so polling won't be a
problem.
--
Timothy Normand Miller
http://www.cse.ohio-state.edu/~millerti
Open Graphics Project
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
