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 Regards, -- Walter Banks Byte Craft Limited Tel. (519) 888-6911 http://www.bytecraft.com walter@bytecraft.com
mixing C and assembly
Started by ●April 22, 2008
Reply by ●April 23, 20082008-04-23
Reply by ●April 23, 20082008-04-23
Mark Borgerson wrote:> In article <480F2B12.69B62031@bytecraft.com>, walter@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 > > Just out of curiosity, how do you set the initial value of the > stack pointer in C?Most embedded systems compilers have extensions that support processor register access. A lot of the compilers were implemented from hosted compilers as a base and the initial startup code was written before they added support for processor access. The example startup has often been this early code. My point is that it can be done in C. In our case the first C compiler was written for the C6805 and that was based on a 6805 mistral compiler we had written a few years earlier. Our initial startup code was written in C on a compiler that would support it. register_sp SP; SP = int_value; w..
Reply by ●April 23, 20082008-04-23
"linnix" <me@linnix.info-for.us> wrote in message news:cb7dfc98-3ba4-4a0c-981d-18ddf8057370@e67g2000hsa.googlegroups.com...> On Apr 22, 9:51 am, "Bill Leary" <Bill_Le...@msn.com> wrote: >> "Lax" <Lax.Cla...@gmail.com> wrote in message >> >> news:2defcf6d-7dab-4699-9ce1-d433240398e4@m36g2000hse.googlegroups.com... >> >> > Are there any situations where programming an embedded processor >> > "requires" at least some assembly code? >> >> In every case where I've worked an embedded processor directly, I've had >> to >> at least initialize the environment so it could run C. Basically, setup >> the >> stack, clear RAM and jump to _main. > > There are always assembly involved somewhere, but you don't have to > write them. Why are you re-inventing run-time libraries?Simplest reason in the world. The development package didn't provide them. The app notes specifically said to initialize RAM, set the stack pointer, a couple of other things (ensure interrupts were disabled, I think), then jump to _main. Provided a couple of examples of how to do it, but did not provide them. - Bill
Reply by ●April 23, 20082008-04-23
"Grant Edwards" <grante@visi.com> wrote in message news:3qWdnbveM7gCsJPVnZ2dnUVZ_rjinZ2d@visi...> On 2008-04-22, Bill Leary <Bill_Leary@msn.com> wrote: >> "Lax" <Lax.Clarke@gmail.com> wrote in message >> news:2defcf6d-7dab-4699-9ce1-d433240398e4@m36g2000hse.googlegroups.com... >>> Are there any situations where programming an embedded processor >>> "requires" at least some assembly code? >> >> In every case where I've worked an embedded processor directly, I've had >> to >> at least initialize the environment so it could run C. Basically, setup >> the >> stack, clear RAM and jump to _main. > > For processors without an external bus (IOW they have a fixed > memory map), many toolchains will provide startup code that > does all that.Most do these days.> That's certainly true for GCC on the Atmel AVR > and TI MSP430: tell the compiler which part you're using, and > you don't have to write a lick of startup code.Very often true. - Bill
Reply by ●April 23, 20082008-04-23
Walter Banks wrote:> Mark Borgerson wrote: >>Just out of curiosity, how do you set the initial value of the >>stack pointer in C? > > Most embedded systems compilers have extensions that > support processor register access.Those I use don't, at least if you don't count inline assembler macros.> In our case the first C compiler was written for the C6805 > and that was based on a 6805 mistral compiler we had written > a few years earlier. Our initial startup code was written > in C on a compiler that would support it. > > 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. But a program doesn't need much assembler code. Actually, one of my recent ones has exactly two lines of assembler: the SP assignment, followed by a call to 'main'. But, to be fair, this program is preceded by a boot loader which is 90% assembler, and leaves the processor in a sane state: annoying registers and BSS segment zeroed, compiler startup code often assumes neither. Stefan
Reply by ●April 23, 20082008-04-23
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.
Reply by ●April 23, 20082008-04-23
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..
Reply by ●April 23, 20082008-04-23
On Apr 23, 7:27=EF=BF=BDpm, Walter Banks <wal...@bytecraft.com> wrote:> Stefan Reuther wrote: > > > register_sp SP; > > > > SP =3D 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 proce=ssor> family specific. =EF=BF=BDWritting 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..
Reply by ●April 23, 20082008-04-23
cbarn24050@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..
Reply by ●April 23, 20082008-04-23
cbarn24050@aol.com wrote:> On Apr 23, 7:27�pm, Walter Banks <wal...@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?
