mixing C and assembly
in [Embedded]
|
Prev: Loop back fails
Next: china wholesale cheap nike air max 87 90 95 ltd tn shoes bapesta hogan sneakers china suppliers www.voguesonline.net
From: cbarn24050 on 24 Apr 2008 08:30 On Apr 24, 12:43 am, David Brown <david.br...(a)hesbynett.removethisbit.no> wrote: > cbarn24...(a)aol.com wrote: > > On Apr 23, 10:03 pm, David Brown > > <david.br...(a)hesbynett.removethisbit.no> wrote: > >> cbarn24...(a)aol.com wrote: > >>> On Apr 23, 7:27�pm, Walter Banks <wal...(a)bytecraft.com> wrote: > >>>> Stefan Reuther wrote: > >>>>>> register_sp SP; > >>>>>> SP = int_value; > >>>>> What you're doing here is writing assembly with C syntax. It relies upon > >>>>> a heavily non-standard language extension, and makes assumptions about > >>>>> how the compiler behaves (you don't want the compiler to use the stack > >>>>> before your SP assignment, do you?). So instead of writing assembly in > >>>>> C, I prefer using the real thing. > >>> Yes, thats what he always does! He can then claim his compiler can > >>> beat assembler for speed,code size ect. To Walter if it looks Cish, > >>> ends in a semicolon and his compiler can change it into machine code > >>> then its C. > >>>> I actually agree with you it is very low level C. The purpose of ISO/IEC > >>>> 18037 was to define the low level syntax. Most start up code is very processor > >>>> family specific. �Writting start up code in C makes good use of C's > >>>> optimization like the branch/jump to main. > >>> Whats to optimise? Why bother optimising a one time instruction? > >>> Sometimes I think you'll say anything to sell a compiler. > >> Why would you bother optimising a traditional call to main into a jump? > >>  On some targets (in particular, several that Bytecraft target), the > >> saved stack space is significant - and even the couple of saved flash > >> bytes is worth doing (given the negligible cost of the compiler's effort). > > > If it is on your project you are allready are allready up a certain > > creek without a paddle. In any event you wouldnt use a "traditional" > > ie a C type call to main from startup so stack saveing would be > > minimal. > > First off, Walter writes compilers and their associated libraries - > saving a few bytes of stack space there means savings for all his users. >  We are not talking about individual projects here. No we're talking about startup code, do try to keep up. > > Secondly, some processors have small fixed-size hardware stacks (small > PIC's and AVR Tiny's are examples).  For such devices, a single > unnecessary "call" can waste a third of your stack resources.- Hide quoted text - Firstly you would be mad to try running C of these chips. Secondly you would not put call returns on the hardware stack unless you have some kind of death wish, you keep that space for the ISRs. > > - Show quoted text -
From: cbarn24050 on 24 Apr 2008 08:33 On Apr 24, 12:13�am, CBFalconer <cbfalco...(a)yahoo.com> wrote: > Walter Banks wrote: > > >> Why would you bother optimising a traditional call to main into > >> a jump? > > > When C runs on embedded systems processors that are not hosted > > main should never return. > > What if the programmer puts (as he should) a return into main? > This means you have to stack an address for that return (possibly > the address of main). Indeed you do but it's not usually more than 2 bytes, you cant get much more optimal than that. > > -- > �[mail]: Chuck F (cbfalconer at maineline dot net) > �[page]: <http://cbfalconer.home.att.net> > � � � � � � Try the download section. > > ** Posted fromhttp://www.teranews.com**
From: cbarn24050 on 24 Apr 2008 08:38 On Apr 24, 8:18�am, David Brown <da...(a)westcontrol.removethisbit.com> wrote: > Bill Leary wrote: > > "Walter Banks" <wal...(a)bytecraft.com> wrote in message > >news:480FAC36.E382E22B(a)bytecraft.com... > >>> Why would you bother optimising a traditional call to main into a jump? > > >> When C runs on embedded systems processors that are not hosted main > >> should never return. > > > Usually, no. �But it's a good idea to make sure the system does > > something reasonable if it does. > > Why should the system do something reasonable if the programmer does > something unreasonable? �In my gcc programs, main is tagged with a > "noreturn" attribute - attempting to return from main will produce at > least a warning message, possibly an error (I can't remember off-hand). > � I'm sure Walter's compilers are able to enforce no return from main > equally well. Anything can upset a program, you need some kind of error code, also needs to be in assembly, to make the system safe.
From: Bill Leary on 24 Apr 2008 08:32 "David Brown" <david(a)westcontrol.removethisbit.com> wrote in message news:48102f95$0$23838$8404b019(a)news.wineasy.se... > Bill Leary wrote: >> "Walter Banks" <walter(a)bytecraft.com> wrote in message >> news:480FAC36.E382E22B(a)bytecraft.com... >>>> Why would you bother optimising a traditional call to main into a jump? >>> >>> When C runs on embedded systems processors that are not hosted main >>> should never return. >> >> Usually, no. But it's a good idea to make sure the system does something >> reasonable if it does. > > Why should the system do something reasonable if the programmer > does something unreasonable? Because programmers WILL do something unreasonable and helping them to discover what that is, beyond the system going bye-bye, is good engineering. A bit of work here can potentially save a pile of work later on. > In my gcc programs, main is tagged with a "noreturn" attribute > - attempting to return from main will produce at least a warning > message, possibly an error (I can't remember off-hand). OK. So you DID do the "something reasonable," using a feature provided by your development package. > I'm sure Walter's compilers are able to enforce no return from > main equally well. - Bill
From: David Brown on 24 Apr 2008 08:44
cbarn24050(a)aol.com wrote: > On Apr 24, 12:43 am, David Brown > <david.br...(a)hesbynett.removethisbit.no> wrote: >> cbarn24...(a)aol.com wrote: >>> On Apr 23, 10:03 pm, David Brown >>> <david.br...(a)hesbynett.removethisbit.no> wrote: >>>> cbarn24...(a)aol.com wrote: <snip> >>>> Why would you bother optimising a traditional call to main into a jump? >>>> On some targets (in particular, several that Bytecraft target), the >>>> saved stack space is significant - and even the couple of saved flash >>>> bytes is worth doing (given the negligible cost of the compiler's effort). >>> If it is on your project you are allready are allready up a certain >>> creek without a paddle. In any event you wouldnt use a "traditional" >>> ie a C type call to main from startup so stack saveing would be >>> minimal. >> First off, Walter writes compilers and their associated libraries - >> saving a few bytes of stack space there means savings for all his users. >> We are not talking about individual projects here. > > No we're talking about startup code, do try to keep up. > Walter writes compilers for a living, so his comments are based at least partly on that - and I was commenting on your comments on his comments, if you see what I mean. But we are also talking about project-specific startup code. When you are writing your own startup code, as is appropriate for some projects, I can't really see why you would intentionally and knowingly want to waste some ram, flash and run-time by specifically choosing a call when a jump will do the job. If the source code is neater or clearer, or faster to write, then that is obviously the decider. But all other factors being equal, a jump will do the same thing. In fact, if you are using a compiler that does some sort of whole-program optimisation, and you write your startup code in C, you can expect that you will get neither a call to main, nor a jump to main - the entire main() function will be inlined within the startup code. >> Secondly, some processors have small fixed-size hardware stacks (small >> PIC's and AVR Tiny's are examples). For such devices, a single >> unnecessary "call" can waste a third of your stack resources.- Hide quoted text - > > Firstly you would be mad to try running C of these chips. Secondly you > would not put call returns on the hardware stack unless you have some > kind of death wish, you keep that space for the ISRs. > Firstly, you must then call me mad, along with all the customers for PIC C compilers targeted at the smallest PICs, and ImageCraft's dedicated AVR Tiny C compiler. I've only used a Tiny once, but I wrote that program in C (using gcc - with a bit of arm-twisting to make it work without RAM). I studied the generated assembly - it is unlikely that I could have improved on it more than a few percent if I had hand-write the assembly. Secondly, the AVR Tiny has no ram beyond its 32 cpu registers. I find it hard to imagine that you could write a program that needed more than 3 levels of calls (including interrupts) and have space in those registers to make a software call stack. These are devices aimed at small and simple programs - three levels of call stack is often sufficient. |