[libre-riscv-dev] [Bug 186] Create decoder for SOC: Power ISA and RISC-V

[libre-riscv-dev] [Bug 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

Tobias Platen <libre-soc@platen-software.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |libre-soc@platen-software.d
                   |                            |e

--- Comment #133 from Tobias Platen <libre-soc@platen-software.de> ---
I've tried to run the tests that use GDB, they still fail.

Traceback (most recent call last):
  File "test_sim.py", line 98, in test_sub
    self.run_tst_program(program, [1, 2, 3, 4, 5])
  File "test_sim.py", line 105, in run_tst_program
    qemu_register_compare(simulator, q, reglist)
  File "test_sim.py", line 110, in qemu_register_compare
    qemu_val = qemu.get_register(reg)
  File "/path/to/soc/src/soc/simulator/qemu.py", line 35, in get_register
    res = self.gdb.write('-data-list-register-values x {}'.format(num))
  File "/usr/local/lib/python3.7/dist-packages/pygdbmi/gdbcontroller.py", line
247, in write
    timeout_sec=timeout_sec, raise_error_on_timeout=raise_error_on_timeout
  File "/usr/local/lib/python3.7/dist-packages/pygdbmi/gdbcontroller.py", line
285, in get_gdb_response
    "Did not get response from gdb after %s seconds" % timeout_sec
pygdbmi.gdbcontroller.GdbTimeoutError: Did not get response from gdb after 1
seconds

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

--- Comment #134 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Tobias Platen from comment #133)
> I've tried to run the tests that use GDB, they still fail.

working fine here tobias - you'll need to work out what's missing,
what's going on, by using appropriate print / debug statements.
when you find out please do document it.

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

Yehowshua <yimmanuel3@gatech.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |yimmanuel3@gatech.edu

--- Comment #135 from Yehowshua <yimmanuel3@gatech.edu> ---
We shouldn't be pulling the the ISA from the wiki.
This is because I can edit the Wiki and break the codebase.

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

--- Comment #136 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
if someone starts doing that i will ban them, recover the wiki with a git
reversion, then add a password to the frontend to prevent it happening again.

ikiwiki was specifically chosen because of the use of git as a backend.

i prefer to trust people.

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

--- Comment #73 from Michael Nolan <mtnolan2640@gmail.com> ---
Huh, apparently the register numbers need to be bit reversed in our decoder.

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

--- Comment #74 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Michael Nolan from comment #73)
> Huh, apparently the register numbers need to be bit reversed in our decoder.

eeeverything needs to be bit-reversed. see 1.3.2 "notation"

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

*gibber*.

so i put the reversing into.. err... where was it...
SignalBitRange.__getitem__() - you can see (i just commented it)

if you can double-check that, it would be really good.  i tend
to get these things wrong.

ultimately, we'll find out pretty damn quick when it comes to
executing actual code.

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

--- Comment #75 from Michael Nolan <mtnolan2640@gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #74)
> (In reply to Michael Nolan from comment #73)
> > Huh, apparently the register numbers need to be bit reversed in our decoder.
> 
> eeeverything needs to be bit-reversed. see 1.3.2 "notation"

Well yes... But I thought we did that already, evidently not. 

> if you can double-check that, it would be really good.  i tend
> to get these things wrong.

Ok

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

--- Comment #76 from Jacob Lifshay <programmerjake@gmail.com> ---
From what I understand, it's just the way bits are numbered that's reversed,
the MSB is still the MSB. So, just the field order is reversed, individual
fields are not since they are treated as a multi-bit number and the MSB is
still the MSB (and other bits also keep their place in a number).

Example:
Power bit order:
bit # 0 1 2 3 4 5 6 7
      0 1 0 1 1 1 1 0

fields: A:0-3, B:4, C:5-7

field A 0-3: 0101 = 5
field B 4: 1 = 1
field C 5-7: 110 = 6

switched bit numbering order:

nmigen/RISC-V bit order:
bit # 7 6 5 4 3 2 1 0
      0 1 0 1 1 1 1 0

fields: C:0-2, B:3, A:4-7

fields have same value but different order:
field C 0-2: 110 = 6
field B 3: 1 = 1
field A 4-7: 0101 = 5

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

Re: [libre-riscv-dev] [Bug 186] Create decoder for SOC: Power ISA and RISC-V

[Luke Kenneth Casson Leighton]

look at decoder1.vhdl, entire 32 bit numbers definitely reversed compared
to numbering in PDF.

howevrr i dont know what "downto" means in vhdl.

On Wednesday, March 18, 2020, <bugzilla-daemon@libre-riscv.org> wrote:

> http://bugs.libre-riscv.org/show_bug.cgi?id=186
>
> --- Comment #76 from Jacob Lifshay <programmerjake@gmail.com> ---
> From what I understand, it's just the way bits are numbered that's
> reversed,
> the MSB is still the MSB. So, just the field order is reversed, individual
> fields are not since they are treated as a multi-bit number and the MSB is
> still the MSB (and other bits also keep their place in a number).
>
> Example:
> Power bit order:
> bit # 0 1 2 3 4 5 6 7
>       0 1 0 1 1 1 1 0
>
> fields: A:0-3, B:4, C:5-7
>
> field A 0-3: 0101 = 5
> field B 4: 1 = 1
> field C 5-7: 110 = 6
>
> switched bit numbering order:
>
> nmigen/RISC-V bit order:
> bit # 7 6 5 4 3 2 1 0
>       0 1 0 1 1 1 1 0
>
> fields: C:0-2, B:3, A:4-7
>
> fields have same value but different order:
> field C 0-2: 110 = 6
> field B 3: 1 = 1
> field A 4-7: 0101 = 5
>
> --
> 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
>


-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] [Bug 186] Create decoder for SOC: Power ISA and RISC-V

[Immanuel, Yehowshua U]

> howevrr i dont know what "downto" means in vhdl.

VHDL: 8 downto 0
Verilog: 8:0

VHDL is really weird...

_______________________________________________
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

--- Comment #77 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Jacob Lifshay from comment #76)
> From what I understand, it's just the way bits are numbered that's reversed,
> the MSB is still the MSB. So, just the field order is reversed, individual
> fields are not since they are treated as a multi-bit number and the MSB is
> still the MSB (and other bits also keep their place in a number).

ngggh mindbender.  so by doing width-idx-1 it has reversed the bitorder of each
bit in the field.

ye gods.

can you and michael take a look at this properly, suggest reviewing the pearpc
and gem5 source code, and chiselwatt.

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

--- Comment #78 from Jacob Lifshay <programmerjake@gmail.com> ---
In any case, what matters is that the instructions are decoded correctly.

Some example disassembly from objdump (edited to convert decimal to hex):

test.o:     file format elf64-powerpcle


Disassembly of section .text:

0000000000000000 <f>:
   0:   01 00 20 3d     addis   r9,0,1
   4:   45 23 29 61     ori     r9,r9,0x2345
   8:   d2 49 84 7c     mulld   r4,r4,r9
   c:   d2 19 64 7c     mulld   r3,r4,r3
  10:   20 00 80 4e     bclr    20,lt

Note how the immediate values for ori and addis are not bit-reversed (they are
in little-endian byte order, though). I haven't checked, but I'm quite sure the
register fields are also not bit-reversed.

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

--- Comment #79 from Michael Nolan <mtnolan2640@gmail.com> ---
Ok, so I've got an instruction, for example: 
add 4, 16, 7
which gets assembled to:
0x7c903a14
or:
value:   0111 1100 1001 0000 0011 1010 0001 0100
field:    oooo oott ttta aaaa       mmm mmmm mmm
number:  0123 4567 8901 2345 6789 0123 4567 8901

o: Opcode = 31
m: Opcode minor = 266/0b0100001010 - ADD - form XO
t: RT = 0b00100 = 4

This all looks right, right?

Somehow the decoder is getting write_reg=8 (write_reg should be RT) out of
this, and I'm not sure how. 0b00100 is 4 regardless of bit ordering...

I double checked, and pdecoder.dec.RT is 
SignalBitRange([(0, 6), (1, 7), (2, 8), (3, 9), (4, 10)])
which seems right. Any idea of where to 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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

--- Comment #80 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
rright.  ok.  so i think, to "fix" thus, in SignalBitRange, the slice indices -
start, end (and direction) all need to be reversed *as well*.

oink.

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

--- Comment #81 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
https://git.libre-riscv.org/?p=soc.git;a=blob;f=src/soc/decoder/power_fieldsn.py;h=a5e03a114ec54d915deb13f20c99e8ab59078dc5;hb=HEAD#l31

try subtracting start and end from from len-1, and sign inverting step, at line
31

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

--- Comment #82 from Michael Nolan <mtnolan2640@gmail.com> ---
(In reply to Michael Nolan from comment #79)
> Ok, so I've got an instruction, for example: 
> add 4, 16, 7
> which gets assembled to:
> 0x7c903a14
> or:
> value:   0111 1100 1001 0000 0011 1010 0001 0100
> field:    oooo oott ttta aaaa       mmm mmmm mmm
> number:  0123 4567 8901 2345 6789 0123 4567 8901
> 
> o: Opcode = 31
> m: Opcode minor = 266/0b0100001010 - ADD - form XO
> t: RT = 0b00100 = 4
> 
> This all looks right, right?
> 
> Somehow the decoder is getting write_reg=8 (write_reg should be RT) out of
> this, and I'm not sure how. 0b00100 is 4 regardless of bit ordering...
> 
> I double checked, and pdecoder.dec.RT is 
> SignalBitRange([(0, 6), (1, 7), (2, 8), (3, 9), (4, 10)])
> which seems right. Any idea of where to look?

Oh I see. It's bit reversing the whole word

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

--- Comment #83 from Michael Nolan <mtnolan2640@gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #81)
> https://git.libre-riscv.org/?p=soc.git;a=blob;f=src/soc/decoder/
> power_fieldsn.py;h=a5e03a114ec54d915deb13f20c99e8ab59078dc5;hb=HEAD#l31
> 
> try subtracting start and end from from len-1, and sign inverting step, at
> line 31

It's giving a key error because the index (31) isn't in the "dict" (I printed
out the object and it gave SignalBitRange([(0, 31)]), and I assume it treats
that as {0: 31}).

What's the purpose of line 1?
                k = OrderedDict.__getitem__(self, t)
                res.append(self.signal[k]) # reverse-order here
I think it'd work ok if I just grabbed the bit from the signal directly, like
so:
                res.append(self.signal[t])

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

--- Comment #84 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Michael Nolan from comment #83)
> (In reply to Luke Kenneth Casson Leighton from comment #81)
> > https://git.libre-riscv.org/?p=soc.git;a=blob;f=src/soc/decoder/
> > power_fieldsn.py;h=a5e03a114ec54d915deb13f20c99e8ab59078dc5;hb=HEAD#l31
> > 
> > try subtracting start and end from from len-1, and sign inverting step, at
> > line 31
> 
> It's giving a key error because the index (31) isn't in the "dict" (I
> printed out the object and it gave SignalBitRange([(0, 31)]), and I assume
> it treats that as {0: 31}).
> 
> What's the purpose of line 1?
>                 k = OrderedDict.__getitem__(self, t)
>   

gets the remapping of what bit you want in the field onto what ACTUAL bit you
want in the instruction.


              res.append(self.signal[k]) # reverse-order here
> I think it'd work ok if I just grabbed the bit from the signal directly,
> like so:
>                 res.append(self.signal[t])

nope.

that will get you bit 0 of the instruction when you request bit 0 ofa **FIELD**
in the instruction.

so, apologies it was reverse the order of t not k

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

--- Comment #85 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
line 32
for t in range(lenself - stop - 1, lenself - start - 1)

except this is wrong because bits are not stepped properly


so it is probably

l = list(range(start, stop, step)
l = l.reverse() # probably
for t in l:
   t = len(self) - t - 1
   carry on

for the else bit just do the t sub-from-self before lookup, too

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

--- Comment #86 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
really like the gnu gas test idea. could you also plan for covering BE as well
as LE?
but... later, we have enough brainmelting going on

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

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

> Oh I see. It's bit reversing the whole word

yes.  that is what width-k-1 is for.

 and then for the field which is local that needs to be reversed *back*.
this is what we are missing.

k is into the instruction (0..31)
t is into the FIELD and just to make life rreally interesting it can cover
MULTIPLE fields.

joy.

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

--- Comment #88 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
michael, fired up laptop brielfly when stopped git commited field-index reverse
please check it, should work.

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

--- Comment #89 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
ok i fixed some dumb off-by-one errors in decode_fieldsn.py and the gas example
works (yay!)  am tempted to suggest throwing a ton more random stuff at it.

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

--- Comment #90 from Michael Nolan <mtnolan2640@gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #89)
> ok i fixed some dumb off-by-one errors in decode_fieldsn.py and the gas
> example works (yay!)  am tempted to suggest throwing a ton more random stuff
> at it.

Yep, looks like you fixed the register thing. 
I'll get to adding more instructions later today

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

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

> Yep, looks like you fixed the register thing. 

dang that was a good guess

> I'll get to adding more instructions later today

i love this idea.  btw did we raise a specific bugreport for using gnu-as?

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

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

> 
> i love this idea.  btw did we raise a specific bugreport for using gnu-as?

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

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

--- Comment #93 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
y'know what, michael... you see in soc experiments comp6600 there is the
beginnings of a Simulator?

i have an idea, it might be worthwhile to run with that to its logical obvious
implication, namely to actually have a simulator, in soc, in python, which
interprets the InternalOps.

we then have a reference implementation which we can document properly etc.
with links to the PDF.

also it means we have to write the code and so understsnd it.

speed is not crucial as the nmigen simulator will be screamingly slow. we can
use cocotb later.

also at some point we can drop-in power-gem5.

what does everyone think?

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

--- Comment #94 from Michael Nolan <mtnolan2640@gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #93)
> y'know what, michael... you see in soc experiments comp6600 there is the
> beginnings of a Simulator?
> 
> i have an idea, it might be worthwhile to run with that to its logical
> obvious implication, namely to actually have a simulator, in soc, in python,
> which interprets the InternalOps.
> 
> we then have a reference implementation which we can document properly etc.
> with links to the PDF.
> 
> also it means we have to write the code and so understsnd it.
> 
> speed is not crucial as the nmigen simulator will be screamingly slow. we
> can use cocotb later.
> 
> also at some point we can drop-in power-gem5.
> 
> what does everyone think?

Yeah, seems reasonable. This wouldn't be cycle accurate or anything right, just
a simulator for our eventual backend?

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

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

> Yeah, seems reasonable. This wouldn't be cycle accurate or anything right,

well, cycle accurate just means that everything on each clock is exactly as it
would be after one clock

it's actually harder to do a nonaccurate simulator as it involves JIT
translation etc.

cycle accurate means doing TLBs in the simulator, too, and that means we have
something to test the hardware against, there, too.

> just a simulator for our eventual backend?

yes.  however adding a power frontend on it as we found ain't so bad.  can use
the same code.

if you look here you can see how basic the test simulator is
https://git.libre-riscv.org/?p=soc.git;a=blob;f=src/soc/experiment/score6600.py;h=babce2439233f84c262c08795b873a6167197ec9;hb=HEAD#l859

adjusting that so it uses InternalOp is... er... not hard? :)

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

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

> yes.  however adding a power frontend on it as we found ain't so bad.  can
> use the same code.
> 
> if you look here you can see how basic the test simulator is
> https://git.libre-riscv.org/?p=soc.git;a=blob;f=src/soc/experiment/score6600.
> py;h=babce2439233f84c262c08795b873a6167197ec9;hb=HEAD#l859
> 
> adjusting that so it uses InternalOp is... er... not hard? :)

Luke, looks like you and I are doing different things...? It looks to me like
score6600 is actual hardware, not a simulator. I have basic simulator I'm
working on here
https://git.libre-riscv.org/?p=soc.git;a=blob;f=src/soc/simulator/internalop_sim.py;h=813dd19c40e21283d000fd597074a2cb38595a8a;hb=e95b4372c5163bb6f753c92d8445d4af7f117457
- I took some of the elements from score6600 (like the register and memory
file) and modified them to get a basic simulator, which I'm testing along side
a real power machine. Were you going for something different...?

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

--- Comment #97 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Michael Nolan from comment #96)
> (In reply to Luke Kenneth Casson Leighton from comment #95)
> 
> > yes.  however adding a power frontend on it as we found ain't so bad.  can
> > use the same code.
> > 
> > if you look here you can see how basic the test simulator is
> > https://git.libre-riscv.org/?p=soc.git;a=blob;f=src/soc/experiment/score6600.
> > py;h=babce2439233f84c262c08795b873a6167197ec9;hb=HEAD#l859
> > 
> > adjusting that so it uses InternalOp is... er... not hard? :)
> 
> Luke, looks like you and I are doing different things...? It looks to me
> like score6600 is actual hardware, not a simulator.

i'd literally just moved RegSim and MemorySim into their own folder, you put
internalop_sim.py in the same location.

they should be pretty much identical in function.


> I have basic simulator
> I'm working on here
> https://git.libre-riscv.org/?p=soc.git;a=blob;f=src/soc/simulator/
> internalop_sim.py;h=813dd19c40e21283d000fd597074a2cb38595a8a;
> hb=e95b4372c5163bb6f753c92d8445d4af7f117457 - I took some of the elements
> from score6600 (like the register and memory file) and modified them to get
> a basic simulator, which I'm testing along side a real power machine. Were
> you going for something different...?

take a look at sim.py it is near identical to what you did :)

although you have, i think, also added a decoder on it?  so what you wrote can
take actual power instructions, is that right?

sim.py "tracks" what the real hardware does.  so the idea is that after running
the exact same instructions through each, and waiting for the instruction queue
to indicate "no longer busy processing", we can do a memory-memory compare and
a regfile-regfile compare and they should be *exactly* the same.

i wrote a function which does exactly that, one for mem and one for regfile.

unfortunately because this is a multiissue  OoO design we cannot take a
snapshot at a given time and say "yeah this will be exactly the same", you have
to pause, wait for outstanding ops, *then* snapshot.

that "pause" means unfortunately that it affects internal state, because FUs
are emptying rather than being filled with new operations.

but, it is the best we can do.

oh btw, one really important thing to remember: at sone point the sim will do
dynamic SIMD just like in the PartitionedSignal.  code to reuse in
InternalOpSim has already been written... in the PartitionedSignal unit tests!

and, actually, hm, we could probably just lift that code wholesale into a class
then rework the psig unit test to use it, *and* use that same code here.

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

--- Comment #98 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
https://git.libre-riscv.org/?p=soc.git;a=blob;f=src/soc/simulator/test_sim.py;hb=HEAD

y'know... the comment "checked this against qemu" got me thinking. this looks
like it could be used to actually run any of:

* qemu
* the simulator
* the score6600 engine
* pearpc
* gem5

i know qemu can be run in bare metal mode, console only, for example.  it would
not be cycle accurate however would give us a jumpstart on running really basic
programs.

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

--- Comment #99 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/virtualization_administration_guide/sect-vish-dump

crashdump --memory only would get a .elf file with memory and registers.

executing a bare metal .bin file under qemu with a small memory would give
something not too massive to parse

https://github.com/eliben/pyelftools/blob/master/examples/dwarf_decode_address.py

hmm it seems there are at least 2 different python elf parsers.

the only thing we have to watch, these are big dependencies we're pulling in
(i'm on a mobile 4G connection). luckily i have qemu already installed

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

--- Comment #100 from Jacob Lifshay <programmerjake@gmail.com> ---
one issue with qemu is that it doesn't properly implement everything -- for
example, it doesn't appear to implement the FPSCR.FR bit (I've been reading its
source as an additional reference for simple-soft-float).

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

--- Comment #101 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Jacob Lifshay from comment #100)
> one issue with qemu is that it doesn't properly implement everything -- for
> example, it doesn't appear to implement the FPSCR.FR bit

yuck

> (I've been reading
> its source as an additional reference for simple-soft-float).

ok so when it comes to FP we can't expect that to work.  by then we should be a
long way forward at least with running something.

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

--- Comment #102 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Luke Kenneth Casson Leighton from comment #98)
> https://git.libre-riscv.org/?p=soc.git;a=blob;f=src/soc/simulator/test_sim.
> py;hb=HEAD
> 
> y'know... the comment "checked this against qemu" got me thinking. this
> looks like it could be used to actually run any of:
> 
> * qemu

what do you think, michael: does firing off qemu to run those same
(tiny) binaries sound practical?

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

--- Comment #103 from Michael Nolan <mtnolan2640@gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #102)
> (In reply to Luke Kenneth Casson Leighton from comment #98)
> > https://git.libre-riscv.org/?p=soc.git;a=blob;f=src/soc/simulator/test_sim.
> > py;hb=HEAD
> > 
> > y'know... the comment "checked this against qemu" got me thinking. this
> > looks like it could be used to actually run any of:
> > 
> > * qemu
> 
> what do you think, michael: does firing off qemu to run those same
> (tiny) binaries sound practical?

It doesn't seem like a bad idea, especially since we don't have another power
simulator to compare to yet. Getting the instructions/data into qemu is pretty
easy, just compile and link a bare metal kernel. I've got a folder with my
manual method for this already, and I can add it to the git repo. 
However, getting the data (registers/memory) out of qemu might be a bit harder.
Probably the best way would be to use the gdb socket that qemu makes available
for reading registers and memory. I know GDB is written with python in mind, so
it *should* be doable to control it from python, but I haven't investigated
that yet.

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

--- Comment #104 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
just taking a closer look at python-libvirt, and trying to find the examples i
saw which turn qemu params into xml files

also this:

https://www.programcreek.com/python/example/28110/libvirt.open
canCreateVM - is able to run virsh, which will get a coredump
(including regfile as well as memory).

see earlier comments, yes do drop the qemu example into a subfolder.

be with you in a sec, just investigating.

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

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

> see earlier comments, yes do drop the qemu example into a subfolder.

It's now uploaded here:
https://git.libre-riscv.org/?p=soc.git;a=tree;f=src/soc/simulator/qemu_test;h=50cde50b45e9af13b3c070c8b9618a956f63d3b5;hb=40c5ec1f0df4bed1d78b1d0d019b399450d87ced

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

--- Comment #106 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
https://libvirt.org/drvqemu.html

shows how to convert qemu to xml if you have some args already ("virsh
domxml-from-native")

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

--- Comment #107 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
currently attempting to get python-libvirt to "start" launch.sh.
wooow is this painful.  obtuseness beyond obtuseness.

/usr/bin/qemu-system-ppc64 \
-name guest=Linux-0.2,debug-threads=on \
-S \
-object
secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-6-Linux-0.2/master-key.aes
\
-machine powernv9,accel=tcg,usb=off,dump-guest-core=off \
-m 1024 \
-overcommit mem-lock=off \
-smp 1,sockets=1,cores=1,threads=1 \
-uuid ce1326f0-a9a0-11e3-a5e2-0800200c9a66 \
-display none \
-no-user-config \
-nodefaults \
-chardev socket,id=charmonitor,fd=33,server,nowait \
-mon chardev=charmonitor,id=monitor,mode=control \
-rtc base=utc \
-no-shutdown \
-boot strict=on \
-kernel /home/lkcl/testdisk.raw \
-sandbox
on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \
-msg timestamp=on
2020-03-25T19:38:07.721499Z qemu-system-ppc64: error creating device tree:
(fdt_property_string(fdt, "system-id", buf)): FDT_ERR_BADSTATE
2020-03-25 19:38:07.758+0000: shutting down, reason=failed


https://bugzilla.redhat.com/show_bug.cgi?id=1624539

nggggggh.

attempting to downgrade qemu-system-ppc so that the older version of libfdt can
be used

apt-get install libfdt1=1.4.2-1 qemu-system-ppc=1:3.1+dfsg-8+deb10u3
qemu-system=1:3.1+dfsg-8+deb10u3 qemu-system-misc=1:3.1+dfsg-8+deb10u3

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

--- Comment #108 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
https://bugzilla.redhat.com/show_bug.cgi?id=1585991

woooow....

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

--- Comment #109 from Michael Nolan <mtnolan2640@gmail.com> ---
I'm going to try using https://sourceware.org/gdb/wiki/PythonGdb to see if I
can't get something working that way.

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

--- Comment #110 from Michael Nolan <mtnolan2640@gmail.com> ---
I've got a rudimentary qemu-gdb interface working in qemu.py:
https://git.libre-riscv.org/?p=soc.git;a=blob;f=src/soc/simulator/qemu.py;h=70e29b0d76b65227a06d3ba3bd95315cf5af37e8;hb=3f7e6c771c7f8df65e67e6dc350964a54aee8066

It's able to load a kernel into qemu, set up a breakpoint at the start of it,
single step it, and dump the register contents.

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

Re: [libre-riscv-dev] [Bug 186] Create decoder for SOC: Power ISA and RISC-V

[Luke Kenneth Casson Leighton]

On Wednesday, March 25, 2020, <bugzilla-daemon@libre-riscv.org> wrote:

> http://bugs.libre-riscv.org/show_bug.cgi?id=186
>
> --- Comment #110 from Michael Nolan <mtnolan2640@gmail.com> ---
> I've got a rudimentary qemu-gdb interface working in qemu.py:
> https://git.libre-riscv.org/?p=soc.git;a=blob;f=src/soc/
> simulator/qemu.py;h=70e29b0d76b65227a06d3ba3bd95315cf5af37e8;hb=
> 3f7e6c771c7f8df65e67e6dc350964a54aee8066
>
> It's able to load a kernel into qemu, set up a breakpoint at the start of
> it,
> single step it, and dump the register contents.


coooool.

confirmed able to duplicate that, here.

i did encounter KeyError, register-values not present but it is spurious
and unreliably occurring.

i added an assert to investigate and, sigh, was no longer seeing failures
even after running 20 times.

the other really useful addition would be memory-dump / memory location
reading.

btw change of topic, i noticed, just like in the original RegSim, OP_ADD is
not joined by OP_SUB because Anton chose to do "add1 to op1" as well as
"invert op1" in the InternalOp csv.

therefore we need to pass the whole of the decode row to the
execute_alu_sim function, rather than just the enum InternalOp value.




-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
_______________________________________________
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

--- Comment #111 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
deep breath....

install dependencies (saves messing about) with
apt-get build-dep qemu

git clone from here:

[remote "origin"]
    url = https://github.com/legoater/qemu.git
    fetch = +refs/heads/*:refs/remotes/origin/*

git checkout this branch:
* origin/powernv-next

configure/build with this:
./configure --enable-system
--target-list=ppc64-softmmu,ppc64-linux-user,ppc64le-linux-user

edit hw/ppc/pnv.c and comment out these lines:

        /*
    if (qemu_uuid_set) {
        _FDT((fdt_property_string(fdt, "system-id", buf)));
    }
    */

run python3 domstart.py (files to be attached shortly)

dump the state to a file:

virsh # dump Linux-0.2 mem.hex --memory-only --crash


objdump the results with this:

objdump -x mem.hex

which gives the following (including regfile and memory):

architecture: powerpc:common64, flags 0x00000000:

start address 0x0000000000000000

Program Header:
    NOTE off    0x00000000000000b0 vaddr 0x0000000000000000 paddr
0x0000000000000000 align 2**0
         filesz 0x0000000000000710 memsz 0x0000000000000710 flags ---
    LOAD off    0x00000000000007c0 vaddr 0x0000000000000000 paddr
0x0000000000000000 align 2**0
         filesz 0x0000000040000000 memsz 0x0000000040000000 flags ---

Sections:
Idx Name          Size      VMA               LMA               File off  Algn
  0 note0         00000710  0000000000000000  0000000000000000  000000b0  2**0
                  CONTENTS, READONLY
  1 .reg/0        00000180  0000000000000000  0000000000000000  00000134  2**2
                  CONTENTS
  2 .reg          00000180  0000000000000000  0000000000000000  00000134  2**2
                  CONTENTS
  3 .reg2/0       00000108  0000000000000000  0000000000000000  000002d0  2**2
                  CONTENTS
  4 .reg2         00000108  0000000000000000  0000000000000000  000002d0  2**2
                  CONTENTS
  5 load1         40000000  0000000000000000  0000000000000000  000007c0  2**0
                  CONTENTS, ALLOC, LOAD, READONLY

and thus can be parsed with python elf libraries mentioned in previous
comments.

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

--- Comment #114 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
actually, i like what you wrote a whooole lot better, michael:
https://git.libre-riscv.org/?p=soc.git;a=blob;f=src/soc/simulator/qemu.py;h=c9b1b573dd22d3da0adb0415a0a6b8bb005c99c6;hb=4b50a170c413f47e0527c843be49babc493c684b

the only modification i needed:

set architecture powerpc:common64
target remote localhost:1234
layout asm
b *0x20000000
c

and to use debian package "gdb-multilib" which *sigh* had to come from
debian/unstable.

building cross-compilers etc. from source has always stressed me out :)

if we do that, we need a proper documented reproducible process.

how did you get powerpc64-linux-gnu-gdb?

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

--- Comment #115 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
i enabled export PYTHONTRACEMALLOC=25
https://docs.python.org/3/using/cmdline.html#envvar-PYTHONTRACEMALLOC

/usr/lib/python3.7/subprocess.py:858: ResourceWarning: subprocess 1551551 is
still running
  ResourceWarning, source=self)
Object allocated at (most recent call last):
  File "simulator/test_sim.py", lineno 106
    unittest.main()
  File "/usr/lib/python3.7/unittest/main.py", lineno 101
    self.runTests()
  File "/usr/lib/python3.7/unittest/main.py", lineno 271
    self.result = testRunner.run(self.test)
  File "/usr/lib/python3.7/unittest/runner.py", lineno 176
    test(result)
  File "/usr/lib/python3.7/unittest/suite.py", lineno 84
    return self.run(*args, **kwds)
  File "/usr/lib/python3.7/unittest/suite.py", lineno 122
    test(result)
  File "/usr/lib/python3.7/unittest/suite.py", lineno 84
    return self.run(*args, **kwds)
  File "/usr/lib/python3.7/unittest/suite.py", lineno 122
    test(result)
  File "/usr/lib/python3.7/unittest/case.py", lineno 663
    return self.run(*args, **kwds)
  File "/usr/lib/python3.7/unittest/case.py", lineno 615
    testMethod()
  File "simulator/test_sim.py", lineno 58
    self.run_test_program(program, [1, 2, 3, 4])
  File "simulator/test_sim.py", lineno 95
    with run_program(prog) as q:
  File "/home/lkcl/src/libreriscv/soc/src/soc/simulator/qemu.py", lineno 54
    q = QemuController(program.binfile.name)
  File "/home/lkcl/src/libreriscv/soc/src/soc/simulator/qemu.py", lineno 16
    stdin=subprocess.PIPE)
