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?
Assembler and/or compiler not importand details for my main question.
You don't know that. You have no idea what's important for your main question and what isn't.
Else you cant see and you cant understand the niceties in my questions.
There are no "niceties" to be found in any of the pointless repetitions of your question. Just the obnoxiousness of a person who asks a question, then is so sure he knows the answer better than the people he asked, that he considers himself qualified to dismiss answers as unhelpful without so much as pretending to consider them first.
You don't want any help, fine --- so stop wasting everybody's time by pretending to ask for it.
I found the answer for my first question and i wrote it. This is an assembler's problem and i think at the next versions Keil repairs.
If you look at the answers to my question unrelated ordinary conceivable that you will see the answers.
I'm not coming here to chat or controversy. I'm coming to find a single reply of my question I was just right.
At the same time the problem is only missing my Ingilizce Caused by.
I found the answer for my first question and i wrote it.
So you believe. Just about everybody, up to and including the company that designed both the CPU and the assembler you're using, disagrees with you on that count.
I'm coming to find a single reply of my question I was just right.
Well, this is a discussion forum, not a "I believe you" automaton. We're people, not Electric Monks (courtesy Douglas Adams).
In other words: if you can't stand the heat, stay out of the kitchen.
This place is technical forum. You're not going to social sciences forums, why?
(Let wait the new version of assembler compilers)
Go away, please. Enough is enough!
Did you see anything about "Some or all forms of this instruction are 16-bit (narrow) instructions in Thumb-2 code. For details see [...]"?
... I already tried pushing him in this direction with no success...!
(These are the narrow and wide variants that he claims to understand the implication of)
LDRB.N R0,[R1,#USB0_CSRL0] LDRB.W R0,[R1,#USB0_CSRL0]
Yes, but the OP is convinced that we still haven't even understood his problem, so why would he assume that any of our comments may be related to the problem?
Continuing on Andys track: a C programmer would have managed to implement quite a lot of real functionality by now since the C compiler condenses quite a lot of experience and documentation into a readily available digital servant.
> 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/
This place is technical forum.
More to the point, it's a dicsussion forum. You don't seem to know what that means, though. You come here not just expecting, but outright demanding that everybody agrees with you, simply because you say so. That's not discussion, that's attempted dictature.
And since the subject matter of this forum is of a technical nature, you come across people who don't just hold opinions, but actually know things for a fact.
Let's, indeed. If only you would shut up til then, we'ld all be better off: you'll be indulging in your own self-righteousness, and we'll be enjoying your silence.
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.