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: David Brown on 23 Apr 2008 14:07 Walter Banks wrote: > > David Brown wrote: > >> 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. > > David, > > ISO/IEC 18037 supports named address spaces and user defined > address spaces. Named address spaces allows direct access to the > processor memory space that is used in some DSP's for mac operations > User defined address space is a little more complex but allows > positioning of mac specific buffering. > > Byte Craft found that the data types and better access > to the processors native address space separated a lot of the > implementation specific extensions and intrinsics. My experience > in automotive applications was it refocused the compiler on > mac code generation and the application on algorithms. > > Retargeting the automotive code to a different execution platform > in our case required little more than redefining the processor specific > address space. > > Our experience is similar to that of other compiler companies > that have implemented ISO/IEC 18037 > The named address spaces and other ISO/IEC 18037 changes will also be welcome additions to C compilers. I still don't see that the changes will eliminate all the intrinsics and extensions in some of the dsp code I've seen - but I haven't actually tried it in practice. Obviously you know a lot more that I about the new types and other enhancements to C, and what can be done with them - I've merely read a couple of spec's.
From: Walter Banks on 23 Apr 2008 14:27 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. 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. w..
From: cbarn24050 on 23 Apr 2008 14:48 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. > > w..
From: Walter Banks on 23 Apr 2008 16:38 cbarn24050(a)aol.com wrote: > Whats to optimise? Why bother optimising a one time instruction? > > Sometimes I think you'll say anything to sell a compiler. :) The serious answer is some initialization on some processors requires memory management that is easier for the compiler to do. I think my comments on startup code would apply to quite a few embedded compilers. w..
From: David Brown on 23 Apr 2008 17:03
cbarn24050(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). There is also the question of why would one bother to write code that you know is less than optimal, if it is just as easy to write better code? |