[Libre-soc-dev] All div pipe tests pass

[Luke Kenneth Casson Leighton]

On 10/9/20, Jacob Lifshay <programmerjake at gmail.com> wrote:
> On Wed, Oct 7, 2020 at 2:57 PM Luke Kenneth Casson Leighton
> <lkcl at lkcl.net> wrote:
>>
>> On 10/7/20, Jacob Lifshay <programmerjake at gmail.com> wrote:
>>
>> >> do you have / know of examples / cases / instructions where
>> >> undefined==0 is not true?
>> >>
>> >
>> > modsw has some: the top 32-bits of the result are undefined and power9
>> > sign-extends the lower 32-bits
>> >
>> > there are a whole pile in the mul* instructions.
>>
>> ah. then we definitely need to list them and go over all of them
>
> My method for finding them has been to go through the tests for the
> instructions and find where they fail, compare the results of the
> simulator to power-instruction-analyzer, then modify the spec
> pseudo-code till that case passes, then go onto the next case. This
> makes it difficult to just come up with the list of instructions you
> wanted without fixing them as I go, otherwise you end up with tons of
> false-positives due to eg. using DIVS instead of `//`.

this is just part of spec development.  it's a royal pain and requires
ridiculous patience.

fixing the pseudocode, i have no problem with, at all.  introducing
something as drastic as a new concept of "undef", this is not a good
idea without consulting e.g. Paul Mackerras or Mike Neuling.

> So, I'm going to just go through the pseudo-code replacing uses of
> `undefined` with `undef` and fixing the test failures.

please, really, this is ringing very large alarm bells, we have a huge
set of changes outstanding and the WG hasn't yet formed.

it would be better to have the pseudocode return explicit magic
constants for overflow situations.

or, is that actually what you meant?

that undef(x) *returns* x, thus indicating to readers that the value x
is "actual POWER9 behaviour but the spec stupidly and dangerously says
actually you can do whatever you like, here, no really"

that i *am* happy with however i would prefer that the keyword be left
as "undefined" and for pyparser to detect "undefined" and
"undefined(x)" and to replace that with an INTERNAL and SPEC INVISIBLE
call to "undef"

effectively another way to look,at that idea is that "undefined" the
spec keyword would map internally to a call to "undef(0)"




> We can still
> easily get the code for the "Fix the power spec without changing
> undefined behavior" proposal by just converting all `undef` calls back
> to `undefined` and deleting dead code.

if i am reading that correctly this means we now have two sets of isa
mdwn files to maintain: one that is to be presented to OPF and has all
of the crossrefs to it from opf-hdl-cores and one we actually use.

or

if modified to "undef" this says to anyone reading the opf-hdl-cores
archives, "we are officially wishing to propose changing undefined to
undef as part of the spec"

or

we are breaking ties and saying we no longer wish to propose this
pseudocode at all for official inclusion.

all three of these options are not very good ones.

l.