[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [f-cpu] Re: Floating-Point



> 
> On Wed, Aug 29, 2001 at 09:48:00AM +0100, Hans Summers wrote:
> [...]
> > Previously you insisted on fixed latency. 
> 
> Latency may depend on the chunk (= operand) size, but not on the
> operands.  That is, it is known at *decode time*.

I understand that but previously it was written:

> Michael Riepe wrote:
> > On Mon, Aug 20, 2001 at 11:33:05PM +0200, Yann Guidon wrote:
> > [...]
> > > > > If there is something to say if the outed data is 
> > > > > correct or not ?
> > > > Currently not; the scheduler should know.  But we can 
> > > > add a `here is the result, take it or I'll throw it away
> > > > in the next cycle' signal.
> > > currently, only the IDIV has one.
> > No it doesn't, but I can add one :)
> 
> if you use a fixed-latency approach, you don't need one.
> however, you could want to "optimise" one day with a data-dependent
> algorithm (leading MSB strip, etc...) and as long as the latency is
> still higher than the scheduling queue's depth, it is possible to
> have _one_ "ready" flag if it can be reased enough in advance.

Here we are talking about more than just chunk-size-dependent latency, we
are talking about real data-dependent latency right? In this case my
alternative scheduler is more suitable: for the time being it can be made
fixed latency and still obtain a simpler scheduler with other benefits (e.g.
greater maintainability and modularity), and in the future it is easy to
move to variable latency data-dependent optimisations without a complete
redesign.

------------------
Hans Summers
http://www.HansSummers.Com 
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/