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: Walter Banks on 23 Apr 2008 08:07 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..
From: Walter Banks on 23 Apr 2008 08:26 Chris H wrote: > As has already been mentioned the start up code has to be in assembler > as it sets up the memory for the stack etc however if you use the > standard one that comes with the compiler you will never need to see it. There is no requirement for the start up code to be in asm. A lot of compilers come with asm sample startup but the code could have been written in C in the same compiler. The same extensions that support embedded systems make this possible Regards, -- Walter Banks Byte Craft Limited Tel. (519) 888-6911 http://www.bytecraft.com walter(a)bytecraft.com
From: Walter Banks on 23 Apr 2008 08:39 David Brown wrote: > The one place where compiler assembly-like extensions and/or real > assembly can make a big difference is for dsp programming. Compilers > are getting better at turning C loops into optimal dsp code, but in many > cases you have to write something horrendous involving all sorts of > compiler/target-specific pseudo-functions to end up with optimal > assembly - writing in pure assembly is often clearer and neater. In the area of DSP the single biggest change has been IEC/ISO 18037 which made it a lot easier to express DSP algorithms in C without using obscure syntax. The C source quickly became a lot easier to port between architectures. The biggest difference was clear way to simply express the data structure of the target processor. At the instruction level the compiler was responsible for mapping the C on the processors mac instructions. Porting went from needing to rewrite the asm code for each target to changing declarations describing the data struct with a minor amount of tweaking. There are other things in this C extension as well that normalized the definitions of fract and accum data types which cleaned up a way to represent data for DSP applications. Regards, -- Walter Banks Byte Craft Limited Tel. (519) 888-6911 http://www.bytecraft.com walter(a)bytecraft.com
From: David Brown on 23 Apr 2008 09:02 Walter Banks wrote: > > David Brown wrote: > >> The one place where compiler assembly-like extensions and/or real >> assembly can make a big difference is for dsp programming. Compilers >> are getting better at turning C loops into optimal dsp code, but in many >> cases you have to write something horrendous involving all sorts of >> compiler/target-specific pseudo-functions to end up with optimal >> assembly - writing in pure assembly is often clearer and neater. > > In the area of DSP the single biggest change has been IEC/ISO 18037 > which made it a lot easier to express DSP algorithms in C without > using obscure syntax. The C source quickly became a lot easier to > port between architectures. The biggest difference was clear way to > simply express the data structure of the target processor. At the > instruction level the compiler was responsible for mapping the C > on the processors mac instructions. > > Porting went from needing to rewrite the asm code for each target to > changing declarations describing the data struct with a minor > amount of tweaking. > > There are other things in this C extension as well that normalized the > definitions of fract and accum data types which cleaned up a way to > represent data for DSP applications. > Once support fract/accum/sat becomes common in C compilers, then it will certainly make it easier to write legible, portable code working with scaled fractional integers. I seriously doubt that it will entirely remove the need for extensions and intrinsics to get optimal code from powerful DSPs, but it will certainly be a solid step in the right direction and will let you write close to optimal code for everything but the tightest of inner loops. mvh., David
From: Mark Borgerson on 23 Apr 2008 10:26
In article <480F2B12.69B62031(a)bytecraft.com>, walter(a)bytecraft.com says... > > > Chris H wrote: > > > As has already been mentioned the start up code has to be in assembler > > as it sets up the memory for the stack etc however if you use the > > standard one that comes with the compiler you will never need to see it. > > There is no requirement for the start up code to be in asm. A lot of > compilers come with asm sample startup but the code could have > been written in C in the same compiler. The same extensions that > support embedded systems make this possible > > Regards, > Just out of curiosity, how do you set the initial value of the stack pointer in C? Mark Borgerson |