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

[bugzilla-daemon at libre-riscv.org]

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 at lkcl.net
          Reporter: lkcl at lkcl.net
                CC: libre-riscv-dev at 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.