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

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=1072

--- 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
https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/regfile/regfiles.py;hb=HEAD

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
https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/fu/logical/pipe_data.py;hb=HEAD

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.