simulator/test_sim.py:58: ResourceWarning: unclosed file <_io.BufferedWriter
name=4>
  self.run_test_program(program, [1, 2, 3, 4])


this gets rid of it:

        self.qemu_popen.stdout.close()
        self.qemu_popen.stdin.close()

except one of the qemus is still running, thissays you have
to call qemu_popen.communicate():
https://docs.python.org/3/library/subprocess.html

fixed with a quick commit.

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

--- Comment #116 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
i've also added pygdbmi to the dependencies in setup.py and added a way
to get hold of and compile up powerpc64 gdb.  michael (and anyone else)
could you take a look?
https://git.libre-riscv.org/?p=soc.git;a=blob;f=README.md;hb=HEAD

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

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

> 
> except one of the qemus is still running, thissays you have
> to call qemu_popen.communicate():
> https://docs.python.org/3/library/subprocess.html
> 
> fixed with a quick commit.

Oh, thank you! I was struggling to figure out where this was coming from.

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

--- Comment #118 from Michael Nolan <mtnolan2640@gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #116)
> i've also added pygdbmi to the dependencies in setup.py and added a way
> to get hold of and compile up powerpc64 gdb.  michael (and anyone else)
> could you take a look?
> https://git.libre-riscv.org/?p=soc.git;a=blob;f=README.md;hb=HEAD

