> Fellows,
> I will probably stick on gcc-3.-current version of the compiler and will
> add new feateres and such to this branch. I checked the code generated
> here and find it reasonable. In many cases current versin generates better
> code than 3.0...
>
> So, new I committed new version of gcc with some improvements:
> 1. Improved movstr() insn. (movstr is a built-in compiler command)
> 2. Added trampolines (aka nested functions)
>
> Several words about it:
> Nested functions are function declared within a function declaration and
> can refer to local variables. This is usefull for some cleanups due to
> interrupted call or external alarm. Another advantage - almost everything
> can be done on stack. For example:
>
< Skip example >
>
> Here, all data transfers can be done on buffer allocated on stack =>
> no .data waste.
>
> Disadvantages:
>  - Every nested declaration enlarges code by ~48 bytes.
>  - Every nested call preceeds by 2 instructions:
> mov #SOMECONST, r6
> br #nestedfunct
>  - Something else :)


I'm a little confused here - C does not normally support nested functions,
does it?  Is this part of the C99 standard?  If so, then it's great that
msp430-gcc supports them.  However, are they actually any real use?  I have
done many years programming in Pascal, a language that does support nested
functions, and I have not found any need for nested functions - indeed, I
have found them to be confusing and difficult to maintain, as well as being
less efficient in use (in Pascal, anyway).  Obviously they don't do any
harm - if I don't want to use them, I don't have to.  But I'm just trying to
see if there are circumstances where code can really be written better by
using them.  I suppose if you have optomisation turned on, then the compiler
will probably in-line nested functions where possible, so if you like that
style of coding, it will give you quite a powerful mechanism for splitting a
function into seperate parts without any overhead (other than compiler
effort!).

Why does the code get enlarged by 48 bytes?

>
> Anyway, this is a supported feature, which msp430-gcc has (avr does not ;)
>
> 4. attribute 'reentrant' added. (Not in includes)
>
> This attribute forces gcc to issue eint/dint on function entry/exit
> irrespective to the status register state.
>

Is there any nice way to add an eint/dint to a function that *is* dependant
on the status register state?  I very often need to be able to turn off
interrupts, then restore them to the previous state - it is extremly useful
for accessing hardware or data structures from either interrupt routines or
background routines.

mvh.

David


>
>
> Have fun
> ~d
>



Reply via email to