[Libre-soc-bugs] [Bug 1072] implement fcvt/fmv instructions in ISACaller (ls006)

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Thu May 18 06:05:25 BST 2023


--- Comment #34 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #31)
> (In reply to Luke Kenneth Casson Leighton from comment #30)
> > this is turning out to be a lot of work so i am increasing the budget.
> > we do have to be careful as there is supposed to be corresponding HDL
> > for them.
> yeah, I can implement hdl too, it shouldn't be all that complex, maybe 2-3
> days work,

from when you start until when you finish please keep an accurate log!
this will help you to get some feedback on whether your time-estimates
are accurate. the reason i ask that is because the last one you said
"it'll be 2 weeks" it turned out to be 4 months. as that is a consistent
systematic mistake that you make it's important for you to get some
feedback on (to yourself, by yourself)

> assuming soc.git already has basic support for fp ops
> (reading/writing FPRs and FPSCR). if not, adding basic fp support should be
> easily justifiable as a separate task under the
> integrate-ieee754fpu-into-soc task.

correct, it doesn't exist at all. good idea new task.  FPSCR can be
added as its *own* regfile - this is important.  copy style of XER.
FPR likewise.  see

essential to add FPSCRRegsEnum and FPRRegs Enum:

  31 # XXX MAKE DAMN SURE TO KEEP THESE UP-TO-DATE if changing/adding regs
  32 from openpower.consts import StateRegsEnum, XERRegsEnum, FastRegsEnum

please take GREAT CARE here, go slowly, make sure to follow process
"i am thinking of doing X, please review, i have done X, please review"
and WAIT for review feedback BEFORE going ahead to the next phase ok?

> should fmvtg/fcvttg be a new FU since it reads fprs and writes gprs? same
> thing with fmvfg/fcvtfg.

ohh yes. the decision is actually made by "register profile".  i.e.
examine *all* pipe_data.py and based on what you see there you will
find with 100% certainty that the "read-fpr&write-gpr" profile is
unique, but please do go through the exercise anyway

if later we want to reduce the number of FUs then it is possible
to amortise them with some additional HDL *without* having to
modify the fu/*/*.py code itself, but the other way round
(separating things that have *explicitly* been merged into
 one fu) is *not* possible without a hell of a lot of work.

madd is an example of something that also goes in its own
completely separate fu because there are no other pipelines
implemented yet with GPR-3-in GPR-1-out.

basically "if different reg profile ==> separate FU" but that
INCLUDES if the pipeline itself can CANCEL a regfile read or
write.  i.e. anything that is OE=1 or Rc=1 will STILL be
consider "XER" and "CR" to be part of the reg profile because
the *FU itself* has control over the decision whether to write
(or not).

i.e. don't for goodness sake separate out Rc=1 and/or OE=1 into
separate FUs for the same instruction. likewise you can also see
that OP_ADD takes all the "neg*" instructions because one of
the operands (RB) can be an immediate, it is *STILL* the same
reg profile, neg is *NOT* separated into a separate pipeline.

You are receiving this mail because:
You are on the CC list for the bug.

More information about the libre-soc-bugs mailing list