Yep, that looks right

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

--- Comment #119 from Michael Nolan <mtnolan2640@gmail.com> ---
>coooool.
>
>confirmed able to duplicate that, here.
>
>i did encounter KeyError, register-values not present but it is spurious
>and unreliably occurring.

Huh. It sounds like that's from the register read code, where it reaches in to
a largeish dict to grab the register values. I'll have to see if I can
replicate it on my end.

>
>i added an assert to investigate and, sigh, was no longer seeing failures
>even after running 20 times.
>
>the other really useful addition would be memory-dump / memory location
>reading.

That shouldn't be too hard to add. Similar to the register comparison code,
it'll need to only do it to specific locations as comparing all of memory would
not only take too long, but disagree because qemu loads the kernel and some
other stuff into memory and the simulator does not. 

>btw change of topic, i noticed, just like in the original RegSim, OP_ADD is
>not joined by OP_SUB because Anton chose to do "add1 to op1" as well as
>"invert op1" in the InternalOp csv.
>
>therefore we need to pass the whole of the decode row to the
>execute_alu_sim function, rather than just the enum InternalOp value.

Ah ok.

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

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

> >the other really useful addition would be memory-dump / memory location
> >reading.
> 
> That shouldn't be too hard to add. Similar to the register comparison code,

yes just the right voodoo gdb incantation.  i think it allows byte word dword
selection.

