On Apr 7, 2014, at 2:36 PM, smplx wrote:

> why is accessing globals more expensive [on MIPS/ARM]? If you are=20
> simply using an offset from a register, wouldn't you simply have a=20
> register that pointed to the start of your globals?

Apparently not.  I imagine that it'd be a complicated decision whether
you wanted to lose a valuable register vs have a (limited range) of global
variables that were accessible "quickly."  And the linker is involved, sinc=
e
globals get pulled from multiple object files.  The linker complication can
prevent half-address optimization (eg on PIC32.  Sigh.) The "offset" also
tends to be relatively small (-255 to 4095 for ARM Cortex.)


> insisting that all parameters and locals be held on a=20
> runtime stack does prevent certain types of optimisations


Yeah, but that's not actually what we're talking about.  We're were talking
about global vs local variables in functions, which, while they are frequen=
tly
implemented as stack variables, don't NEED to be, and frequently aren't.

I ran some not-very-realistic examples (shown below) through several C comp=
ilers
(avr-gcc, cc5x for pic16, xc8 for pic16, xc16 for pic24) and in all cases t=
he "local variable"
version had smaller and faster code.  Usually that was because the compiler=
 did
extra optimization and didn't even wind up with a stack frame at all.  (cc5=
x actually
had identical code, because it just used direct memory access for both vers=
ions; I'm
sure what it would have done with additional program depth.)  I believe the=
 hand-done
PIC24 example, but it only "won" because PIC24 has 24bit single-word instru=
ctions with
to the full RAM address space.  On a more typical CPU (msp430?), the stack-=
relative
instructions might be one word (16 bits) and the "direct access" instructio=
ns two
words.  And then  you're talking about 5 scsw instructions vs 3 dcdw instru=
ctions...

So I think we're really down to "you should do what seems to make logical s=
ense,
except in cases where every cycle counts.  And then you have to inspect the=
 code
produced by your particular case, rather than follow any general rules=85

char foo()
{
    auto char a, b;
    a =3D PORTB;
    b =3D PORTC;
    return a+b;
}

char d, e;
char bar()
{
    d =3D PORTB;
    e =3D PORTC;
    return d+e;
}


--=20
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.