2007/3/25, Timothy Normand Miller <[EMAIL PROTECTED]>:
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:
> > 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.
What do you called an 'I/O op' ? A specific instruction ? If you do a memory mapped load/store unit, the cpu will be easier but you will lose few cycle and maybe few complexe function, like read/modify/write, bus locking, etc...
> > > > > > 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.
You could "hide" the condition register, like a state of the register set (==0, >0, <0, etc...).
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
You lake of memory space ? To be aligned to 8 bits or 32 bits word is only important for general purpose cpu. There you will have dedicated memory. With 1 or 2 more bits, you could often save 32 bits one or more and with a speed increase.
apply this only to some instructions we'll start to get a somewhat unwieldy unorthogonal instruction set.
Sur but do you plan a c compiler for it ? The instruction could not be orthogonal if the software and the hardware are develpped in the same time.
The idea here is to maximize the clock rate at the expense of having to use some extra instructions sometimes.
Those depend only of the software. So you need the software to know. And you could have it, because you will run a very specifi code on it.
> > 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.
Not pipeline hasard permit much more optimisation.
-- 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)
