I feel a little sheepish asking, but I had a little trouble getting
the IAR assembler to produce results I expected from:
add.w #(2-$), r15
The constant that follows appears after the first word of the
instruction doesn't appear to be calculated the way I'd expect. If
I
instead use:
dw 2-$
I get exactly what I'd expect to see. Similarly, if I write:
h EQU $
add.w #(2-h), r15
Then I also get what I expect.
Also,
add.w #($-2), r15
gives me what I expect, too.
I did do a short browse of the assembler manual from IAR and came up
short for an explanation. I suspect this is just me and something I'm
missing. Can anyone give me a kick in the head, here, and straighten
me out?
I'm using:
IAR Assembler for MSP430
V4.11B/W32 (4.11.2.9)
a430.exe
6/2/2008 11:41:20 AM, 2002944 bytes
Thanks,
Jon
IAR assembler -- use of a constant and $ in an expression
Started by ●September 20, 2009
Reply by ●September 20, 20092009-09-20
Hello Jon,
What do you see and what did you expect?
The erroneous result would be incremented by 2 or subtracted by 2 in
case you do 4-$?
2-$ would (almost) allways result in a negative number. Maybe
inspecting the value you got would give a hint. I assume you already
did that but without the values this audience can do very little.
-Augusto
On Dom 20/09/09 16:44 , Jon Kirwan j...@infinitefactors.org sent:
I feel a little sheepish asking, but I had a little trouble getting
the IAR assembler to produce results I expected from:
add.w #(2-$), r15
The constant that follows appears after the first word of the
instruction doesn't appear to be calculated the way I'd expect. If
I
instead use:
dw 2-$
I get exactly what I'd expect to see. Similarly, if I write:
h EQU $
add.w #(2-h), r15
Then I also get what I expect.
Also,
add.w #($-2), r15
gives me what I expect, too.
I did do a short browse of the assembler manual from IAR and came up
short for an explanation. I suspect this is just me and something
I'm
missing. Can anyone give me a kick in the head, here, and
straighten
me out?
I'm using:
IAR Assembler for MSP430
V4.11B/W32 (4.11.2.9)
a430.exe
6/2/2008 11:41:20 AM, 2002944 bytes
Thanks,
Jon
What do you see and what did you expect?
The erroneous result would be incremented by 2 or subtracted by 2 in
case you do 4-$?
2-$ would (almost) allways result in a negative number. Maybe
inspecting the value you got would give a hint. I assume you already
did that but without the values this audience can do very little.
-Augusto
On Dom 20/09/09 16:44 , Jon Kirwan j...@infinitefactors.org sent:
I feel a little sheepish asking, but I had a little trouble getting
the IAR assembler to produce results I expected from:
add.w #(2-$), r15
The constant that follows appears after the first word of the
instruction doesn't appear to be calculated the way I'd expect. If
I
instead use:
dw 2-$
I get exactly what I'd expect to see. Similarly, if I write:
h EQU $
add.w #(2-h), r15
Then I also get what I expect.
Also,
add.w #($-2), r15
gives me what I expect, too.
I did do a short browse of the assembler manual from IAR and came up
short for an explanation. I suspect this is just me and something
I'm
missing. Can anyone give me a kick in the head, here, and
straighten
me out?
I'm using:
IAR Assembler for MSP430
V4.11B/W32 (4.11.2.9)
a430.exe
6/2/2008 11:41:20 AM, 2002944 bytes
Thanks,
Jon
Reply by ●September 20, 20092009-09-20
Reviewing my own reply it makes not much difference if you supply
the values. It seems a parsing error and my reply is useless.
-Augusto
On Dom 20/09/09 16:44 , Jon Kirwan j...@infinitefactors.org sent:
I feel a little sheepish asking, but I had a little trouble getting
the IAR assembler to produce results I expected from:
add.w #(2-$), r15
The constant that follows appears after the first word of the
instruction doesn't appear to be calculated the way I'd expect. If
I
instead use:
dw 2-$
I get exactly what I'd expect to see. Similarly, if I write:
h EQU $
add.w #(2-h), r15
Then I also get what I expect.
Also,
add.w #($-2), r15
gives me what I expect, too.
I did do a short browse of the assembler manual from IAR and came up
short for an explanation. I suspect this is just me and something
I'm
missing. Can anyone give me a kick in the head, here, and
straighten
me out?
I'm using:
IAR Assembler for MSP430
V4.11B/W32 (4.11.2.9)
a430.exe
6/2/2008 11:41:20 AM, 2002944 bytes
Thanks,
Jon
the values. It seems a parsing error and my reply is useless.
-Augusto
On Dom 20/09/09 16:44 , Jon Kirwan j...@infinitefactors.org sent:
I feel a little sheepish asking, but I had a little trouble getting
the IAR assembler to produce results I expected from:
add.w #(2-$), r15
The constant that follows appears after the first word of the
instruction doesn't appear to be calculated the way I'd expect. If
I
instead use:
dw 2-$
I get exactly what I'd expect to see. Similarly, if I write:
h EQU $
add.w #(2-h), r15
Then I also get what I expect.
Also,
add.w #($-2), r15
gives me what I expect, too.
I did do a short browse of the assembler manual from IAR and came up
short for an explanation. I suspect this is just me and something
I'm
missing. Can anyone give me a kick in the head, here, and
straighten
me out?
I'm using:
IAR Assembler for MSP430
V4.11B/W32 (4.11.2.9)
a430.exe
6/2/2008 11:41:20 AM, 2002944 bytes
Thanks,
Jon
Reply by ●September 20, 20092009-09-20
On Sun, 20 Sep 2009 20:33:28 +0000, Augusto wrote:
> Hello Jon,
> What do you see and what did you expect?
> The erroneous result would be incremented by 2 or subtracted by 2 in
>case you do 4-$?
> 2-$ would (almost) allways result in a negative number. Maybe
>inspecting the value you got would give a hint. I assume you already
>did that but without the values this audience can do very little.
> -Augusto
Sorry, Augusto. I should have said what I observed.
I'll provide the program counter:
001126 503F 1126 add.w #$, r15 ; 1. expected
00112A 503F EED6 add.w #-$, r15 ; 2. expected
00112E 503F 10EA add.w #(0-$), r15 ; 3. not expected
001132 503F 10E8 add.w #(2-$), r15 ; 4. not expected
001136 503F 1136 add.w #($-0), r15 ; 5. expected
00113A 503F 1138 add.w #($-2), r15 ; 6. expected
00113E 503F EEC4 add.w #-($-2), r15 ; 7. expected
h equ $
001142 503F EECO add.w #(2-h), r15 ; 8. expected
Hope that helps. Note and compare (4) and (7), too.
Thanks in advance for your thoughts.
Jon
> Hello Jon,
> What do you see and what did you expect?
> The erroneous result would be incremented by 2 or subtracted by 2 in
>case you do 4-$?
> 2-$ would (almost) allways result in a negative number. Maybe
>inspecting the value you got would give a hint. I assume you already
>did that but without the values this audience can do very little.
> -Augusto
Sorry, Augusto. I should have said what I observed.
I'll provide the program counter:
001126 503F 1126 add.w #$, r15 ; 1. expected
00112A 503F EED6 add.w #-$, r15 ; 2. expected
00112E 503F 10EA add.w #(0-$), r15 ; 3. not expected
001132 503F 10E8 add.w #(2-$), r15 ; 4. not expected
001136 503F 1136 add.w #($-0), r15 ; 5. expected
00113A 503F 1138 add.w #($-2), r15 ; 6. expected
00113E 503F EEC4 add.w #-($-2), r15 ; 7. expected
h equ $
001142 503F EECO add.w #(2-h), r15 ; 8. expected
Hope that helps. Note and compare (4) and (7), too.
Thanks in advance for your thoughts.
Jon
Reply by ●September 20, 20092009-09-20
Hi JOn, when I quickly loaded up an existing program and just pasted
that into the front of my code this is what happened:_
00E126 503F E126 add.w #$, r15 ; 1. expected
Error[446]: Number out of range. Valid range is -32768 (-0x8000) to
65535 (0xFFFF).
So I looked a little longer and then shifted the test code down to info
memory at 1080 and here's the result:_
83 001080 3F508010 add.w #$, r15 ; 1. expected
84 001084 3F507CEF add.w #-$, r15 ; 2. expected
85 001088 3F5078EF add.w #(0-$), r15 ; 3. expected
86 00108C 3F5076EF add.w #(2-$), r15 ; 4. expected
87 001090 3F509010 add.w #($-0), r15 ; 5. expected
It seems that the result is being affected by the position in memory, OR
the size of memory/chip type, almost as if it wasn't treating $ as a
literal value but trying to rationalise it as an address
Al
Jon Kirwan wrote:
> On Sun, 20 Sep 2009 20:33:28 +0000, Augusto wrote:
>
>> Hello Jon,
>> What do you see and what did you expect?
>> The erroneous result would be incremented by 2 or subtracted by 2 in
>> case you do 4-$?
>> 2-$ would (almost) allways result in a negative number. Maybe
>> inspecting the value you got would give a hint. I assume you already
>> did that but without the values this audience can do very little.
>> -Augusto
>
> Sorry, Augusto. I should have said what I observed.
>
> I'll provide the program counter:
>
> 001126 503F 1126 add.w #$, r15 ; 1. expected
> 00112A 503F EED6 add.w #-$, r15 ; 2. expected
> 00112E 503F 10EA add.w #(0-$), r15 ; 3. not expected
> 001132 503F 10E8 add.w #(2-$), r15 ; 4. not expected
> 001136 503F 1136 add.w #($-0), r15 ; 5. expected
> 00113A 503F 1138 add.w #($-2), r15 ; 6. expected
> 00113E 503F EEC4 add.w #-($-2), r15 ; 7. expected
> h equ $
> 001142 503F EECO add.w #(2-h), r15 ; 8. expected
>
> Hope that helps. Note and compare (4) and (7), too.
>
> Thanks in advance for your thoughts.
>
> Jon
>
that into the front of my code this is what happened:_
00E126 503F E126 add.w #$, r15 ; 1. expected
Error[446]: Number out of range. Valid range is -32768 (-0x8000) to
65535 (0xFFFF).
So I looked a little longer and then shifted the test code down to info
memory at 1080 and here's the result:_
83 001080 3F508010 add.w #$, r15 ; 1. expected
84 001084 3F507CEF add.w #-$, r15 ; 2. expected
85 001088 3F5078EF add.w #(0-$), r15 ; 3. expected
86 00108C 3F5076EF add.w #(2-$), r15 ; 4. expected
87 001090 3F509010 add.w #($-0), r15 ; 5. expected
It seems that the result is being affected by the position in memory, OR
the size of memory/chip type, almost as if it wasn't treating $ as a
literal value but trying to rationalise it as an address
Al
Jon Kirwan wrote:
> On Sun, 20 Sep 2009 20:33:28 +0000, Augusto wrote:
>
>> Hello Jon,
>> What do you see and what did you expect?
>> The erroneous result would be incremented by 2 or subtracted by 2 in
>> case you do 4-$?
>> 2-$ would (almost) allways result in a negative number. Maybe
>> inspecting the value you got would give a hint. I assume you already
>> did that but without the values this audience can do very little.
>> -Augusto
>
> Sorry, Augusto. I should have said what I observed.
>
> I'll provide the program counter:
>
> 001126 503F 1126 add.w #$, r15 ; 1. expected
> 00112A 503F EED6 add.w #-$, r15 ; 2. expected
> 00112E 503F 10EA add.w #(0-$), r15 ; 3. not expected
> 001132 503F 10E8 add.w #(2-$), r15 ; 4. not expected
> 001136 503F 1136 add.w #($-0), r15 ; 5. expected
> 00113A 503F 1138 add.w #($-2), r15 ; 6. expected
> 00113E 503F EEC4 add.w #-($-2), r15 ; 7. expected
> h equ $
> 001142 503F EECO add.w #(2-h), r15 ; 8. expected
>
> Hope that helps. Note and compare (4) and (7), too.
>
> Thanks in advance for your thoughts.
>
> Jon
>
Reply by ●September 20, 20092009-09-20
Hi Jon,
It is at least an interesting topic to try an explanation.
The incorrect values are calculated accordingly, so the constants 0
and 2 are evaluated. As proven in the line 2 the calculation for -$
is also correctly evaluated.
Lines 5 to 8 proves the equation format is not the sole responsible.
So, in my humble opinion it is a very specific compiler flaw where it
gets a wrong value for $ only when it is the subtrahend inside
parenthesis.
I wonder if the statement add.w #2-$,r15 would work whitout the
parenthesis.
I did try to test it here in my IAR (IAR Assembler for MSP430
V4.10E/W32 (4.10.5.9)) but it is giving an error:
Error[446]: Number out of range. Valid range is -32768 (-0x8000) to
65535 (0xFFFF). test.asm 50
It seems that I have to get a newer version for IAR...
Best regards,
Augusto
On Dom 20/09/09 17:48 , Jon Kirwan j...@infinitefactors.org sent:
On Sun, 20 Sep 2009 20:33:28 +0000, Augusto wrote:
> Hello Jon,
> What do you see and what did you expect?
> The erroneous result would be incremented by 2 or subtracted by 2
in
>case you do 4-$?
> 2-$ would (almost) allways result in a negative number. Maybe
>inspecting the value you got would give a hint. I assume you
already
>did that but without the values this audience can do very little.
> -Augusto
Sorry, Augusto. I should have said what I observed.
I'll provide the program counter:
001126 503F 1126 add.w #$, r15 ; 1. expected
00112A 503F EED6 add.w #-$, r15 ; 2. expected
00112E 503F 10EA add.w #(0-$), r15 ; 3. not expected
001132 503F 10E8 add.w #(2-$), r15 ; 4. not expected
001136 503F 1136 add.w #($-0), r15 ; 5. expected
00113A 503F 1138 add.w #($-2), r15 ; 6. expected
00113E 503F EEC4 add.w #-($-2), r15 ; 7. expected
h equ $
001142 503F EECO add.w #(2-h), r15 ; 8. expected
Hope that helps. Note and compare (4) and (7), too.
Thanks in advance for your thoughts.
Jon
It is at least an interesting topic to try an explanation.
The incorrect values are calculated accordingly, so the constants 0
and 2 are evaluated. As proven in the line 2 the calculation for -$
is also correctly evaluated.
Lines 5 to 8 proves the equation format is not the sole responsible.
So, in my humble opinion it is a very specific compiler flaw where it
gets a wrong value for $ only when it is the subtrahend inside
parenthesis.
I wonder if the statement add.w #2-$,r15 would work whitout the
parenthesis.
I did try to test it here in my IAR (IAR Assembler for MSP430
V4.10E/W32 (4.10.5.9)) but it is giving an error:
Error[446]: Number out of range. Valid range is -32768 (-0x8000) to
65535 (0xFFFF). test.asm 50
It seems that I have to get a newer version for IAR...
Best regards,
Augusto
On Dom 20/09/09 17:48 , Jon Kirwan j...@infinitefactors.org sent:
On Sun, 20 Sep 2009 20:33:28 +0000, Augusto wrote:
> Hello Jon,
> What do you see and what did you expect?
> The erroneous result would be incremented by 2 or subtracted by 2
in
>case you do 4-$?
> 2-$ would (almost) allways result in a negative number. Maybe
>inspecting the value you got would give a hint. I assume you
already
>did that but without the values this audience can do very little.
> -Augusto
Sorry, Augusto. I should have said what I observed.
I'll provide the program counter:
001126 503F 1126 add.w #$, r15 ; 1. expected
00112A 503F EED6 add.w #-$, r15 ; 2. expected
00112E 503F 10EA add.w #(0-$), r15 ; 3. not expected
001132 503F 10E8 add.w #(2-$), r15 ; 4. not expected
001136 503F 1136 add.w #($-0), r15 ; 5. expected
00113A 503F 1138 add.w #($-2), r15 ; 6. expected
00113E 503F EEC4 add.w #-($-2), r15 ; 7. expected
h equ $
001142 503F EECO add.w #(2-h), r15 ; 8. expected
Hope that helps. Note and compare (4) and (7), too.
Thanks in advance for your thoughts.
Jon
Reply by ●September 20, 20092009-09-20
Sorry, to clarify this. The micro my code was written for is the
MSP430F2131, but my code starts at F800, so I plonked your test code at
E126. The firsy 6K or so of flash memory is reserved for data logging so
was clean. The error seemed strange so, i decided to move it downwards.
Since i don't have any flash at 1100H I went as close as possible, into
the first naked info memory segment, which was 1080, and lo and behold,
she compiles. sO i THEN WENT BACK AND DECIDED TO COMPILE THE CODE AT
IMAGINARY MEMORY ADDRESS 1126h, WHICH DOESN'T ACTUALLY EXIST ON THE
2131. THE RESULTS OF THIS ARE BELOW AS YOU CAN SEE, ALONG WITH THE
COMPILER VERSION i'M USING.:-
IAR Assembler V4.20.1.50017/W32 for MSP430 21/Sep/2009 07:02:18
#
83 001080 3F508010 add.w #$, r15 ; 1. expected
84 001084 3F507CEF add.w #-$, r15 ; 2. expected
85 001088 3F5078EF add.w #(0-$), r15 ; 3. not expected
86 00108C 3F5076EF add.w #(2-$), r15 ; 4. not expected
87 001090 3F509010 add.w #($-0), r15 ; 5. expected
88 001094
89 001094
90 0010C0 ORG INFOA
91 0010C0 CALDATA:
92 0010C0
93 001126 ORG 1126H
94 001126
95 001126 3F502611 add.w #$, r15 ; 1. expected
96 00112A 3F50D6EE add.w #-$, r15 ; 2. expected
97 00112E 3F50D2EE add.w #(0-$), r15 ; 3. not expected
98 001132 3F50D0EE add.w #(2-$), r15 ; 4. not expected
99 001136 3F503611 add.w #($-0), r15 ; 5. expected
100 00113A
Cheers
Al
OneStone wrote:
> Hi JOn, when I quickly loaded up an existing program and just pasted
> that into the front of my code this is what happened:_
>
> 00E126 503F E126 add.w #$, r15 ; 1. expected
> Error[446]: Number out of range. Valid range is -32768 (-0x8000) to
> 65535 (0xFFFF).
>
> So I looked a little longer and then shifted the test code down to info
> memory at 1080 and here's the result:_
>
> 83 001080 3F508010 add.w #$, r15 ; 1. expected
> 84 001084 3F507CEF add.w #-$, r15 ; 2. expected
> 85 001088 3F5078EF add.w #(0-$), r15 ; 3. expected
> 86 00108C 3F5076EF add.w #(2-$), r15 ; 4. expected
> 87 001090 3F509010 add.w #($-0), r15 ; 5. expected
>
> It seems that the result is being affected by the position in memory, OR
> the size of memory/chip type, almost as if it wasn't treating $ as a
> literal value but trying to rationalise it as an address
>
> Al
>
> Jon Kirwan wrote:
>> On Sun, 20 Sep 2009 20:33:28 +0000, Augusto wrote:
>>
>>> Hello Jon,
>>> What do you see and what did you expect?
>>> The erroneous result would be incremented by 2 or subtracted by 2 in
>>> case you do 4-$?
>>> 2-$ would (almost) allways result in a negative number. Maybe
>>> inspecting the value you got would give a hint. I assume you already
>>> did that but without the values this audience can do very little.
>>> -Augusto
>> Sorry, Augusto. I should have said what I observed.
>>
>> I'll provide the program counter:
>>
>> 001126 503F 1126 add.w #$, r15 ; 1. expected
>> 00112A 503F EED6 add.w #-$, r15 ; 2. expected
>> 00112E 503F 10EA add.w #(0-$), r15 ; 3. not expected
>> 001132 503F 10E8 add.w #(2-$), r15 ; 4. not expected
>> 001136 503F 1136 add.w #($-0), r15 ; 5. expected
>> 00113A 503F 1138 add.w #($-2), r15 ; 6. expected
>> 00113E 503F EEC4 add.w #-($-2), r15 ; 7. expected
>> h equ $
>> 001142 503F EECO add.w #(2-h), r15 ; 8. expected
>>
>> Hope that helps. Note and compare (4) and (7), too.
>>
>> Thanks in advance for your thoughts.
>>
>> Jon
>>
MSP430F2131, but my code starts at F800, so I plonked your test code at
E126. The firsy 6K or so of flash memory is reserved for data logging so
was clean. The error seemed strange so, i decided to move it downwards.
Since i don't have any flash at 1100H I went as close as possible, into
the first naked info memory segment, which was 1080, and lo and behold,
she compiles. sO i THEN WENT BACK AND DECIDED TO COMPILE THE CODE AT
IMAGINARY MEMORY ADDRESS 1126h, WHICH DOESN'T ACTUALLY EXIST ON THE
2131. THE RESULTS OF THIS ARE BELOW AS YOU CAN SEE, ALONG WITH THE
COMPILER VERSION i'M USING.:-
IAR Assembler V4.20.1.50017/W32 for MSP430 21/Sep/2009 07:02:18
#
83 001080 3F508010 add.w #$, r15 ; 1. expected
84 001084 3F507CEF add.w #-$, r15 ; 2. expected
85 001088 3F5078EF add.w #(0-$), r15 ; 3. not expected
86 00108C 3F5076EF add.w #(2-$), r15 ; 4. not expected
87 001090 3F509010 add.w #($-0), r15 ; 5. expected
88 001094
89 001094
90 0010C0 ORG INFOA
91 0010C0 CALDATA:
92 0010C0
93 001126 ORG 1126H
94 001126
95 001126 3F502611 add.w #$, r15 ; 1. expected
96 00112A 3F50D6EE add.w #-$, r15 ; 2. expected
97 00112E 3F50D2EE add.w #(0-$), r15 ; 3. not expected
98 001132 3F50D0EE add.w #(2-$), r15 ; 4. not expected
99 001136 3F503611 add.w #($-0), r15 ; 5. expected
100 00113A
Cheers
Al
OneStone wrote:
> Hi JOn, when I quickly loaded up an existing program and just pasted
> that into the front of my code this is what happened:_
>
> 00E126 503F E126 add.w #$, r15 ; 1. expected
> Error[446]: Number out of range. Valid range is -32768 (-0x8000) to
> 65535 (0xFFFF).
>
> So I looked a little longer and then shifted the test code down to info
> memory at 1080 and here's the result:_
>
> 83 001080 3F508010 add.w #$, r15 ; 1. expected
> 84 001084 3F507CEF add.w #-$, r15 ; 2. expected
> 85 001088 3F5078EF add.w #(0-$), r15 ; 3. expected
> 86 00108C 3F5076EF add.w #(2-$), r15 ; 4. expected
> 87 001090 3F509010 add.w #($-0), r15 ; 5. expected
>
> It seems that the result is being affected by the position in memory, OR
> the size of memory/chip type, almost as if it wasn't treating $ as a
> literal value but trying to rationalise it as an address
>
> Al
>
> Jon Kirwan wrote:
>> On Sun, 20 Sep 2009 20:33:28 +0000, Augusto wrote:
>>
>>> Hello Jon,
>>> What do you see and what did you expect?
>>> The erroneous result would be incremented by 2 or subtracted by 2 in
>>> case you do 4-$?
>>> 2-$ would (almost) allways result in a negative number. Maybe
>>> inspecting the value you got would give a hint. I assume you already
>>> did that but without the values this audience can do very little.
>>> -Augusto
>> Sorry, Augusto. I should have said what I observed.
>>
>> I'll provide the program counter:
>>
>> 001126 503F 1126 add.w #$, r15 ; 1. expected
>> 00112A 503F EED6 add.w #-$, r15 ; 2. expected
>> 00112E 503F 10EA add.w #(0-$), r15 ; 3. not expected
>> 001132 503F 10E8 add.w #(2-$), r15 ; 4. not expected
>> 001136 503F 1136 add.w #($-0), r15 ; 5. expected
>> 00113A 503F 1138 add.w #($-2), r15 ; 6. expected
>> 00113E 503F EEC4 add.w #-($-2), r15 ; 7. expected
>> h equ $
>> 001142 503F EECO add.w #(2-h), r15 ; 8. expected
>>
>> Hope that helps. Note and compare (4) and (7), too.
>>
>> Thanks in advance for your thoughts.
>>
>> Jon
>>
Reply by ●September 20, 20092009-09-20
Hi Al, you got it. I was testing using a program I made and it was
starting at 0x9000, that resulted in the Error 446. Moving the start
to 0x1100 did solve it.
Then I also did a try with:
add.w #2-$,r15
add.w#(2-$),r15
In both cases the assembler did calculate correctly.
As you pointed out device type seems to be the issue since Jon´s
experiments where also in lower memory.
My target device is '149.
-Augusto
On Dom 20/09/09 18:23 , OneStone o...@bigpond.net.au sent:
Hi JOn, when I quickly loaded up an existing program and just pasted
that into the front of my code this is what happened:_
00E126 503F E126 add.w #$, r15 ; 1. expected
Error[446]: Number out of range. Valid range is -32768 (-0x8000) to
65535 (0xFFFF).
So I looked a little longer and then shifted the test code down to
info
memory at 1080 and here's the result:_
83 001080 3F508010 add.w #$, r15 ; 1. expected
84 001084 3F507CEF add.w #-$, r15 ; 2.
expected
85 001088 3F5078EF add.w #(0-$), r15 ; 3.
expected
86 00108C 3F5076EF add.w #(2-$), r15 ; 4.
expected
87 001090 3F509010 add.w #($-0), r15 ; 5.
expected
It seems that the result is being affected by the position in
memory, OR
the size of memory/chip type, almost as if it wasn't treating $ as a
literal value but trying to rationalise it as an address
Al
Jon Kirwan wrote:
> On Sun, 20 Sep 2009 20:33:28 +0000, Augusto wrote:
>
>> Hello Jon,
>> What do you see and what did you expect?
>> The erroneous result would be incremented by 2 or subtracted by 2
in
>> case you do 4-$?
>> 2-$ would (almost) allways result in a negative number. Maybe
>> inspecting the value you got would give a hint. I assume you
already
>> did that but without the values this audience can do very little.
>> -Augusto
>
> Sorry, Augusto. I should have said what I observed.
>
> I'll provide the program counter:
>
> 001126 503F 1126 add.w #$, r15 ; 1. expected
> 00112A 503F EED6 add.w #-$, r15 ; 2. expected
> 00112E 503F 10EA add.w #(0-$), r15 ; 3. not expected
> 001132 503F 10E8 add.w #(2-$), r15 ; 4. not expected
> 001136 503F 1136 add.w #($-0), r15 ; 5. expected
> 00113A 503F 1138 add.w #($-2), r15 ; 6. expected
> 00113E 503F EEC4 add.w #-($-2), r15 ; 7. expected
> h equ $
> 001142 503F EECO add.w #(2-h), r15 ; 8. expected
>
> Hope that helps. Note and compare (4) and (7), too.
>
> Thanks in advance for your thoughts.
>
> Jon
>
>
>
>
>
>
>
Reply by ●September 20, 20092009-09-20
On Mon, 21 Sep 2009 07:04:46 +0930, you wrote:
>IAR Assembler V4.20.1.50017/W32
Your output is different from mine, obviously. I'm thinking now that
this was an issue with:
V4.11B/W32 (4.11.2.9)
I'll update to a newer version and re-check.
If this is a problem with 4.11 and not with 4.20, I guess it surprises
me to find that a version 4 assembler would have such problems. But
it remains for me to update first and verify. I have some other work
going on with the computer, right now, plus some visitors, so it will
be an hour or so more before I can check this.
Thanks very, very much, though. This helps bring my sanity back, I
think. (I'm just hoping I don't have to be shocked with IAR and it is
still something else.)
Jon
>IAR Assembler V4.20.1.50017/W32
Your output is different from mine, obviously. I'm thinking now that
this was an issue with:
V4.11B/W32 (4.11.2.9)
I'll update to a newer version and re-check.
If this is a problem with 4.11 and not with 4.20, I guess it surprises
me to find that a version 4 assembler would have such problems. But
it remains for me to update first and verify. I have some other work
going on with the computer, right now, plus some visitors, so it will
be an hour or so more before I can check this.
Thanks very, very much, though. This helps bring my sanity back, I
think. (I'm just hoping I don't have to be shocked with IAR and it is
still something else.)
Jon
Reply by ●September 20, 20092009-09-20
Hi Jon, sorry if I'm responsible for returning your sanity, I personally
feel much better off without mine! I'd lay odds it's a compiler issue,
but you're certainly more than welcome to the mild assist.
Al
Jon Kirwan wrote:
> On Mon, 21 Sep 2009 07:04:46 +0930, you wrote:
>
>> IAR Assembler V4.20.1.50017/W32
>
> Your output is different from mine, obviously. I'm thinking now that
> this was an issue with:
> V4.11B/W32 (4.11.2.9)
>
> I'll update to a newer version and re-check.
>
> If this is a problem with 4.11 and not with 4.20, I guess it surprises
> me to find that a version 4 assembler would have such problems. But
> it remains for me to update first and verify. I have some other work
> going on with the computer, right now, plus some visitors, so it will
> be an hour or so more before I can check this.
>
> Thanks very, very much, though. This helps bring my sanity back, I
> think. (I'm just hoping I don't have to be shocked with IAR and it is
> still something else.)
>
> Jon
>
feel much better off without mine! I'd lay odds it's a compiler issue,
but you're certainly more than welcome to the mild assist.
Al
Jon Kirwan wrote:
> On Mon, 21 Sep 2009 07:04:46 +0930, you wrote:
>
>> IAR Assembler V4.20.1.50017/W32
>
> Your output is different from mine, obviously. I'm thinking now that
> this was an issue with:
> V4.11B/W32 (4.11.2.9)
>
> I'll update to a newer version and re-check.
>
> If this is a problem with 4.11 and not with 4.20, I guess it surprises
> me to find that a version 4 assembler would have such problems. But
> it remains for me to update first and verify. I have some other work
> going on with the computer, right now, plus some visitors, so it will
> be an hour or so more before I can check this.
>
> Thanks very, very much, though. This helps bring my sanity back, I
> think. (I'm just hoping I don't have to be shocked with IAR and it is
> still something else.)
>
> Jon
>
