On Apr 23, 10:03=C2=A0pm, David Brown <david.br...@hesbynett.removethisbit.no> wrote:> cbarn24...@aol.com wrote: > > 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 up=on> >>> 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/IE=C> >> 18037 was to define the low level syntax. Most start up code is very pr=ocessor> >> 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. > > Why would you bother optimising a traditional call to main into a jump? > =C2=A0 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.> > 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?=- Hide quoted text -> > - Show quoted text -
mixing C and assembly
Started by ●April 22, 2008
Reply by ●April 23, 20082008-04-23
Reply by ●April 23, 20082008-04-23
> 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. w..
Reply by ●April 23, 20082008-04-23
On Apr 23, 9:38=EF=BF=BDpm, Walter Banks <wal...@bytecraft.com> wrote:> cbarn24...@aol.com wrote: > > Whats to optimise? Why bother optimising a one time instruction? > > > Sometimes I think you'll say anything to sell a compiler. > > :) =EF=BF=BD The serious answer is some initialization on some processors > requires memory management that is easier for the compiler to > do.Any hope of an example that demonstates your point?> > I think my comments on startup code would apply to quite a > few embedded compilers. > > w..
Reply by ●April 23, 20082008-04-23
Walter Banks wrote:>... snip ...> > 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;In other words you seized a user available identifier, register_sp, and then recognized that in the code to accept an int_value and initialize the stack pointer. This is not C, but an extension. The only thing wrong with that is that it is not marked as an extension. If the mechanism is also used to read the SP the above declaration should mark it as volatile. I think it would be better to use a name reserved for the implementation, such as __register_sp. I am not objecting to extensions. However I believe they should minimize any effects on standard C. -- [mail]: Chuck F (cbfalconer at maineline dot net) [page]: <http://cbfalconer.home.att.net> Try the download section. ** Posted from http://www.teranews.com **
Reply by ●April 23, 20082008-04-23
"Walter Banks" <walter@bytecraft.com> wrote in message news:480FAC36.E382E22B@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. I said before that I wrote init routines to "jump" to _main. And I have, when it had to be that way. But whenever I've had a choice, I've actually pushed the address of my restart routine onto the stack first then done the jump. If _main DOES return, the machine reboots. In one case I raised the error flag on the system and set a code in the status LEDs when _main returned. - Bill
Reply by ●April 23, 20082008-04-23
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). -- [mail]: Chuck F (cbfalconer at maineline dot net) [page]: <http://cbfalconer.home.att.net> Try the download section. ** Posted from http://www.teranews.com **
Reply by ●April 23, 20082008-04-23
cbarn24050@aol.com wrote:> On Apr 23, 10:03 pm, David Brown > <david.br...@hesbynett.removethisbit.no> wrote: >> cbarn24...@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). > > 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. 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.
Reply by ●April 23, 20082008-04-23
CBFalconer wrote:> Walter Banks wrote: > ... snip ... >> 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; > > In other words you seized a user available identifier, register_sp, > and then recognized that in the code to accept an int_value and > initialize the stack pointer. This is not C, but an extension. > The only thing wrong with that is that it is not marked as an > extension. If the mechanism is also used to read the SP the above > declaration should mark it as volatile. I think it would be better > to use a name reserved for the implementation, such as > __register_sp. > > I am not objecting to extensions. However I believe they should > minimize any effects on standard C. >Personally, I prefer to avoid extra underscores - they make the code look ugly. But it's important that it is possible (through compiler flags and/or choice of include files) to disable any extensions not marked with double underscores.
Reply by ●April 23, 20082008-04-23
On Apr 22, 3:50=A0am, Lax <Lax.Cla...@gmail.com> wrote:> Are there any situations where programming an embedded processor > "requires" at least some assembly code? > > How about for AVR, MSP430, 68HC11, 8051(Atmel)? > Can these 4 microcontrollers be programmed fully in C without touching > assembly (even interrupts and etc.)?Can't interface with with external hardware without assembly.
Reply by ●April 23, 20082008-04-23
On Tue, 22 Apr 2008 01:50:31 -0700 (PDT), Lax <Lax.Clarke@gmail.com> wrote:> >Are there any situations where programming an embedded processor >"requires" at least some assembly code? > >How about for AVR, MSP430, 68HC11, 8051(Atmel)? >Can these 4 microcontrollers be programmed fully in C without touching >assembly (even interrupts and etc.)?Why do you ask this ? Do you expect that you could work with embedded systems without learning anything about the hardware architecture and the processor instruction set ? Most embedded project could be written completely in C except for the initialization code, possibly some interrupt preamble code, OS task switching and the use of some processor specific special instructions. In most cases this would be 1-2 pages of assembler code. However, if you are developing embedded applications in C or in other high level languages, you really have to understand what machine instructions are generated and what resources are needed for a specific construction. Also when debugging a program, understanding the instruction set (and assembler) will help a lot. Paul
