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

Re: [bender] Re: [openrisc] Important or1k question...



Hello,

sorry for late reply. I'm out of the country right now.

Anyway we'll change floating-point and vector stuff in the future. Right
now I think it is most important that we (or at least me) focus on OR1200.

I hope this won't upset software people, but you might will have to make
some changes in software since I have problems meeting 400MHz and <1W
constraints (size isn't an issue right now and it should be according to
expectations - less than 1sqmm). Maybe speedins't such a problem right
now, but when we move to backend with OR1200, there might be a problem
keeping up with the constraints. I'd like to remind everyone that these
constraints are really demanding compared that we are doing soft core and
not custom made. I talked with some very experience people in backend and
they say that we might have to sacrifice some fancy functionalities (for
example debug unit looks like something that _might_ go through changes ).
Please don't get upset since this is just a warning - I'll see in near
future what kind of measures will be necessary.

regards,
Damjan

On Wed, 4 Jul 2001, Matan Ziv-Av wrote:

> On Mon, 2 Jul 2001, Chris Ziomkowski wrote:
> 
> > And, as long as we're on the subject (I can already guess why
> > Damjan doesn't want to do this...but it is REALLY annoying) Can
> > we either A) add an offset addressing mode to the lvf.[s/l][d/w]
> > instruction, or B) make this instruction do an auto increment of
> > the address register so that sequential loads/stores will go into
> > sequential locations?
> > 
> > I can't just add 8 to a floating point register to increment the
> > address now can I?
> > 
> > Alternatively, can we simply use an integer register for the address
> > so that all of these problems just go away?
> > 
> > Comments?
> 
> Maybe completely get rid of lvf.[sl][dw] ?
> It only adds a single instruction per load/store (mtspr/mfspr).
> It also wastes a gpr used as intermediate, but saves an fpr used as
> address.
> 
> If those instructions stay, I think that using gprs as address makes
> most sense.
> 
> -- 
> Matan Ziv-Av.                         matan@svgalib.org
> 
> 
> --
> To unsubscribe from openrisc mailing list please visit http://www.opencores.org/mailinglists.shtml
> 

--
To unsubscribe from openrisc mailing list please visit http://www.opencores.org/mailinglists.shtml