[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