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: Bill Leary on 24 Apr 2008 17:55 "Walter Banks" <walter(a)bytecraft.com> wrote in message news:48108425.240346E6(a)bytecraft.com... > cbarn24050(a)aol.com wrote: >> > 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. > > A layer of a stack on a PIC with only 8 levels (In one case 2 levels) > has a big impact the available subroutine return stack. Good point. On that sort of machine, you'd have to consider what you were going to use that stack for before you'd use up 1/8 (or even half) of your resources to handle that particular "it'll never happen" scenario. I usually work on systems with a lot more stack resource than that, so pushing a two or four byte return is using a very small percentage of that resource. A reasonable trade off in those environments. - Bill
From: David Brown on 24 Apr 2008 18:08 Neil wrote: > Walter Banks wrote: >> >> Neil wrote: >> >>> Walter Banks wrote: >>>> Vladimir Vassilevsky wrote: >>>> >>>>> You have to resort to assembly in the two special cases: >>>>> >>>>> 1. The system level work like switching the contexts of the tasks, C >>>>> startup code, etc. >>>>> >>>>> 2. The parts of code where the performance is very critical. >>>> In your second point I would qualify it to parts of code >>>> requiring exact timing on anything that we have released >>>> recently that seems to be the only limitation. >>>> >>>> >>> Do not forget the startup code >> >> Our startup code is in C. >> >> w.. >> >> >> > I am not sure how that works. I am talking about the code that jumps to > main after setting up the C environment. So is he. There are small bits of the startup that must be in assembler (I use embedded assembly within the C code - Walter uses C extensions in his compilers that translate directly to matching assembly). But most of it can be written perfectly well in C. For example, code to copy the initialised data from flash to ram, and to zero the bss, can be written in C.
From: cbarn24050 on 24 Apr 2008 19:37 On Apr 24, 1:44�pm, David Brown <da...(a)westcontrol.removethisbit.com> wrote: > cbarn24...(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 They teget them to get money from people like you. 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. I have yet to be convinced that any meaningful program can be written in C for these small devices. Maybe you could post yours. > > 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. Exactly! you cant. C is nested language, functions calling functions calling functions. Thats one reason why it isn't so good on these small chips. �These are devices aimed at > small and simple programs - three levels of call stack is often sufficient..- Hide quoted text - > > - Show quoted text -
From: cbarn24050 on 24 Apr 2008 19:39
On Apr 24, 1:59�pm, Walter Banks <wal...(a)bytecraft.com> wrote: > cbarn24...(a)aol.com wrote: > > > 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. > > A layer of a stack on a PIC with only 8 levels (In one case 2 levels) > has a big impact the available subroutine return stack. Hence the need to avoid C altogether. > > w.. |