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