1. Home
  2. Embedded Programming
  3. Question on ARM Instruction and an Armulator Bug?

Question on ARM Instruction and an Armulator Bug?

To all:

I am playing with Armulator to try to understand the ARM instruction as I do not yet have any ARM hardware to play with. However I run into a poss ible Armulator bug. This is surprising as Armulator should be sophisticated enough to have such trivial and obvious bug.

Here is the code that Armulator try to emulate:

00008104 : 8104: e3b00016 movs r0, #22 8108: e28f1f47 add r1, pc, #284 ; 0x11c

Question, after the second instruction, what value is stored into regis ter r1?

You would think that by the time the instruction is fetched from locati on 0x8108, the program counter PC would have been increased 4 to 0x810C. Th us the result would be 0x810C + 0x11C = 0x8228, which is stored into r1.

However Armulator gives a result 0x822C instead. It first increment PC right after the instruction is fetched, then, within function data_proc() i t increment the PC register once again:

void ARM::data_proc(A_INSTR instruction) { //bla bla bla... int Rn = (instruction>>16) & MASK_4BIT; //Bla bla bla...

if (Rn == 15) r[Rn] += 4;

Looks to me this is a bug, as R15 (PC) is un-necessarily incremented tw ice before used. Am I right in concluding that this is a bug in Armulator?

I obtained the source using GIT and I forgot where I got it, as I am no t familiar how to look up log in GIT. But the author seems to be Zi Yan

Any one has an answer to my question? Is this a bug in the Armulator?

Reply to
Jar Jar Code Binks
Loading thread data ...

Probably not. When you read the PC on an ARM, the value returned is instruction + 8. At least one of the ARM Architecture Reference Manuals is available on-line.

Stephen

--
Stephen Pelc, stephenXXX@mpeforth.com 
MicroProcessor Engineering Ltd - More Real, Less Time 
133 Hill Lane, Southampton SO15 5AF, England 
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 
web: http://www.mpeforth.com - free VFX Forth downloads
Reply to
Stephen Pelc

I can say you cannot possibly be right in reaching your conclusion the way you did, because you obviously failed to even look at the one document that gets to decide what the correct behaviour of that emulator would be: the architecture reference manual for your CPU's architecture, usually just referred to as the ARM ARM.

Reply to
Hans-Bernhard Bröker

This is essentially an implementation artifact of the 3-stage pipeline of ARM1 (and ARM2, ARM3) - when the current instruction is in execute, the instruction two later is in fetch so that's the value of PC you get. It's one of those things that's got frozen by the architecture specification, so every processor has to behave like ARM1 in this respect.

Theo

Reply to
Theo Markettos

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.