[libre-riscv-dev] [Bug 272] New: functions needed in POWER simulator which match 3.0B spec

[libre-riscv-dev] [Bug 272] New: functions needed in POWER simulator which match 3.0B spec

[bugzilla-daemon]

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

            Bug ID: 272
           Summary: functions needed in POWER simulator which match 3.0B
                    spec
           Product: Libre-SOC's first SoC
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: CONFIRMED
          Severity: enhancement
          Priority: ---
         Component: Source Code
          Assignee: lkcl@lkcl.net
          Reporter: lkcl@lkcl.net
                CC: libre-riscv-dev@lists.libre-riscv.org
   NLnet milestone: ---

we need some functions, named EXTS, EXTZ64 and so on, which
are in the spec, and need to be implemented.  this is so that
the auto-generated code, which is taken directly *from* the spec
(pseudo-code fragments, converted to actual python code),
can call them.

michael can you take a look?

-- 
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 272] functions needed in POWER simulator which match 3.0B spec

[bugzilla-daemon]

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

--- Comment #1 from Michael Nolan <mtnolan2640@gmail.com> ---
Would this be in power_pseudo.py? Or the POC simulator I wrote?

-- 
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 272] functions needed in POWER simulator which match 3.0B spec

[bugzilla-daemon]

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

--- Comment #2 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Michael Nolan from comment #1)
> Would this be in power_pseudo.py? Or the POC simulator I wrote?

in the simulator, as a base "convenience" class of some kind.

basically, right now, code like this (which is extswsli)

    n  <- sh[5] || sh[0:4]
    r  <- ROTL64(EXTS64(RS[32:63]), n)
    m  <- MASK(0, 63-n)
    RA <- r & m

currently gets turned into this:

    n  = sh[5] + sh[0:5] # these are lists so they get concatenated
    r  = ROTL64(EXTS64(RS[32:64]), n)
    m  = MASK(0, 63-n)
    RA = r & m

however what is *actually* needed is:

    n  = sh[5] + sh[0:5] # these are lists so they get concatenated
    r  = self.helperfns.ROTL64(self.helperfns.EXTS64(RS[32:64]), n)
    m  = self.helperfns.MASK(0, 63-n)
    RA = r & m

and some other small changes.

remember, the code that's being executed will be *in* the simulator.
it's only generated *by* the compiler (power_pseudo.py).

welcome to compilers, they're a bit of a mind-bender :)

-- 
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 272] functions needed in POWER simulator which match 3.0B spec

[bugzilla-daemon]

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

--- Comment #3 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
these are the functions, listed in 3.0B section 1.4.3 p6 - p7

ABS(x)     
BCD_TO_DPD(x)
CEIL(x)   
DOUBLE(x) 
DPD_TO_BCD(x)
EXTS(x)    
FLOOR(x)
GPR(x)  
MASK(x, y)
MEM(x, y)
ROTL64(x, y)
ROTL32(x, y)
SINGLE(x) 
SPR(x)

there's really not many of them.

-- 
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 272] functions needed in POWER simulator which match 3.0B spec

[bugzilla-daemon]

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

--- Comment #4 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
found some of the helpers, look great michael.  i think i may just be able
to import them from helpers.py and, yes, assume they're globally imported.
should be fine.

btw some whitespace crept in again:

+
+        <
+        <
+    def assertHex(self, a, b):
+        msg = "{:x} != {:x}".format(a, b)
+        return self.assertEqual(a, b, msg)
+

-- 
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 272] functions needed in POWER simulator which match 3.0B spec

[bugzilla-daemon]

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

--- Comment #5 from Michael Nolan <mtnolan2640@gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #3)
> these are the functions, listed in 3.0B section 1.4.3 p6 - p7
> there's really not many of them.

Just a note: SPR(x), GPR(x) and MEM(x, y) will need to be located outside
helpers.py so they can access their respective memories

