[Libre-soc-bugs] [Bug 325] create POWER9 TRAP pipeline

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Wed Jul 22 17:14:23 BST 2020


--- Comment #111 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Samuel A. Falvo II from comment #108)
> (In reply to Luke Kenneth Casson Leighton from comment #104)
> > 1. we are following microwatt, which has not implemented hypervisor. 
> After reading its readme, it also doesn't yet implement supervisor state
> either.  Can you confirm whether we are aiming to implement supervisor state?

we're tracking microwatt explicitly.  when microwatt implements supervisor,
we read the code and update Libre-SOC accordingly.

> > 3. the bit fields are in *PowerISA* order and need reversing: this is why we
> > use DecodeFields, why FieldSelectableInt exists.
> In all the IBM specs I've read in the past, bit 0 (or, alternatively, the
> smallest numbered bit) is considered to be the most significant bit for any
> field.  This is a convention that dates back to before the IBM System/360.
> In other words, if there is a 5-bit field, its bits are *labelled* according
> to the top row, but have arithmetic *meaning* according to the bottom row:
>     0 1 2 3 4
>     M . . . L
>     4 3 2 1 0
> where M=2^4, and L=2^0, if those bits are set.

yep.  this *directly* contradicts the expectation of everyone else's
conventions, *and* it is inverted from python behaviour.

this is why we set up the Decode Fields - and use them.  self.fields.FormNNNN
*specifically* sets up (named) fields, *specifically* performs the bit-order
inversion needed so that it is *not* necessary for programmers to do that,
laboriously, each and every time.

use of "op.insn[....:....]" we're therefore *not* doing.  the code that
you wrote actually checks the *MSB* (bit 5) of LEV, in both the trap
main_stage and the spec, because Const(1, 6) is *NOT* an IBM/PowerISA
bit-order constant.

so that needs fixing: by following the convention i set, and not removing
code in places where that convention is used.

> What you're saying contradicts my understanding, and what I've read before. 

it took Michael and i several days to get right.

> I tried looking in the OpenPower ISA books for an explanation (it seems like
> anyone wanting to write an assembler would have an absolute need to know
> this data), but I found nothing!

i know.  it's there - i have said a couple of times, now: section 1.3.4
"Notation", page 4:

- Bits in instructions, fields, and bit strings are
  numbered from left to right, starting with bit 0

- The leftmost bit of a sequence of bits is the
  most significant bit of the sequence.

> This seems like a gaping hole in the spec, and I'd argue it needs top
> priority for resolution by the OpenPower group.

it's not missing: it's just not emphasised, it's stated plainly, once and
only once, on p4  then the remaining 1,500 pages assume that you've read
those two sentences and know what they mean.

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

More information about the libre-soc-bugs mailing list