OpenCores
Issue List
Problem in Load Word with sign Extend insn. #159
Closed srig opened this issue over 13 years ago
srig commented over 13 years ago

When I tried to compile the insn. l.lws the result is not occuring. only l.lwz is working fine.

Please rply if I need any correction or this is a bug? If but I will try to fix it.

srig commented over 13 years ago

If this is a bug I will try to fix it.

jeremybennett commented over 13 years ago
<p> Hi sridharan, </p> <p> l.lws and l.lwz are equivalent on a 32-bit architecture. Can you explain your problem in more detail. </p> <p> Thanks, </p> <p> Jeremy </p> <p> -- <br /> Tel: +44 (1590) 610184<br /> Cell: +44 (7970) 676050<br /> SkypeID: jeremybennett<br /> Email: <a href="mailto:jeremy.bennett@embecosm.com">jeremy.bennett@embecosm.com</a><br /> Web: <a href="http://www.embecosm.com">www.embecosm.com</a> </p>
srig commented over 13 years ago

Hi Jeremy, Thanks for the rply. Actually while compiling the instruction l.lws the data is not loading into the respective register and stays unfinished while simulating. But while running the l.lwz insn. correct loading happening from the memory to respective register. Once if remove the l.lws insn everything is okay.

I am using modelsim. l.lbs and l.lhs works fine.

srig commented over 13 years ago

What we understand from the arch doc as the difference between them is in the generation of the memory address being: addr = sign_extended(I15:0) + (rA31:0) for l.lws addr = zero_extended(I15:0) + (rA31:0) for l.lwz

these will be different for offsets > 2^15 (ie, negative offsets).

Is this interpretation of the two instructions wrong?

srig commented over 13 years ago

Please help in this regard...

jeremybennett commented over 13 years ago
<p> Hi Sridharan </p> <p> You have misunderstood the documentation of the instruction. The immediate value is always sign extended to form a memory address. a 32-bit value is then loaded from that address and either sign extended (l.lws) or zero extended (l.lwz) before placing in the register. </p> <p> Since the current OR1200 implementation is a 32-bit implementation, it has 32-bit registers, so there is no sign-extension to be done. However the behaviour would be different on a 64-bit system, where the 32-bit value from memory had to sign extended to fill a 64-bit register. </p> <p> I hope this explains things. I'm marking this bug as closed. </p> <p> HTH </p> <p> Jeremy </p>
jeremybennett was assigned over 13 years ago
jeremybennett closed this over 13 years ago

Assignee
jeremybennett
Labels
Bug