How do you choose an ARM family

you see, I have provided a quote which makes you look bad because you made a totally unfounded, repeated and fantastic claim that is (as far as I can tell; if somebody knows better please do correct me and justify the "professor"!) wrong. you showed a piece of assembly that further proves that you don't understand the problem at hand. I am still waiting. show me a quote or a piece of code that proves you point; show me that apart from register R1 to R4 in thumb mode, a program does not need to preserve the processor context (unless the register is shadowed by the mode itself, or course!!!!).
I'm still waiting.

you see, I have provided a quote which makes you look bad because you made a totally unfounded, repeated and fantastic claim that is (as far as I can tell; if somebody knows better please do correct me and justify the "professor"!) wrong. you showed a piece of assembly that further proves that you don't understand the problem at hand. I am still waiting. show me a quote or a piece of code that proves you point; show me that apart from register R1 to R4 in thumb mode, a program does not need to preserve the processor context (unless the register is shadowed by the mode itself, or course!!!!).
I'm still waiting.

Based on:
infocenter.arm.com/.../IHI0042C_aapcs.pdf

5.1.1
This paragraph seems to indicate that you need not preserve r0 to r3:

r0 named scratch register 1
...
r3 named scratch register 3

and:
"The first four registers r0-r3 (a1-a4) are used to pass argument values into a subroutine and to return a result value from a function. They may also be used to hold intermediate values within a routine (but, in general, only between subroutine calls)."

the "(but, in general, only between subroutine calls)" seems to indicate that if the called function is visible to the compiler, the compiler can see if any of these registers are unused in the function. For the general case, they are assumed to be destroyed.

This also seems to indicate that r0 .. r3 need not be preserved (still 5.1.1):
"A subroutine must preserve the contents of the registers r4-r8, r10, r11 and SP (and r9 in PCS variants that designate r9 as v6)."

---

Then something about using volatile in loops. We have had a debate about this earlier and not managed to find 100% proof from the C standard what goes.

The AAPCS specifies in 7.1.5 (my emphasis)
"A data type declaration may be qualified with the volatile type qualifier. The compiler may not remove any access to a volatile data type unless it can prove that the code containing the access will never be executed; <v>however, a compiler may ignore a volatile qualification of an automatic variable whose address is never taken unless the function calls setjmp()."

In short, a loop with a volatile local loop variable that doesn't get the address taken may be removed. So volatile doesn't guarantee that a delay loop will survive.

I know, I just found it myself following the lack of response from our talented peer.

Tapeer.

'our talented peer.'

respect at last.

ha ha ha ho ho ho

Always yo're freind.

Zeusti.

I don't know what is worst - making a mistake because I got confused with another process architecture that I used to work with, or writing delay loops that can kill people. I have a guess that you will pick the first option - well, well, well....

in other words - preserving 2 redundant registers is not going to do any harm to anyone. but writing broken C code like you do - and you brag about it even (making me laugh time after time after time...) is on the verge on criminality in certain circles.

I have still never seen a compiler remove a loop where the loop variable has been volatile. And I haven't been able to find a sentence in the C standard that clearly indicates if the compiler is allowed to, or isn't allowed to.

But the ARM document seems to say that it is an allowed, but not required optimization.

Another issue here is that you may have delay loops in a program for more than one reason.

One reason may be to make something happen once/second. Such a product isn't likely to get out on the market without you noticing that it runs at 100 times the normal speed because of the lack of delay. Any use of a loop for creating exact delays are a way to sure disaster. Using assembler or __nop() could give a minimum delay, but the loop will not be able to adjust for the interrupt load. Obivously, a timer or similar should be used when actual delay length is important.

The other reason may be to create short micro-delays in the code. You maybe need 30 NOP instructions to let an external signal settle. Using a small loop with a few __nop() consumes less code space than having all the __nop() in a long sequence. For ARM mode, 30 nop instructions would consume 120 bytes. As long as the compiler treats the __nop() as having a side effect it isn't allowed to optimize away, such software loops should be ok, and shouldn't even need any "volatile" on the loop variable. Such a loop will not create a fixed delay, but instead a minimum delay. But that is fine if the requirement is just to get enough settle time on a signal. The extra cycles for the loop instructions or from an interrupt in the middle of the delay can then be ignored.

But the bottom line here is that whenever you design critical hardware - whatever algorithms the program contains - you will have to get the software through a release acceptance test of some form. Such a test is seriously broken if it does not verify all timing means used by the software. It should verify that the real-time clock ticks one second/second with a suitable precision. If changing a couple of source-code lines rsults in a day or a week of testing, a change of compiler, processor frequency or processor model would most definitely not lead to less testing.

The issue with software delays is that the testing may see that the delay is long enough. But it can be hard to get the test to figure out potential problems if the sw delay gets extended to the maximum because of maximum interrupt loads from all possible sources during the delay. Such behaviour will require a lot of theoretical work too since a test rig has limitations.

Tapir.

<quote>
I have a guess that you will pick the first option - well, well, well....
</quote>

why do you keep judging the book when you cannot see it?

can u remembar back? when i first sayed you do not need to preserve r0 etc.

i then wrote a delay rootine in ASSEMBELY which you sayed was bad. becoz u sayed i did not preserve registers. { now you learn u do not need to }

today i wrote a loop in c and you compain. but i did it for u for example. bcoz u did not beleive me. i do not normelly write code like it. i did it bcoz i needed to hilite yo're pour understanding of the register useage.

now u know i was right u still try to say i am bad.

u plz read the books. then u 2 can maybe write efficient relieble code.

Always yo're freind.

Zeusti.

Tapir.

<quote>
but writing broken C code like you do
</quote>

books and false judgements agin?

plz read the previes postings

remembar:

u only guess what i do. i know what i do!

Always yo're freind.

Zeusti.