> it'll need to only do it to specific locations as comparing all of memory
> would not only take too long, but disagree because qemu loads the kernel and
> some other stuff into memory and the simulator does not. 

urk :)

> 
> >btw change of topic, i noticed, just like in the original RegSim, OP_ADD is
> >not joined by OP_SUB because Anton chose to do "add1 to op1" as well as
> >"invert op1" in the InternalOp csv.
> >
> >therefore we need to pass the whole of the decode row to the
> >execute_alu_sim function, rather than just the enum InternalOp value.
> 
> Ah ok.

yeh :)

should be very straightforward (you want to do it?) a separate if elif elif,
"if op1.value == Op1.ONE op1 += 1"

can skip carry for now, add as TODO.

then also if row['op1neg'] op1 ^= 0xffffffffffffffff

something like that.

or op1 = (~op1) & 0xffffffffffffffff

that _should_ be sufficient to get sub, subi and neg all working, with not a
lot of effort.

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

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

> 
> should be very straightforward (you want to do it?) a separate if elif elif,
> "if op1.value == Op1.ONE op1 += 1"
> 
> can skip carry for now, add as TODO.
> 
> then also if row['op1neg'] op1 ^= 0xffffffffffffffff
> 
> something like that.
> 
> or op1 = (~op1) & 0xffffffffffffffff
> 
> that _should_ be sufficient to get sub, subi and neg all working, with not a
> lot of effort.

