[libre-riscv-dev] [Bug 278] New: POWER v3.0B spec ambiguity on EXTS and missing EXTZ

[libre-riscv-dev] [Bug 278] New: POWER v3.0B spec ambiguity on EXTS and missing EXTZ

[bugzilla-daemon]

http://bugs.libre-riscv.org/show_bug.cgi?id=278

            Bug ID: 278
           Summary: POWER v3.0B spec ambiguity on EXTS and missing EXTZ
           Product: Libre-SOC's first SoC
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: CONFIRMED
          Severity: enhancement
          Priority: ---
         Component: Specification
          Assignee: lkcl@lkcl.net
          Reporter: lkcl@lkcl.net
                CC: libre-riscv-dev@lists.libre-riscv.org
   NLnet milestone: ---

sent to openpower-hdl-cores

continuing with the implementation of a simulator that is taken
directly - and literally - from the pseudocode and definitions of
functions in the spec, we have hit an "inconvenient" definition.
EXTS, section 1.3.4, page 6:

EXTS(x) Result of extending x on the left with sign
        bits

the problem is illustrated by asking the very simple question, "how many bits?"

also, note: a definition for EXTS64 and EXTZ, both of which are *used*
in the spec - and for which their definition may easily be deduced
[however that *defeats the purpose of having a spec*...] - are both
missing.

EXTZ suffers from the same problem as EXTS, namely the number of bits
to extend to, is missing.

we have a "class" (SelectableInt) which records both the value and the
*length* of the value (in number of bits), therefore determining where
*from* (to *begin* zero-extending or sign-extending) is not a problem.
where to *stop* extending is the problematic part.

this causes us some considerable inconvenience when it comes to
"deducing" where to stop sign/zero-extending.  example, in cmprb:

src21hi <- EXTZ((RB) 32:39 )

if L=0 then
   in_range <- (src22lo <= src1) & (src1 <= src22hi)

so.. um... we zero-extend RB bits 32:39, to an *unknown* - and
completely unspecified - length, then perform comparisons on those
values, not having any information?

now, yes, we know that zero compared to zero is obviously zero,
therefore we could arbitrarily pick some random length, here, and
"everything would work".

a less-obvious example

if AA then NIA <-iea EXTS(LI || 0b00)
else       NIA <-iea CIA + EXTS(LI || 0b00)

i believe, here, that it is expected that the "deduction" of the
sign-extension length should be by way of knowing the bit-length of
NIA!

to that end, we can probably get away with EXTS returning an object
that is specifically marked, "ok, we have no idea what the actual
bit-length is going to be, so let's set it to 1,000,000 and work it
out when the object is actually used".

 actually... we can't...

lbz RT,D(RA)
-------
if RA = 0 then b <- 0
else           b <- (RA)
EA <- b + EXTS(D)

because when b=0, that's an integer of undefined arbitrary length!

now, if b had been assigned to 0-subscript-64 (64 bit zero) *then* we
would have the information needed.

so this actually turns out to be quite problematic.  actually: in the
lbz case if the definition had been:

b <- (RA|0)
EA <- b + EXTS(D)

where the definition for (Reg|0) *is* defined, clearly (Notation
section 1.3.2, p4) then that would actually be fine!  this because it
is obvious from the definition of (Reg|0) that the result is 64-bit.

with that being defined as 64-bit, b would become 64-bit, and thus
when EXTS(D) was added to b, the "unknown" length of EXTS(D) could be
resolved.

it would be *significantly* better if EXTS was retired in favour of
EXTS64 and EXTS32!  i appreciate that this requires a careful and
comprehensive review of every single usage of EXTS.

perhaps i can help there by collecting debug information either from
actual execution or from the parser as to what bit-lengths EXTS (and
EXTZ) interact with?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

[libre-riscv-dev] [Bug 278] POWER v3.0B spec ambiguity on EXTS and missing EXTZ

[bugzilla-daemon]

http://bugs.libre-riscv.org/show_bug.cgi?id=278

Jacob Lifshay <programmerjake@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |programmerjake@gmail.com

--- Comment #1 from Jacob Lifshay <programmerjake@gmail.com> ---
Reply on openpower-hdl-cores:
http://lists.mailinglist.openpowerfoundation.org/pipermail/openpower-hdl-cores/2020-April/000022.html

On Sat, Apr 4, 2020, 07:16 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> continuing with the implementation of a simulator that is taken
> directly - and literally - from the pseudocode and definitions of
> functions in the spec, we have hit an "inconvenient" definition.
> EXTS, section 1.3.4, page 6:
>
> EXTS(x) Result of extending x on the left with sign
>         bits
>
> the problem is illustrated by asking the very simple question, "how many
> bits?"


Maybe it would work to treat it as a conversion from a bitstring to a
mathematical integer (like a Python3 int) where it can then be converted
back to a bitstring when it is assigned to something with a size again?

You don't need an infinite number of hardware bits to represent the
mathematical integer, since you know the exact range the values fall in so
you can calculate exactly how many bits you need, sign/zero-extending as
needed when converting back to a bitstring.

Jacob

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

[libre-riscv-dev] [Bug 278] POWER v3.0B spec ambiguity on EXTS and missing EXTZ

[bugzilla-daemon]

http://bugs.libre-riscv.org/show_bug.cgi?id=278

--- Comment #2 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Jacob Lifshay from comment #1)