-- 
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 272] functions needed in POWER simulator which match 3.0B spec

[bugzilla-daemon]

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

--- Comment #6 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Michael Nolan from comment #5)

> Just a note: SPR(x), GPR(x) and MEM(x, y) will need to be located outside
> helpers.py so they can access their respective memories

yes, see http://bugs.libre-riscv.org/show_bug.cgi?id=269#c3

-- 
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 272] functions needed in POWER simulator which match 3.0B spec

[bugzilla-daemon]

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

--- Comment #7 from Michael Nolan <mtnolan2640@gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #3)
> these are the functions, listed in 3.0B section 1.4.3 p6 - p7
> 
> BCD_TO_DPD(x)
> DPD_TO_BCD(x)

The instructions that use these pseudocode functions (cbcdtd and cdtbcd) cause
the qemu power9 machine to trap to an exception handler. Should I bother trying
to implement them at the moment?

-- 
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 272] functions needed in POWER simulator which match 3.0B spec

[bugzilla-daemon]

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

--- Comment #8 from Michael Nolan <mtnolan2640@gmail.com> ---
Status of each helper function in the document:

ABS(x)          - Not found in pseudocode
BCD_TO_DPD(x)   - Traps on QEMU
CEIL(x)         - Not found in pseudocode
DOUBLE(x)       - Float - needs softfloat library
DPD_TO_BCD(x)   - Traps on QEMU
EXTS(x)         - Implemented
FLOOR(x)        - Not found in pseudocode
GPR(x)          - Needs internal implementation
MASK(x, y)      - Implemented
MEM(x, y)       - Needs internal implementation
ROTL64(x, y)    - Implemented
ROTL32(x, y)    - Implemented
SINGLE(x)       - Float - needs softfloat library
SPR(x)          - Needs internal implementation

-- 
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 272] functions needed in POWER simulator which match 3.0B spec

[bugzilla-daemon]

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

--- Comment #9 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Michael Nolan from comment #7)
> (In reply to Luke Kenneth Casson Leighton from comment #3)
> > these are the functions, listed in 3.0B section 1.4.3 p6 - p7
> > 
> > BCD_TO_DPD(x)
> > DPD_TO_BCD(x)
> 
> The instructions that use these pseudocode functions (cbcdtd and cdtbcd)
> cause the qemu power9 machine to trap to an exception handler. Should I
> bother trying to implement them at the moment?

... naah :)

(In reply to Michael Nolan from comment #8)
> Status of each helper function in the document:
> SINGLE(x)	- Float - needs softfloat library

let's leave this one for now.  i'd like to focus on integer initially.

i am planning to do a "pre-prep" phase (which gets variables set up,
reading in advance from the regfile) and "post-cleanup" phase
(which writes out anything that was modified)

what we will need, however, is an indexable overloaded integer class.
(err, basically, the features of Signal).

in other words, due to the fact that you can do this:

RS[32:64] = product[0:32]

or

RS[0:32] = (RA)[0:32] + (RB)[0:32]

it means basically an integer class with operator overloads on
__add__ *and* it means adding a __getitem__ (in order to be able
to do the slice), and probably changing it to be this:

RS[0:32].eq(RA[0:32] + RB[0:32])

later, we will need a class for SimpleV anyway (so as to be able to change
bit-widths)

do you want to do that?  it's basically a class:

class Int:
   def __init__(self, value, width):
       self.value = value
       self.width = width
   def __getitem__(self, idx):
       if isinstance(idx, slice):
           # TODO, convert slice to an &able mask,
           # make sure that the length is that of the slice
       else:
           return Int((self.int & (1<<idx) >> idx, 1)

it will also need an "append" function - again, just like Signal can
use Cat().

it *might* - although performance will be absolutely terrible - be that
we are forced to individually slice bits into lists.

one other alternative, michael, is just... use Signal.  it's got everything
needed.

ideas?

-- 
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 272] functions needed in POWER simulator which match 3.0B spec

[bugzilla-daemon]

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

--- Comment #10 from Michael Nolan <mtnolan2640@gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #9)
> ... naah :)

