How do you choose an ARM family

(knows you do not need to push r0 and r1)

just a little foot note:
you do know that this only applies to THUMB mode, don't you? otherwise, the following would not have appeared in the ATPCS (ARM-Thumb Procedure Call Standard) document, surely you agree?

maybe you have skipped this while browsing your documentation:

infocenter.arm.com/.../DUI0056.pdf

see page 24, paragraph 2.2.1

quote:

The following register usage applies in all variants of the ATPCS except where otherwise stated. To comply with the ATPCS you must follow these rules:
Use registers r0-r3 to pass parameter values into routines, and to pass result values out. You can refer to r0-r3 as a1-a4 to make this usage apparent. See Parameter passing on page 2-9. Between subroutine calls you can use r0-r3 for any purpose. A called routine does not have to restore r0-r3 before returning. A calling routine must preserve the contents of r0-r3 if it needs them again....

however, if you can find a similar quote for ARM mode, in which I have written my code - you are right (but I doubt you will).

(knows you do not need to push r0 and r1)

just a little foot note:
you do know that this only applies to THUMB mode, don't you? otherwise, the following would not have appeared in the ATPCS (ARM-Thumb Procedure Call Standard) document, surely you agree?

maybe you have skipped this while browsing your documentation:

infocenter.arm.com/.../DUI0056.pdf

see page 24, paragraph 2.2.1

quote:

The following register usage applies in all variants of the ATPCS except where otherwise stated. To comply with the ATPCS you must follow these rules:
Use registers r0-r3 to pass parameter values into routines, and to pass result values out. You can refer to r0-r3 as a1-a4 to make this usage apparent. See Parameter passing on page 2-9. Between subroutine calls you can use r0-r3 for any purpose. A called routine does not have to restore r0-r3 before returning. A calling routine must preserve the contents of r0-r3 if it needs them again....

however, if you can find a similar quote for ARM mode, in which I have written my code - you are right (but I doubt you will).

I forgot to highlight the following:

"A called routine does not have to restore r0-r3 before returning". but this is only true when complying with ATPCS. it is certainly not true (as far as I know) when running in ARM mode.

Tapeer.

i dn'nt have time 2 teech u simple basics. but u need advising.

read

en.wikipedia.org/.../Calling_convention

look at entry for arm

read

infocenter.arm.com/.../IHI0042C_aapcs.pdf

look at page 16

if u do not understand now. compile this little function with keil

void SmallDelay(void)
{
  volatile int x;

  for (x=10000;x!=0;--x)
    ;
}

look at the code made by compiler

                  SmallDelay PROC
;;;783
;;;784    void SmallDelay(void)
000ba4  e59f0100          LDR      r0,|L1.3244|
                  |L1.2984|
;;;785    {
;;;786      volatile int x;
;;;787
;;;788      for (x=10000;x!=0;--x)
000ba8  e2500001          SUBS     r0,r0,#1
000bac  1afffffd          BNE      |L1.2984|
;;;789        ;
;;;790    }
000bb0  e12fff1e          BX       lr
;;;791
                          ENDP

see that r0 is not preserved.

or do you think keil have got it wrong?

as i say b4. you should not say book is bad if you have not seen.

Always yo're freind.

Zeusti.

not surprisingly you don't answer my question, but let correct you: R0 is not saved because it should not - it is always used as a return value. try to actually understand what you are posting, for a change.

look man, I'm serious now. you are a danger to society. do you understand? you are dangerous by writing delay loops like that. confide it: you are indeed dangerous. don't write software for:
planes
missile
space systems
cars
trains
etc.

stick to flashing LEDs and bad English, please...

I wonder: can you point to anywhere in the document (that you obviously did not read at all!) to prove that I'm wrong? here, I challenge you: take your time, and tell all of us a page number and paragraph number. I'm waiting, "correcting professor".

Tapeer.

a nother example to cklarimfy.

void SmallLoop(void)
{
  volatile int a;

  for (a=10000;a!=0;--a)
  {
    volatile int b;

    for (b=10000;b!=0;--b)
    {
      volatile int c;

      for (c=10000;c!=0;--c)
      {
        ;
      }
    }
  }
}

                  SmallLoop PROC
;;;783
;;;784    void SmallLoop(void)
000ba4  e59f211c          LDR      r2,|L1.3272|
;;;785    {
;;;786      volatile int a;
;;;787
;;;788      for (a=10000;a!=0;--a)
000ba8  e1a03002          MOV      r3,r2
                  |L1.2988|
;;;789      {
;;;790        volatile int b;
;;;791
;;;792        for (b=10000;b!=0;--b)
000bac  e1a01003          MOV      r1,r3
                  |L1.2992|
;;;793        {
;;;794          volatile int c;
;;;795
;;;796          for (c=10000;c!=0;--c)
000bb0  e1a00003          MOV      r0,r3
                  |L1.2996|
000bb4  e2500001          SUBS     r0,r0,#1
000bb8  1afffffd          BNE      |L1.2996|
000bbc  e2511001          SUBS     r1,r1,#1              ;792
000bc0  1afffffa          BNE      |L1.2992|
000bc4  e2522001          SUBS     r2,r2,#1              ;788
000bc8  1afffff7          BNE      |L1.2988|
;;;797          {
;;;798            ;
;;;799          }
;;;800        }
;;;801      }
;;;802    }
000bcc  e12fff1e          BX       lr
;;;803
                          ENDP

are r0 r1 r2 r3 all return values? have keil got big code problems? no!

plz wake up and read.

Always yo're freind.

Zeusti.

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.

are you sure this code is compiled at ARM mode?

Tapeer,.

YES IT IS ARM MODE!

TRY IT UR SELF!

Always yo're freind.

Zeusti.

leave the compilers aside. can you provide a quote from the documentation founding your claim? how many times do I need to ask? come on, show us. I'm still waiting. If you can then I am wrong - not the end of the world. but you must show the quote first (I didn't find it).

Tapeer.

i told u so many many many times b4 but u seem prejudiced aginst things i say.

look at

infocenter.arm.com/.../IHI0042C_aapcs.pdf

page 16

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).

it does not say must preserve r0-r3. dos it?

why does ity not say r0-r3? bcoz they do not need preserve.

i think i am correct

now plz. u reciover { and maybe apologise }.

Always yo're freind.

Zeusti

(i bare no gruges)

I will not provide a quote but in this particular instance you are right - R0-R3 can freely be corrupted at any processor mode (I don't know the M3).

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.

Tapeer.

<quote>

I will not provide a quote but in this particular instance you are right - R0-R3 can freely be corrupted at any processor mode (I don't know the M3).

</quote>

u r magnanimous in yo're learning.

Always yo're freind.

Zeusti.

(holding no gruge)

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