Re: [f-cpu] Manual 0.2.6

[Yann Guidon <whygee@f-cpu.org>]

hi,

Cedric BAIL wrote:
> Quoting Thomas Lavergne <thomas.lavergne@laposte.net>:
> 
> > >>>      6.1.2 `loadcons':
> > >>>              The jury is still discussing this.
> > >>
> > >>Ok, but you and thomas write the latest post, because nobody answer, I
> > >>was thinking it was decided.
> > > i am definitely against.
> > I'm definitely for...
> > Or for any other proposition that allow simple constant loading of any
> > size. And thats not the case for your loadcons/loadconsx.
> 
> So it's under discussion ;-)
> 
> Yann the reason you give to me for not doing it is only that you need 3 times
> more place for the version that Thomas want than for the one you whant, right >
> But Thomas version is more scalable and orhtogonal. And in fact I don't see
> that it cost so much. (I think you didn't explain completly your reason on
> the mailing list, like you explain to me, so if you have time it would be a
> good idea)

* if you want to shift, use the shifter unit (SHL) : it's its job.
  The purpose of Xbar is not to shift.

* a shifter takes more room than you would think. More
  room means decreased frequency and higher power consumption.
  Even though the shift is only 16 bits, remember that
  the "cost" is proportional to N*M (if M is the number of
  bits in the word and N is the shift amount).
  And even though there are several metal layers and better
  synthesizers, you can't modify this basic topological rule.
  i think that Michael's shifter will not match the speed of
  other units if he keeps wanting a single cycle shift.

* The Xbar is already very loaded :
  - 4 bypass (2 write ports with 2 bypass nets each)
  - 3 read ports that must feed half a dozen of inputs
  - roughly 10 execution units (and still no FP in sight)
  - CIP, NIP; TLB, immediate data
  and i probably forget many things.
  In the beginning, Xbar was a place where we could do
  whatever we wanted but now it's proably as heavy and
  slow as the register set.  Adding a shifter in this
  critical datapath would slow down the whole circuit.

* Show me the proposed instruction form.

Remark : the existing loadcons shifts the constant before
use (not exactly, but it's the principle). it benefits
from the latency of the decoder and the Xbar (2 cycles
are enough to amplify and select the right bits).

The "shifting loadcons" does the reverse and the shifting cost
is put in the critical datapath of the Xbar. And shifting has
a cost (don't tell me "it's only a mux").

> Cedric
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/