[Libre-soc-bugs] [Bug 865] implement vector bitmanip opcodes

[bugzilla-daemon at libre-soc.org]

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

--- Comment #24 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
https://libre-soc.org/irclog/%23libre-soc.2022-06-24.log.html#t2022-06-24T23:07:05

Andrey, i'm answering here:

> just made another test case for bmask, but as I was about to run it,
> noticed the generated python function in av.py is bad

ah no it isn't.

> it generates these statements "if eq(_RB, 0)"

that's correct.  it's from: "if _RB = 0"

> but now noticed "mode" is not defined.

it's called "bm" and i renamed it in the demo-code bmask.py
to help there

https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=c7e7ea66564c9c2ba1a1b1f931b6d37f0269b72a

> It's part of the opcode, but does it need to be
> one of the input arguments?

rright, ok, so this is... a complex part of python programming.
the pseudo-code is "global" in nature (it was never intended to
be used as an *actual* programming language: we were literally
the first people in the world to *make* it a strictly-defined
deterministic programming language)

the key word there is "global"

python is different: there is in fact *local* and global variables,
and there are strict rules about how those are separated.  in
particular, in class functions.

now, so as not to make an absolute pig's ear out of the pseudocode
compiler, i made a deliberate decision to bypass some of the rules
set by python.

https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/isa/caller.py;h=941a89f0bb2eedfc323b3a51c52464bd8cbd03ef;hb=a7f3fa7ab2c87d75d0c562eb12d73e01d19095f1#l1950

that's based on a stackoverflow question "how do i explicitly inject
variables into a function namespace"

and as jacob later says, it basically allows the X-Form / BM2-Form /
whatever-Form opcode fields to be "injected" into the Simulator
function.  look here, in av.py:

from openpower.decoder.isa.caller import inject

    vvvvvv
 -> @inject() <-
    ^^^^^
    def op_bmask(self, RB, RA):
        if eq(_RB, 0):
            mask = concat(1, repeat=self.XLEN)
        else:
            mask = RB

> Also in your pseudo-code

in *the* pseudocode.

>  you're skipping bit 0 of "mode" (starting with mode[1])

(bear in mind i renamed "mode" to "bm")
no, i haven't.  you've misinterpreted this:

    a1 = ra if bm&1 else ~ra

that's an *INTEGER* (bm) and the expression "bm&1" is testing BIT ZERO
it helps to view it as this:

    a1 = ra if bm&0b00001 else ~ra

or this:

    a1 = ra if bm&(1<<0) else ~ra

the "0" there refers to "bit 0".

if you were correct (which you're not), then it would be:

    a1 = ra if bm&2 else ~ra

*that* would be testing bit 1.

BUT

butbutbut

PLEASE REMEMBER that whilst the python code bmask.py is in "normal" order
(LSB0), the av.mdwn is in ***MSB0 ORDER***

thus, these two pseudocode lines from av.mdwn here:

    a1 <- ra
    if bm[4] = 0 then a1 <- ¬ra

*ARE* repeat *ARE* repeat *ARE* directly and EXACTLY equivalent to this
from bmask.py:

    a1 = ra if bm&1 else ~ra

why? because bm is 5 bits long, and therefore bm[4] refers to the LEAST
significant bit **NOT** repeat **NOT** to the most significant bit.

bottom line *do not* modify the pseudocode, it is correct.  if you think
you have to modify it, please stop and think "*why* is this correct, what
have i not understood about the utter mind-melting weirdness that takes
everyone who ever sees MSB0 ordering for the first time 6 months to get
used to".

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