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

[bugzilla-daemon at libre-soc.org]

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

--- 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.