|
Message
From: rachel_cy at hotmail.com<rachel_cy@h...>
Date: Wed Mar 26 21:44:26 CET 2008
Subject: [openrisc] Dead Loop in Generated Image of OR1200
Yes, you are right. Thank you and the other guys very much. I checked my Verilog simulation results again and the instruction in the
delay slot did get executed. I was careless and impatient. Sorry.
It seems Ok now.
Again, thank you guys very much.
Regards,
Mark
----- Original Message -----
From: Richard Deglin<richard.deglin@g...>
To:
Date: Fri Mar 21 21:09:20 CET 2008
Subject: [openrisc] Dead Loop in Generated Image of OR1200
> You missed the instruction in the delay slot (8000002c) which
> eventually increments r28 until it is equal to r30.
> -----Original Message-----
> From: openrisc-bounces at opencores.org
> [mailto:openrisc-bounces at opencores.org] On Behalf Of
> rachel_cy at hotmail.com
> Sent: Thursday, March 20, 2008 12:07 PM
> To: openrisc at opencores.org
> Subject: [openrisc] Dead Loop in Generated Image of OR1200
> I came across a problem of the generated image with the toolchain
> built
> by the package
> of drp-0.6.
> Version information of the tools is
> gcc 4.2.1
> binutils: 2.17-1
> uClibc 0.9.28.3
> The small C program is attached at the bottom of this message.
> I used the compiler of or32-elf-gcc and the command I used to
> generated the image is
> % or32-elf-gcc -s x.c -o x1
> Here are the first few lines of the assembly code:
> 1 80000000: 18 20 03 00 l.movhi r1,0x300
> 2 80000004: a8 21 00 00 l.ori r1,r1,0x0
> 3 80000008: 9c 40 ff f9 l.addi r2,r0,0xfffffff9
> 4 8000000c: e0 21 10 03 l.and r1,r1,r2
> 5 80000010: 1b 80 00 01 l.movhi r28,0x1
> 6 80000014: ab 9c 2f 94 l.ori r28,r28,0x2f94
> 7 80000018: 1b c0 00 01 l.movhi r30,0x1
> 8 8000001c: ab de 2f e0 l.ori r30,r30,0x2fe0
> 9 80000020: d4 1c 00 00 l.sw 0x0(r28),r0
> 10 80000024: e4 9c f0 00 l.sfltu r28,r30
> 11 80000028: 13 ff ff fe l.bf 0x80000020
> 12 8000002c: 9f 9c 00 04 l.addi r28,r28,0x4
> 13 80000030: 18 60 90 00 l.movhi r3,0x9000
> ...
> ... The remaining lines of the assembly code are omitted.
> ...
> The problem of the generated image is
> At steps 5 and 6, register r28 is assigned a value of 0x12f94 and
> at steps 7 and 8, register r30 is assigned a value of 0x12fe0. And
> up to step 11, these values in register r28 and r30 do not change.
> Step 10, the instruction l.sfltu compares [r28] to [r30], which
> should set the flag bit, since 0x12f94(r28) is less than
> 0x12fe0(r30). So the immedately following instruction l.bf directs
> the CPU to PC address 0x80000020, which is step 9. The instruction
> at 0x80000020 is l.sw, which just stores the data addressed by r28
> with 0. When step 10 compares [r28] to [r30] again, and step 11
> turns to CPU to step 9 again. Thus, steps 9, 10 and 11 effectively
> form a dead loop. I am looking into the code of insn-output.c,
> insn-emit.c, emit-rtl.c, optab.s, etc. But if someone who is
> familiar with OR1200 port of GCC would help or point me to which
> code I should look, that will be great. Thank you. Mark
> ==================== Attachment: //------------- x.c
> ------------------------ 1 int main() 2 { 3 int a, b, c, *p = (int
> *)(0x3fff0); 4 5 a = 0x55; 6 b = 0x88; 7 8 c = a + b; 9 10 *p = c;
> 11 12 return 0; 13 }
> _______________________________________________
> http://www.opencores.org/mailman/listinfo/openrisc
>
|
 |
Browse
