[Libre-soc-bugs] [Bug 765] Add way for instructions to specify in csv if they have OE field

[bugzilla-daemon at libre-soc.org]

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

--- Comment #1 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=openpower/isatables/minor_5.csv;h=c0260dbf65e18ac3d4c1abe623becf5c77159810;hb=b55f37ee14b3253087f0a743eb795b53e59f25d2

   3
0010010110-,SHIFT_ROT,OP_GREV,RA,RB,NONE,RT,NONE,CR0,0,0,ZERO,0,NONE,0,0,0,0,0,0,RC,0,0,grev,X,,1,

notice how you've requested "RC" post-processing?

    0,-->RC<--,0,0,grev,X,,1,

RC and OE typically work together and are really only supposed to be
applied to arithmetic operations (not logical ones).  the reason why
microwatt specifies them together is because in those arithmetic
operations, you process RC=1 and OE=1 together including reading
and writing of XER.SO, where only under certain conditions is XER.SO
_not_ written to... but that cannot be determined at issue-time
(i explained this in another bugreport about 6 weeks ago)

i wondered a year ago when fighting with understanding on this whether
to add an OE field to the CSV files, you can see the link to the archive.
in the end decided against it because it would deviate from what microwatt
does.

in my mind the question is not entirely about whether the CSV files should
support a separate OE encoding but whether grev should have an RC=1 option
in the first place: if it was a bug due to cut/paste then this bugreport
should be closed as "INVALID".

Rc=1 is kiiinda also supposed to only be used for arithmetic operations,
[numerical integers - obviously grev in no way fits that category]
and because any that violate that rule are exceptional, a case could be
made to *not* have a CSV OE encoding, such that instead the source code
for PowerDecoder2 is in fact *forced* to have an explicit documented
explanation as to why the exceptional circumstances exist. trying to
fit that explanation into CSV file format is completely inappropriate,
obviously.

now, if on the other hand it turns out that a large number of the
bitmanip instructions being added *do* need - as a group - an Rc=1
field but no OE - then that's a different matter.  however that's
best discussed separately, under a completely different bugreport,
evaluating whether the bitmanip instructions should have Rc=1.
most of them won't, because they don't calculate standard
arithmetic-integer-numeric results. GF will be a bundle-o-fun to
work _that_ one out, what does GT and LT even mean, in GF arithmetic.

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