Compiler give error message for following codes. A1174E: "Data transfer offset 0x00000102 out of range. Permitted values are 0x00..0x1F"
LDR R1,=USB_BASE LDRB R0,[R1,#USB0_CSRL0] ; Error code is A1174E !!!! USB_BASE EQU 0x40050000 USB0_CSRL0 EQU 0x102
But compiler dont give any error if i write this program thats way
USB_BASE EQU 0x40050000 USB0_CSRL0 EQU 0x102 LDR R1,=USB_BASE LDRB R0,[R1,#USB0_CSRL0] ; Error code is A1174E !!!!
What is wrong?
> This is an assembler's problem and i think at the next versions Keil repairs.
I can see that the observed behavior might appear to be a bug, especially after spending ours getting down to the root cause of this. However, this is arguably not a bug since the behavior is documented. See here: infocenter.arm.com/.../armasm_cihdgigd.htm
An action item for ARM could be to improve the error message so that it at least mention the possibility of a "wrong" instruction size.
Regards Marcus http://www.doulos.com/arm/
Thank you for providing focused answer to my question. Other friends tried with me not to question.
I want to explain why i think assembler has a bug.
Please carefully follow the next lines.
USB_BASE EQU 0x40050000 USB0_CSRL0 EQU 0x102 LDR R1,=USB_BASE LDRB R0,[R1,#USB0_CSRL0] ; No error !!!!
LDRB R0,[R1,#USB0_CSRL0] means R0 = [R1 + 0x102] (Assmebler compile without error.)
Can I ask, is 0x102 offset value bigger than 0x1F ? Answer is yes.
Why does not give assembler the error messages. (A1174E: "Data transfer offset 0x00000102 out of range. Permitted values are 0x00..0x1F")
Answer: Because 0x102 legal value. Because offset value range of LDR command of Arm Cortex m3 processor is larger than 0x1F. (You may look to any CM3 book).But assembler claims to the contrary.
Let forget this.
Now;
Remove the first two-line and move to the end of the program.(as follows)
Let recompile.
Now assembler will give error messges.(A1174E: "Data transfer offset 0x00000102 out of range. Permitted values are 0x00..0x1F")
What happen and why assembler give this error? Did i changed the offset value? No, this value is not changed and it is 0x102.
Therefore assembler has a bug.
Answer: Because 0x102 legal value. Because offset value range of LDR command of Arm Cortex m3 processor is larger than 0x1F. (You may look to any CM3 book).But assembler claims to the contrary. Let forget this.
Let’s not forget it.
The LDR and LDRB are different instructions. From the Cortex-M3 Technical Reference Manual, there are two forms of this particular instruction with immediate offset.
Load memory byte [7:0] from register address + 5-bit immediate offset LDRB <Rd>, [<Rn>, #<immed_5>] Memory byte [7:0] from base register address + immediate 12-bit offset LDRB.W <Rxf>, [<Rn>, #<offset_12>]
Marcus has provided the link which describes which one is chosen when the assembler does not know the offset in advance or the .N or .W suffix is specified.
infocenter.arm.com/.../armasm_cihdgigd.htm
For forward references, LDR, ADR, and B without .W always generate a 16-bit instruction, even if that results in failure for a target that could be reached using a 32-bit instruction.
This implies the 5-bit immediate offset LDRB variant => 0x1F is the maximum offset.
Why is this difficult to understand?
It would appear that the OP does not understand what a forward reference is.
Or the implications of an assembler that always selects the biggest instruction "just in case".
An interesting thing here - why would an assembler even have the option to specify if narrow or wide instructions should be used if the assembler always iterated through the complete set of instructions until it found the "optimum" instruction sizes? And how would that affect a developer who expects to be able to count bytes in relation to cache lines or machine cycles when trying to write the optimal loop?
The OP tries, yet again, to explain the problem, so he is still convinced that he is the only one who sees a problem while everyone else haven't even noticed what the debate is about.
It's this view (that he is the only one with "the view") that keeps the OP in a constant output-only mode - always trying to argue his case without spending any time looking at other peoples posts. When the world and his view differs, the error is with the world since he sees the ladder of knowledge as finite, and him already on the top rung.
I use Luminaris Cortex M3 processor family and I read its documents.
focus.ti.com/.../spmu159.pdf
Please look to end of page 27.
In the end of page 27 (the N and W suffix) will see the range of the offset of LDR and other LDRx commands.
I trusted this document and the *** psycho example, the assembler of the problem that I thought made a mistake when assembler.
(equ directives have given example, the head or the end result being an error in one of the error remained same and the other being strengthened in my thesis)
Therefore, the need to ask this question I've heard in this forum. At this point, I understand that I used false documents.
I'm sorry friends of seriously discussing it away.
Note that the absolute source for information about ARM instructions is the ARM web site.
And problems can often be seen from multiple angles - and it is often required to see them from more than one angle.
That is a reason why this forum has lots of discussions in the threads. People posts hints and clues to problems to move the debate forward.
If someone do post a link where they have seen a specific quote (such as the limitation for the immediate value), then people may respond back with alternative links showing additional information. In this thread, people did post hints about narrow and wide instructions - the TI document doesn't mention anything about them. The thread also mentioned a couple of terms and references that could have been picked up by Google to fetch more information about the issue.
Chip manufacturers (who buys the core design from ARM) wants to present "for dummies" documents to make it easy for people to get going. Alas, the shoft-form documentation do get people going but doesn't help them when they get stuck. Having a simplified map works well if you drive by GPS, or takes the highway (or program in C). But if you want to take the shortest route (possibly even accepting dirt tracks) then you do need the full information.
A traditional way to handle problems is to make assumptions, and then see if they can be proved or disproved. And if stuck, to post on a forum telling what assumption based on what premisses and then see if people can point at errors in the logic or missing data.
We often can. But we often do dish out details one-by-one instead of going directly to posting complete text sections from different documents. The reason is that a text document may tell "what happens". It seldom discuss "why". And a developer is very much helped by considering the "why".
In this case, people who selects assembler does it because they want control. And having an assembler that is too clever will in some situations get in the way. So while it is very nice with assemblers with good macro functionality, almost all developers wants to keep the right to decide exactly what instructions that gets used. The logical alternative is of course to instead focusing on what problem to solve, and switch to a problem-solving language like C where the task of the compiler is to figure out a reasonably efficient mapping from the C code into processor instructions.
Another reason why people like to debate things on web forums is that we don't know everything. But if we debate things, we will be able to share some of the things we know, while at the same time having the chance of picking up some new knowledge in return. If just posting final solutions we wouldn't evolve ourselves - and since we do post help for free, we somehow needs some potential value in return.
When we do debate, the thread can progress quickly or slowly. When someone always returns to the original post, then the thread will progress very slowly. When the debate can manage to solve small sub-steps of a problem then the discussion can directly progress to looking at new, potential sub-problems or steps needed to reach a good conclusion to the debate.
Please look to page 3.20 of following document.
infocenter.arm.com/.../DUI0552A_cortex_m3_dgug.pdf
This document wrong same as luminary. Isnt it?
I can not see the 0x00 ... 0x1f offset range for the LDRB command.
I am looking reliable document.
But that doesn't help if you're so intent on proving your point that you only read those parts of a single document that appear to support it, without looking left and right.
In the case at hand, for starters you're overlooking section 3.3.8 of same document.
I am looking but i dont see.
.N and .W suffix ok but where is writing offset range for the 0x00 ... 0x1f.
infocenter.arm.com/.../QRC0006_UAL16.pdf