> let's leave this one for now.  i'd like to focus on integer initially.

That's what I figured 


> later, we will need a class for SimpleV anyway (so as to be able to change
> bit-widths)
> 
> do you want to do that?  it's basically a class:

I can, sure.

> 
> one other alternative, michael, is just... use Signal.  it's got everything
> needed.

Doing it through signal would mean messing with yield and such wouldn't it?
Unless implementing the class turns out to be very difficult, I'd kinda like to
avoid that

-- 
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 272] functions needed in POWER simulator which match 3.0B spec

[bugzilla-daemon]

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

--- Comment #11 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Michael Nolan from comment #10)

> Doing it through signal would mean messing with yield and such wouldn't it?
> Unless implementing the class turns out to be very difficult, I'd kinda like
> to avoid that

sigh well as the PowerDecoder class is based around Signal we are kinda stuck
with yield and it is a pain.

i will attempt a pre and post process tomorrow which basically duplicates what
you did to get src1 2 etc out of the opcode.

once i have the regnums as integers i believe the class Int as defined, which
passes Int(value,len) around between ooerations rather than just value would do
the trick

-- 
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 272] functions needed in POWER simulator which match 3.0B spec

[bugzilla-daemon]

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

--- Comment #12 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Luke Kenneth Casson Leighton from comment #11)

> i will attempt a pre and post process tomorrow which basically duplicates
> what you did to get src1 2 etc out of the opcode.

done - it works (although the code's a dreadful mess)

if you'd like to do that Int class i can use it immediately.
or, if you want to give it a shot, knock yourself out.

        for i in range(32):
            self[i] = [0] * 64 # TODO: needs to be IntClass(value=0, len=64)

the class needs to be something like:

class IntClass
    def __init__(self, value, len):
        self.value = value
        self.len = len

then __add__ etc. all have to return an object which first asserts that
the len is the same for both operands.

the one thing, assign (now in soc/decoder/pseudo/parser.py) will, instead
of returning ast.Assign(name, expr) will have to return something like
this:

ast.Call(func=ast.Attribute(value=ast.Name(id='x'), attr='eq'),
                args=[Num(n=5)],
                keywords=[],
                starargs=None,
                kwargs=None))])

i got that from a little test program, parsing this:

x.eq(5)

so when we see "x <- 5"...

i'll add it to the parser, commented-out.

-- 
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 272] functions needed in POWER simulator which match 3.0B spec

[bugzilla-daemon]

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

--- Comment #13 from Michael Nolan <mtnolan2640@gmail.com> ---
I've got something in decoder/selectable_int.py. It uses Power's bit ordering
so it should be good for the compiler but something to be aware of if it's used
anywhere else.

I'm not sure what to do about left shift and right shift. Should SelectableInt
(0x10, bits=8) << 4 equal SelectableInt(0x100, bits=12) or SelectableInt(0x00,
bits=8)

It's also unsigned only, I'm not sure how much that matters right now

-- 
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 272] functions needed in POWER simulator which match 3.0B spec

[bugzilla-daemon]

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

Jacob Lifshay <programmerjake@gmail.com> changed:

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

--- Comment #14 from Jacob Lifshay <programmerjake@gmail.com> ---
(In reply to Michael Nolan from comment #13)
> I've got something in decoder/selectable_int.py. It uses Power's bit
> ordering so it should be good for the compiler but something to be aware of
> if it's used anywhere else.
> 
> I'm not sure what to do about left shift and right shift. Should
> SelectableInt (0x10, bits=8) << 4 equal SelectableInt(0x100, bits=12) or
> SelectableInt(0x00, bits=8)

I would assume shift left is still shift left. You can check which pseudo-code
gets run by the slw instruction since it's what gcc produces for the <<
operator.

-- 
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 272] functions needed in POWER simulator which match 3.0B spec