Working now. Need to sort out setting the carry and overflow flags at some
point though, that'll be more fun...

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

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

> > that _should_ be sufficient to get sub, subi and neg all working, with not a
> > lot of effort.
> 
> Working now.

yay!  oh wait...

F
======================================================================
FAIL: test_sub (__main__.DecoderTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "simulator/test_sim.py", line 98, in test_sub
    self.run_test_program(program, [1, 2, 3, 4, 5])
  File "simulator/test_sim.py", line 105, in run_test_program
    qemu_register_compare(simulator, q, reglist)
  File "simulator/test_sim.py", line 111, in qemu_register_compare
    simulator.regfile.assert_gpr(reg, qemu_val)
  File "/home/lkcl/src/libreriscv/soc/src/soc/simulator/internalop_sim.py",
line 74, in assert_gpr
    assert reg_val == val, msg
AssertionError: reg r3 got 10000000000004444, expecting 4444

----------------------------------------------------------------------
Ran 5 tests in 15.696s

FAILED (failures=1)

how many bits is that
0x 1 0000 0000 0000 4444

ha, that's amusing.  the result is a roll-over from 64-bit arithmetic

> Need to sort out setting the carry and overflow flags at some
> point though, that'll be more fun...

yehyeh.  a SPR storing the carry, first.  take a look at pearpc,
it should show a way to do it (that's easy to interpret)
https://github.com/sebastianbiallas/pearpc

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

--- Comment #123 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
i hacked masking the write to take out the upper 1 in write_reg.

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

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

> how many bits is that
> 0x 1 0000 0000 0000 4444
> 
> ha, that's amusing.  the result is a roll-over from 64-bit arithmetic
> 
> > Need to sort out setting the carry and overflow flags at some
> > point though, that'll be more fun...
> 
> yehyeh.  a SPR storing the carry, first.  take a look at pearpc,
> it should show a way to do it (that's easy to interpret)
> https://github.com/sebastianbiallas/pearpc

Ooops, some of my experiments with carry must have snuck in, sorry. Speaking
of, I'm getting some weird behavior with carry on qemu. If I run some
instructions that generate a carry or overflow, then have gdb read the xer
register, it returns 0. But if I execute a `mfxer r5` or the like and print out
that register, it gives me the correct value for xer. I'm trying to confirm
whether this is a bug with qemu or not.

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

--- Comment #125 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Michael Nolan from comment #124)
> (In reply to Luke Kenneth Casson Leighton from comment #122)
> 
> > how many bits is that
> > 0x 1 0000 0000 0000 4444
> > 
> > ha, that's amusing.  the result is a roll-over from 64-bit arithmetic
> > 
> > > Need to sort out setting the carry and overflow flags at some
> > > point though, that'll be more fun...
> > 
> > yehyeh.  a SPR storing the carry, first.  take a look at pearpc,
> > it should show a way to do it (that's easy to interpret)
> > https://github.com/sebastianbiallas/pearpc
> 
> Ooops, some of my experiments with carry must have snuck in, sorry. 

no worries

> Speaking
> of, I'm getting some weird behavior with carry on qemu. If I run some
> instructions that generate a carry or overflow, then have gdb read the xer
> register, it returns 0. But if I execute a `mfxer r5` or the like and print
> out that register, it gives me the correct value for xer. I'm trying to
> confirm whether this is a bug with qemu or not.

hmmm.  if it's a bug in qemu it's one that, i suspect, would have been detected
a loooong time ago.  but... you never know...

let's look at the spec:

p70 3.0B "addc":

RT <= (RA) + (RB)

The sum (RA) + (RB) is placed into register RT.
Special Registers Altered:
    CA CA32
    CR0                                       (if Rc=1)
    SO OV OV32                               (if OE=1)

ok so SO (summary overflow), OV (overflow) and OV32 (overflow 32-bit)
all get set, in XER.  these are listed on p45 3.2.2

however that's not the "carry" flag: that's *CR0*.  which is in... errr...
the Condition Register p45 2.3.1

let's check the pearpc source (yes it's only 32-bit).  ppc_alu.c
whereisitwhereisit...  ok!

https://github.com/sebastianbiallas/pearpc/blob/master/src/cpu/cpu_generic/ppc_alu.cc#L56

ahh, then as a *separate* concern, if you see the implementation of addcx,
that updatex XER_CA *and* updates CR0:
https://github.com/sebastianbiallas/pearpc/blob/master/src/cpu/cpu_generic/ppc_alu.cc#L86

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

--- Comment #126 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
here's ppc_update_cr0:

https://github.com/sebastianbiallas/pearpc/blob/master/src/cpu/cpu_generic/ppc_opc.h#L26

#define CR_CR0_LT (1<<31)
#define CR_CR0_GT (1<<30)
#define CR_CR0_EQ (1<<29)
#define CR_CR0_SO (1<<28)

* clears the CR-CR0 bits
* result is zero: sets bit 29
* result top bit is set (indicating -ve as signed): sets bit 31
* otherwise (+ve signed): sets bit 30
* after that (in *addition*): if the XER SO bit was set, set bit 28 of CR0

interestingly, then, it looks like you have to check the XER flag *before*
checking the carry.  and XER is set based on... err... comparing operand A
with the result.  how odd.
https://github.com/sebastianbiallas/pearpc/blob/master/src/cpu/cpu_generic/ppc_alu.cc#L86

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

--- Comment #127 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
oh - i just spotted this in p30, section 2.3.1.  it seems to concur with
ppc_update_cr0 *except* of course, it's been adapted for 32/64-bit modes.

if (64-bit mode)
   then M <= 0
   else M <= 32
if       (target_register)[M:63] < 0 then c <= 0b100  # bit 31
else if (target_register)[M:63] > 0 then c <= 0b010   # bit 30
else                                      c <= 0b001  # bit 29
CR0 <= c || XERSO                                     # bit 28

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

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

> hmmm.  if it's a bug in qemu it's one that, i suspect, would have been
> detected
> a loooong time ago.  but... you never know...
> 

> ok so SO (summary overflow), OV (overflow) and OV32 (overflow 32-bit)
> all get set, in XER.  these are listed on p45 3.2.2
> 

Sorry, was actually overflow that I was checking: 
        li 1, 1
        sldi 1, 1, 63
        or 2, 1, 1
        addco. 3, 2, 1
        mfxer 5

That should add -0x80000000000000000 to itself and overflow, and the "o" means
that OV and SO should actually be set. Like I said before, running it in qemu
and reading the xer register gives a result of 0, and reading r5 gives a result
of 0xe0000000.

> however that's not the "carry" flag: that's *CR0*.  which is in... errr...
> the Condition Register p45 2.3.1

It does also list CA and CA32, which should correspond to the flags in xer as
well.

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

--- Comment #129 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
https://github.com/qemu/qemu/blob/master/target/ppc/translate.c#L950

eurrrgh... macros-on-macros-on-macros... *sigh*.

ok so we're looking at a trail that goes through GEN_HANDLER, GEN_OPCODE,
GEN_INT_ARITH_ADD but ultimately lands at geo_op_addic which in turn
lands in gen_op_arith_add.

here's where addco sets the flags compute_ca=1, compute_ov=1 *but* sets
add_ca=0 whereas addeo *does* set all three (line #926)

https://github.com/qemu/qemu/blob/master/target/ppc/translate.c#L924

the flag "cpu_ca" comes in globally (initialised at line 132).

looking at the spec, the difference between addco and addeo is supposed to
be:

addco

RT <= (RA) + (RB)
The sum (RA) + (RB) is placed into register RT.

addeo

RT <= (RA) + (RB) + CA
The sum (RA) + (RB) + CA is placed into register RT.

hmmm need to look at microwatt, will do that in a minute.

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

--- Comment #130 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
https://github.com/antonblanchard/microwatt/blob/master/ppc_fx_insns.vhdl#L110
ppc_adde():
return 65-bit RA + 65-bit RB + carry

https://github.com/antonblanchard/microwatt/blob/master/ppc_fx_insns.vhdl#L140
ppc_add():
return 64-bit RA + 64-bit RB

hmm ppc_add() doesn't appear to be used (at all) in execute1.vhdl

decode_input_carry(ic, XERC) is:
if ic=ZERO return 0
if ic=ONE return 1
if ic=CA return XERC.ca

returning XERC.ca might be a significant difference, there... ah!  yes,
if you look in the "cry_in" column, adde and addeo are supposed to take
cry_in=CA *not* cry_in=ZERO.

that's likely to be it.

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

--- Comment #131 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
btw don't be afraid to commit unit tests that don't "quotes work quotes".

when it comes to unit tests, the whole idea is to have
"things-that-demonstrate-a-need-to-fix-code" rather than "have everything
absolutely perfect".

so do go ahead and commit some unit tests that actually break, but you
expect them to pass at some point in the future.

i say that because in the past i noticed that you commented out some unit
tests which "failed".  just leave them to fail, as a reminder.  also
there's a way to tag them with bugreports (with decorators).

i'll document this in HDL_workflow.

-- 
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 186] Create decoder for SOC: Power ISA and RISC-V

[bugzilla-daemon]

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

--- Comment #132 from Jacob Lifshay <programmerjake@gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #131)
> btw don't be afraid to commit unit tests that don't "quotes work quotes".
> 
> when it comes to unit tests, the whole idea is to have
> "things-that-demonstrate-a-need-to-fix-code" rather than "have everything
> absolutely perfect".
> 
> so do go ahead and commit some unit tests that actually break, but you
> expect them to pass at some point in the future.
> 
> i say that because in the past i noticed that you commented out some unit
> tests which "failed".  just leave them to fail, as a reminder.  also
> there's a way to tag them with bugreports (with decorators).
> 
> i'll document this in HDL_workflow.

Actually, I'd decorate them with something like:
import unittest

@unittest.skip("not working yet")
def test_fn():
    body-here

or

@unittest.expectedFailure # FIXME: not working yet
def test_fn():
    body-here


That way, once I add support for GitLab CI we will get a message when one of
the commits fails any of the tests, allowing us to more quickly detect that
something unexpectedly broke. If it's filled with a whole bunch of tests that
we know will fail, then that makes the CI nearly worthless because it will
always be filled with a bunch of failures obscuring the ones we care about.

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