Hi,

This is a noob question I guess.

When I use the or32-decode program under sw/utils, what does it mean when it decodes the instruction as ".word"?

For example:
./or32-decode 14610000
.word 14610000

This was generated by or32-elf-gcc as part on an instruction flow for a very simple program I wrote.

Thanks a lot
-Diego

It means that it is data and not an instruction.

Hi diegovalverde.

Alternatively endianness has got confused. OpenRISC is big-endian, while if you are running on an Intel/AMD workstation, they are little-endian.

0x14610000 is not a valid OpenRISC opcode, although it looks a bit like an undocumented l.nop (which can take 0x14 in the top byte instead of 0x15), but in this case with some reserved bits swapped.

However if you have the endianness wrong, this is really 0x00006114. That is l.j to an offset 0x6114 words forward.

If you are compiling code, you can get an assembler listing by using -Wa,-alh on the gcc command line. This will show you the value that has been assembled for each address. For example.

or32-elf-gcc -Wa,-alh hello-world.c -o hello-world > hello-world.listing

HTH

Jeremy

Hi, I have a list file, this is what I see: ... 00002248 : 2248: d7 e1 17 fc l.sw 0xfffffffc(r1),r2 224c: 9c 41 00 00 l.addi r2,r1,0x0 2250: 9c 21 ff fc l.addi r1,r1,0xfffffffc 2254: a8 a0 00 01 l.ori r5,r0,0x1 2258: d4 05 00 00 l.sw 0x0(r5),r0 225c: 9c 60 00 00 l.addi r3,r0,0x0 2260: a9 63 00 00 l.ori r11,r3,0x0 2264: a8 22 00 00 l.ori r1,r2,0x0 2268: 84 41 ff fc l.lwz r2,0xfffffffc(r1) 226c: 44 00 48 00 l.jr r9 2270: 15 00 00 00 l.nop 0x0 ... This a very simple program to force a misalignment exception. At LIP 225c it is executing a addition as the list file shows. The strange behavior happens when I look for this LIP in gtkwave after running the RTL simulation. As you can see from the attached screen-shot, that the DU decodes correctly l.addi r3,r0,0x0 as it expected, but 1 clock cycle after that it just fills the du_insn with 0x14410000 (which I can't decode and doesn't appear as part of my instruction flow). I see the same behavior in IF and EXE. Is this some values that is used in the Stall logic? Thanks a lot for your help :) -Diego

Sorry Re-posting the previous text since my browser removed the "\n" charactes, so replacing by HTML
new-lines.
Please refer to attachement from previous reply
Hi, I have a list file, this is what I see:
00002248 :
2248: d7 e1 17 fc l.sw 0xfffffffc(r1),r2
224c: 9c 41 00 00 l.addi r2,r1,0x0
2250: 9c 21 ff fc l.addi r1,r1,0xfffffffc
2254: a8 a0 00 01 l.ori r5,r0,0x1
2258: d4 05 00 00 l.sw 0x0(r5),r0
225c: 9c 60 00 00 l.addi r3,r0,0x0
2260: a9 63 00 00 l.ori r11,r3,0x0
2264: a8 22 00 00 l.ori r1,r2,0x0
2268: 84 41 ff fc l.lwz r2,0xfffffffc(r1)
226c: 44 00 48 00 l.jr r9
2270: 15 00 00 00 l.nop 0x0
This a very simple program to force a misalignment exception.
At LIP 225c it is executing a addition as the list file shows.
The strange behavior happens when I look for this LIP in gtkwave after running the RTL
simulation. As you can see from the attached screen-shot, that the DU decodes correctly l.addi r3,r0,0x0 as it expected, but 1 clock cycle after that it just fills the du_insn with 0x14410000 (which I can't decode and doesn't appear as part of my instruction flow). I see the same behavior in IF and EXE.
Is this some values that is used in the Stall logic?
Thanks a lot for your help :)

You are correct, the opcode you are seeing is indeed stall logic. I tried to convince those with power to document this as a possible nop, but failed. The instruction following the stalls should be the add.