cornell-brg / pydgin

A (Py)thon (D)SL for (G)enerating (In)struction set simulators.
BSD 3-Clause "New" or "Revised" License
165 stars 29 forks source link

parc-sim.py fetched incorrect instruction #38

Closed kevinyuan closed 3 years ago

kevinyuan commented 3 years ago

Dear pydgin team,

I am trying to walk through the tcd tutorial, how every parc-sim.py fetched incorrect instruction (expect gcd, actual subu_xi)as following:

~/works/pymtl3/cornell-brg/pydgin/parc > python ./parc-sim.py --test -d insts,rf asm_tests/build/parcv1-gcd
NOTE: Using sparse storage
sparse memory size 400 addr mask 3ff block mask fffffc00
  808000 2402000f addiu        0        :: RD.RF[0 ] = 00000000 :: WR.RF[2 ] = 0000000f
  808004 2403000c addiu        1        :: RD.RF[0 ] = 00000000 :: WR.RF[3 ] = 0000000c
  808008 9c432011 subu_xi      2        :: RD.RF[2 ] = 0000000f :: RD.RF[3 ] = 0000000c :: WR.RF[4 ] = 00000003
  80800c 241d000b addiu        3        :: RD.RF[0 ] = 00000000 :: WR.RF[29] = 0000000b
  808010 24010003 addiu        4        :: RD.RF[0 ] = 00000000 :: WR.RF[1 ] = 00000003
  808014 1481002c bne          5        :: RD.RF[4 ] = 00000003 :: RD.RF[1 ] = 00000003
  808018 24020001 addiu        6        :: RD.RF[0 ] = 00000000 :: WR.RF[2 ] = 00000001
  80801c 241d0000 addiu        7        :: RD.RF[0 ] = 00000000 :: WR.RF[29] = 00000000
  808020 409d0800 mtc0         8        :: RD.RF[29] = 00000000   [ passed ] asm_tests/build/parcv1-gcd

parc-sim.py


 269   #---------------------------------------------------------------------
 270   ['gcd',      '101111_xxxxx_xxxxx_xxxxx_xxxxx_010011'],                                                                 
 271 ]

 932 
 933 #-----------------------------------------------------------------------
 934 # gcd                                                                                                                    
 935 #-----------------------------------------------------------------------
 936 def execute_gcd( s, inst ):
 937   # TODO: check for overflow
 938   a = s.rf[ inst.rs ]
 939   b = s.rf[ inst.rt ]
 940   while b:
 941       a, b = b, a%b
 942       s.gcd_ncycles +=1;
 943   s.rf[ inst.rd ] = a
 944   s.pc += 4

parc/asm_tests/parcv1/parcv1-gcd.S

1 //=========================================================================
  2 // parcv1-gcd.S
  3 // Author: Kevin Yuan
  4 // Data: 2020/12/21
  5 //=========================================================================
  6 
  7 #include "parc-macros.h"                                                                                                  
  8 
  9         TEST_PARC_BEGIN
 10 
 11         TEST_RR_OP( gcd, 15, 12, 3)
 12 
 13         TEST_PARC_END
 14 
~                                   

Dump the ASM test, which has the correct gcd instruction:


~/works/pymtl3/cornell-brg/pydgin/parc > maven-objdump -dC asm_tests/build/parcv1-gcd

asm_tests/build/parcv1-gcd:     file format elf32-littlemips

Disassembly of section .text:

00808000 <_test>:
  808000:       2402000f        li      v0,15
  808004:       2403000c        li      v1,12
  808008:       9c432011        gcd     a0,v0,v1
  80800c:       241d000b        li      sp,11
  808010:       24010003        li      at,3
  808014:       1481002c        bne     a0,at,8080c8 <_fail>

00808018 <_pass>:
  808018:       24020001        li      v0,1
  80801c:       241d0000        li      sp,0
  808020:       409d0800        mtc0    sp,c0_toserv
  808024:       1402ffff        bne     zero,v0,808024 <_pass+0xc>
        ...

008080c8 <_fail>:
  8080c8:       24020001        li      v0,1
  8080cc:       3c038000        lui     v1,0x8000
  8080d0:       03a3e825        or      sp,sp,v1
  8080d4:       409d0800        mtc0    sp,c0_toserv
  8080d8:       1402ffff        bne     zero,v0,8080d8 <_fail+0x10>
        ...
cbatten commented 3 years ago

Hi! I think this is just a disassembly issue. It looks like it is passing the test. If you look at the actual bits in the binary for the gcd instruction it says 9c432011 and then if you look in the line trace you see the same thing 9c432011 ... so it is indeed working correctly. The only issue is the disassembler. This is probably because the way it works is Pydgin takes the first encoding it finds. So if you look, the encoding for subu_xi is here:

If you remove the encoding for subu_xi and leave in the encoding for gcd I think the disassembler will show the correct instruction.