<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://community.arm.com/utility/feedstylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>LPC2104</title><link>https://community.arm.com/developer/tools-software/tools/f/keil-forum/30137/lpc2104</link><description> 
I am a newbie to ARM and KEIL, I wrote a samll program in assembly
and try to simulate it using debuger, I noticed that the PC value is
same as the line which is just executed (i.e. marked with green
rectangle) but because the arm uses 3 stage pipe</description><dc:language>en-US</dc:language><generator>Telligent Community 10</generator><item><title>RE: LPC2104</title><link>https://community.arm.com/thread/127384?ContentTypeID=1</link><pubDate>Tue, 21 Feb 2012 19:30:48 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:9ee8861e-2621-42a5-bb5c-7e37bc87c7a6</guid><dc:creator>Nima Moaddeli</dc:creator><description>&lt;p&gt;&lt;p&gt;
Thanks for all your post on my question,&lt;/p&gt;

&lt;p&gt;
I tested debugger by LDR PC,[PC,#4] as you can see in following
code and it worked they way that if it was in thumb state (but T in
CPSR was 0).&lt;/p&gt;

&lt;pre&gt;
     5:                 MOV R0,#0x11
0x00000000  E3A00011  MOV       R0,#0x00000011
     6:                 LDR PC,[PC,#4]
0x00000004  E59FF004  LDR       PC,[PC,#0x0004]
     7:                 MOV R1,R0,LSL#1
0x00000008  E1A01080  MOV       R1,R0,LSL #1
     8:                 MOV R2,R1,LSL#1
0x0000000C  E1A02081  MOV       R2,R1,LSL #1
     9: STOP    B STOP
0x00000010  EAFFFFFE  B         0x00000010
&lt;/pre&gt;

&lt;p&gt;
After executing line 6 it jumped to line 8, which means the PC was
0x00000008 rather than being 0x0000000C.&lt;/p&gt;

&lt;p&gt;
This could be the case if ARM is in THUMB state, but not in ARM
state.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: LPC2104</title><link>https://community.arm.com/thread/119627?ContentTypeID=1</link><pubDate>Tue, 21 Feb 2012 04:36:56 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:a5b84ece-fce6-4de0-bec0-5f56413847c0</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
Do you believe that, or can you produce any actual documentation
for that claim?&lt;/p&gt;

&lt;p&gt;
I have seen a number of references that clearly says that PC
points at the fetched instruction - not the executed instruction.&lt;/p&gt;

&lt;p&gt;
And looking at the output from the assembler, a jump of PC+0 is a
jump two steps forward, while it takes pc - 2 (i.e. PC - 8 bytes) to
get an empty, infinite loop.&lt;/p&gt;

&lt;p&gt;
So when the debugger is about to execute an instruction that makes
a jump to PC-2, it would be reasonable that the debugger then
actually show a contents of PC that is the fetched instruction two
steps forward. Or else that -2 will nto make sense.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: LPC2104</title><link>https://community.arm.com/thread/105755?ContentTypeID=1</link><pubDate>Mon, 20 Feb 2012 16:04:19 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:86206d36-cf09-4ef9-82d9-fe21ed3e4bf2</guid><dc:creator>HansBernhard Broeker</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;why Program Counter (PC) in debugger shows 0x00000004 instead
of 0x0000000C&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Becaust that &lt;b&gt;is&lt;/b&gt; the value of the PC at that point. Whether
or not there&amp;#39;s a pipeline containing other instructions currently
being prepared for later execution is irrelevant as far as simulating
the code&amp;#39;s actual behaviour is concerned.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: LPC2104</title><link>https://community.arm.com/thread/105756?ContentTypeID=1</link><pubDate>Mon, 20 Feb 2012 10:14:38 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:160ac7bb-f81c-4f09-aa74-7d8e0ea7a4e1</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
I&amp;#39;m sorry if I gave you a bad answer.&lt;/p&gt;

&lt;p&gt;
I did look a bit further and ARM do say that the PC should point
to the fetched instruction and not the current instruction. When
single-stepping in assembler, I normally don&amp;#39;t look at the PC - it&amp;#39;s
only when I have written trap handlers that I have had to bother with
stack frames and PC behaviour to figure out what instruction that
caused the exception.&lt;/p&gt;

&lt;p&gt;
You might have to talk with Keil about this. If they have made a
presentation decision because they got too many complaints when the
editor showed one instruction as active and the PC indicate another
instruction. Or if it is something related to Keils addition of thumb
and tumb2 modes.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: LPC2104</title><link>https://community.arm.com/thread/80004?ContentTypeID=1</link><pubDate>Sun, 19 Feb 2012 23:55:17 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:6ff9c30d-39c6-41eb-9cfe-dc9cec32cc5f</guid><dc:creator>Nima Moaddeli</dc:creator><description>&lt;p&gt;&lt;p&gt;
Thanks for your reply,&lt;br /&gt;
what I meant to say is , suppose the instruction MOV r0,r1 is located
at the address 0x00000004 and just executed, why Program Counter (PC)
in debugger shows 0x00000004 instead of 0x0000000C. Because when
processor executing an instruction it is decoding the other one and
fetching the one after that. but I cannot observe it in debugger.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: LPC2104</title><link>https://community.arm.com/thread/67263?ContentTypeID=1</link><pubDate>Sun, 19 Feb 2012 22:21:13 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:7129d48a-3255-44a0-a2d6-6943987215af</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
The program is related to the current instruction - not
instructions that may be several steps away in the pipeline. After
all - the current instruction could represent a jump, in which case
the pipeline would be invalidated.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>