[bugzilla-daemon]

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

--- Comment #15 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Michael Nolan from comment #13)
> I've got something in decoder/selectable_int.py. It uses Power's bit
> ordering so it should be good for the compiler but something to be aware of
> if it's used anywhere else.

ahh superb.  ok.

> It's also unsigned only, I'm not sure how much that matters right now

as jacob pointed out, we can find out soon enough.

i do feel that we maay need to put carry-in and carry-out into the
Int class (somehow).  also, perhaps rewrite the pseudo-code fragments
to match those, then propose them back to the OpenPOWER Foundation.

just a thought.

-- 
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 272] functions needed in POWER simulator which match 3.0B spec

[bugzilla-daemon]

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

--- Comment #16 from Michael Nolan <mtnolan2640@gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #15)

> i do feel that we maay need to put carry-in and carry-out into the
> Int class (somehow).  also, perhaps rewrite the pseudo-code fragments
> to match those, then propose them back to the OpenPOWER Foundation.

Carry-in is addressed in the pseudocode, for instance:
adde:

RT <- (RA) + (RB) + CA

However, yes we'll probably need to add carry-out handling to the SelectableInt
class at some point

-- 
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 272] functions needed in POWER simulator which match 3.0B spec

[bugzilla-daemon]

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

--- Comment #17 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Michael Nolan from comment #16)

> Carry-in is addressed in the pseudocode, for instance:
> adde:
> 
> RT <- (RA) + (RB) + CA

oh duh :)

> However, yes we'll probably need to add carry-out handling to the
> SelectableInt class at some point

carry out, yes.

however think ahead to PartitionedSignal.  it becomes more like the unit tests
logic, with multiple incoming carry bits and multiple outgoing carry bits.

this is where it becomes both interesting and also hair-raising to implement
SV.

not least: the regfile gets typecast to a union of arrays of byte, hword, word
and dword.  the "register" RA etc then simply become a pointer to the 64 bit (8
byte) offset into the SRAM of the regfile memory.

but... let's leave that for later :)

-- 
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 272] functions needed in POWER simulator which match 3.0B spec

[bugzilla-daemon]

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

--- Comment #18 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
alriiight, i added it in: just... used it, and it worked!
i did however have to modify EXTZ64 and EXTS64 to get them
to recognise SelectableInt, and, interestingly, was able to
"drop in" the fact that the sign-zero-extended int now has
a bit-width of 64.

-- 
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 272] functions needed in POWER simulator which match 3.0B spec

[bugzilla-daemon]

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

--- Comment #19 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
hiya michael, saw the commit (reinstated addi) - couple of things:

* generally, a blank __init__.py is kiiinda the normal convention?
  (there's a few exceptions)

* i believe you may have created a circular import dependency loop

* multiple ISACaller base classes have been added.  this is a pain
  to workaround.

imports in python work hierarchically.  so, import x.y.z will
look for x, then x.y and finally x.y.z

because class ISA(fixedarith, fixedload) is in soc.decoder.isa
and because fixedarith is derived from ISACaller
and because ISACaller is in soc.decoder.isa.caller i think
that goes circular.

but the multiple ISACaller bases is slightly more problematic.

how about instead either:

* creating a class ISA which has fixedarith and fixedload (etc)
  as *member* variables, which, in the constructor, merge the
  instr dictionaries into one?

* removing ISACaller as a base then making it a base of ISA:
  class ISA(ISACaller, fixedarith, fixedload)

* changing pywriter.py to output dicts named fixedarith_instr (etc.)
  which can be merged / accessed separately

oh - i think you might have fixed it, just saw the latest push :)

-- 
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 272] functions needed in POWER simulator which match 3.0B spec

[bugzilla-daemon]

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

Luke Kenneth Casson Leighton <lkcl@lkcl.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
    NLnet milestone|---                         |NLNet.2019.10.Standards

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