> > EXTS(x) Result of extending x on the left with sign
> >         bits
> >
> > the problem is illustrated by asking the very simple question, "how many
> > bits?"
> 
> 
> Maybe it would work to treat it as a conversion from a bitstring to a
> mathematical integer (like a Python3 int) where it can then be converted
> back to a bitstring when it is assigned to something with a size again?

hmm...

   if AA then NIA <-iea EXTS(LI || 0b00)
   else       NIA <-iea CIA + EXTS(LI || 0b00)

the args to that would be integer-values by that point (not the AST)
so it would in theory be ok...

> You don't need an infinite number of hardware bits to represent the
> mathematical integer, since you know the exact range the values fall in so
> you can calculate exactly how many bits you need, sign/zero-extending as
> needed when converting back to a bitstring.

if it's ok i'd like to go with "EXTS returns bitsize of 256" and see how
that goes, because string-to-int comes with a performance penalty.

yes so do python Longs (to use a python2-ism) however i don't believe it will
be as high.

keep this bug open so we have an alternative idea.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

[libre-riscv-dev] [Bug 278] POWER v3.0B spec ambiguity on EXTS and missing EXTZ

[bugzilla-daemon]

http://bugs.libre-riscv.org/show_bug.cgi?id=278

--- Comment #3 from Jacob Lifshay <programmerjake@gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #2)
> (In reply to Jacob Lifshay from comment #1)
> > You don't need an infinite number of hardware bits to represent the
> > mathematical integer, since you know the exact range the values fall in so
> > you can calculate exactly how many bits you need, sign/zero-extending as
> > needed when converting back to a bitstring.
> 
> if it's ok i'd like to go with "EXTS returns bitsize of 256" and see how
> that goes, because string-to-int comes with a performance penalty.

Basically all that's needed is to create a new type with the original bits and
record if it's sign or zero extended, no Python strings need to be created or
processed. What I called a bitstring above is basically a bitvector and the
same as the underlying bits in a nmigen Signal, I used the name bitstring
instead of nmigen Signal since there are people on the openpower list who
aren't familiar with nmigen.
> 
> yes so do python Longs (to use a python2-ism) however i don't believe it
> will be as high.

nmigen's simulator uses python longs internally to represent the value of a
Signal, so it shouldn't be that much slower.

> keep this bug open so we have an alternative idea.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

[libre-riscv-dev] [Bug 278] POWER v3.0B spec ambiguity on EXTS and missing EXTZ

[bugzilla-daemon]

http://bugs.libre-riscv.org/show_bug.cgi?id=278

--- Comment #4 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Jacob Lifshay from comment #3)
> (In reply to Luke Kenneth Casson Leighton from comment #2)
> > (In reply to Jacob Lifshay from comment #1)
> > > You don't need an infinite number of hardware bits to represent the
> > > mathematical integer, since you know the exact range the values fall in so
> > > you can calculate exactly how many bits you need, sign/zero-extending as
> > > needed when converting back to a bitstring.
> > 
> > if it's ok i'd like to go with "EXTS returns bitsize of 256" and see how
> > that goes, because string-to-int comes with a performance penalty.
> 
> Basically all that's needed is to create a new type with the original bits
> and record if it's sign or zero extended, no Python strings need to be
> created or processed. 

oh ok - a different type, rather than an "actual python string".

or, a flag (in the SelectableInt) would do as well.  it's... slightly
better than overloading the meaning "bitlen=256".


> nmigen's simulator uses python longs internally to represent the value of a
> Signal, so it shouldn't be that much slower.

what i mean is... hmmm it's been a long time since i looked at the code:
i believe they use an int (long) for when numbers fit into a long, and
a different type - which takes far more time - when numbers go beyond
2^64.  this in the actual interpreter source code.

therefore, you won't know it, but if you use numbers greater than size 2^64
the interpreter slows down slightly.

i could be wrong about that, it's been a while since i looked at the
python interpreter source code.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

[libre-riscv-dev] [Bug 278] POWER v3.0B spec ambiguity on EXTS and missing EXTZ

[bugzilla-daemon]

http://bugs.libre-riscv.org/show_bug.cgi?id=278

--- Comment #5 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
hi michael, i reverted commit b5e4e847c2841189386da3509949d9206de92f8b
Author: Michael Nolan <mtnolan2640@gmail.com>
Date:   Sun Apr 5 14:31:48 2020 -0400

    Implement bug 278, comment 1 - better version of EXTS

the reason is that

unfortunately, as it wasn't a single-purpose commit, it's also reverted
this:

diff --git a/src/soc/decoder/isa/test_caller.py
b/src/soc/decoder/isa/test_caller.py
index aa6f23a..12db984 100644
--- a/src/soc/decoder/isa/test_caller.py
+++ b/src/soc/decoder/isa/test_caller.py
@@ -9,7 +9,7 @@ from soc.simulator.program import Program
 from soc.decoder.isa.caller import ISACaller, inject
 from soc.decoder.selectable_int import SelectableInt
 from soc.decoder.orderedset import OrderedSet
-from soc.decoder.isa import ISA
+from soc.decoder.isa.all import ISA


i'll leave that with you to fix?


the reason i reverted the use of exts() is because exts() returns
integers.

when it comes to SV, we will *need* things to be in classes such
as SelectableInt, because it will be there that the bitwidths
can be over-ridden (to implement the polymorphic behaviour of SV)

ints cannot have their behaviour over-ridden.

EXTS and the other functions will also at some point need to go into
a class, so that their behaviour can also be over-ridden.

however they can be dropped into the namespace as-is - appearing
to be global non-class-based functions - using the @inject decorator.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev