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: Hans-Bernhard Bröker on 22 Apr 2008 17:45 Lax wrote: > Are there any situations where programming an embedded processor > "requires" at least some assembly code? Yes. Somebody, somewhere, some time, will have to write some assembly code. Startup code, low-level support routines for the C compiler, task switching support, ... that kind of thing. It depends on just about every partner in the process (from chip designer to application customer) whether "somebody" includes you, the embedded software engineer. > How about for AVR, MSP430, 68HC11, 8051(Atmel)? > Can these 4 microcontrollers be programmed fully in C without touching > assembly (even interrupts and etc.)? That depends entirely on what one still considers to be "in" C, and how the tool makers chose to handle those features of an embedded controller that strictly pure standard C can't handle. E.g., ISRs could be mapped to the signal() mechanism of standard C. But hardly anyone ever actually does that. Instead, there are compiler extensions or assembly wrappers that link C functions to interrupts.
From: Neil on 22 Apr 2008 23:16 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. >> >> Other then that, everything can be done in C. > > Vladimir, > > 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. > > Regards, > > -- > Walter Banks > Byte Craft Limited > Tel. (519) 888-6911 > http://www.bytecraft.com > walter(a)bytecraft.com > > > > > > Do not forget the startup code
From: Neil on 22 Apr 2008 23:22 Lax 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.)? MAYBE For many applications using small CPUs you do not need any ASM. There are situations where you do need it. Your code may vary. Of the above I have used Keil 8051 C compiler. Many general apps did not need ASM.
From: Chris H on 23 Apr 2008 02:13 In message <fulm9l$r16$02$1(a)news.t-online.com>, Hans-Bernhard Br�ker <HBBroeker(a)t-online.de> writes >Lax wrote: >> Are there any situations where programming an embedded processor >> "requires" at least some assembly code? > >Yes. Somebody, somewhere, some time, will have to write some assembly >code. Startup code, low-level support routines for the C compiler, >task switching support, ... that kind of thing. > >It depends on just about every partner in the process (from chip >designer to application customer) whether "somebody" includes you, the >embedded software engineer. > >> How about for AVR, MSP430, 68HC11, 8051(Atmel)? >> Can these 4 microcontrollers be programmed fully in C without touching >> assembly (even interrupts and etc.)? > >That depends entirely on what one still considers to be "in" C, and how >the tool makers chose to handle those features of an embedded >controller that strictly pure standard C can't handle. E.g., ISRs >could be mapped to the signal() mechanism of standard C. But hardly >anyone ever actually does that. Instead, there are compiler extensions >or assembly wrappers that link C functions to interrupts. I agree... if you go to comp.lang.c you will find that Gcc is NOT C... it is a "C like language" as it is not a full C implementation and has Gcc extensions quite apart from extensions for the target Also most compilers for embedded targets have many "assembler like" extensions eg where you can put hex directly into registers and peripherals. The "C" function to set up the UART on an 8051 with a Keil compiler looks almost the same as assembler! 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. It is usually automatically pulled in as an object file. That said you can program most of these micros in pure C with no extensions (compiler or targets) BUT it is usually very inefficient code and no one is likely to employ you if you do that. -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
From: David Brown on 23 Apr 2008 03:51
Chris H wrote: > In message <fulm9l$r16$02$1(a)news.t-online.com>, Hans-Bernhard Br�ker > <HBBroeker(a)t-online.de> writes >> Lax wrote: >>> Are there any situations where programming an embedded processor >>> "requires" at least some assembly code? >> >> Yes. Somebody, somewhere, some time, will have to write some assembly >> code. Startup code, low-level support routines for the C compiler, >> task switching support, ... that kind of thing. >> >> It depends on just about every partner in the process (from chip >> designer to application customer) whether "somebody" includes you, the >> embedded software engineer. >> >>> How about for AVR, MSP430, 68HC11, 8051(Atmel)? >>> Can these 4 microcontrollers be programmed fully in C without touching >>> assembly (even interrupts and etc.)? >> >> That depends entirely on what one still considers to be "in" C, and >> how the tool makers chose to handle those features of an embedded >> controller that strictly pure standard C can't handle. E.g., ISRs >> could be mapped to the signal() mechanism of standard C. But hardly >> anyone ever actually does that. Instead, there are compiler >> extensions or assembly wrappers that link C functions to interrupts. > > > I agree... if you go to comp.lang.c you will find that Gcc is NOT C... > it is a "C like language" as it is not a full C implementation and has > Gcc extensions quite apart from extensions for the target > gcc supports at least as high a proportion of C99 as the great majority of commercial compilers, and I don't know off-hand of any pre-C99 language issues. Just like all commercial compilers I am familiar with (I've used a few over the years), gcc has extensions which can be enabled or disabled. Some of these extensions are target-specific (such as for interrupt handling), others are target-independent (such as allowing certain C++ constructs in C, and vice-versa). Since gcc has barely been mentioned in this thread, you must have good reason for bringing it up - surely it was not merely for gratuitous and unsubstantiated bashing (and surely it was not trolling for my reply, to re-establish our relationship after too many recent agreements :-) Since you hang out gcc for not being "a full C implementation", and for having "extensions quite apart from extensions for the target", can you give me some examples of other available compilers that *are* "full C implementations" (along with an explanation of exactly what you mean by that phrase), which have *no* compiler extensions, and which are targeted at embedded systems? Beyond the obsessive gcc-bashing, I pretty much agree with your post. > Also most compilers for embedded targets have many "assembler like" > extensions eg where you can put hex directly into registers and > peripherals. The "C" function to set up the UART on an 8051 with a Keil > compiler looks almost the same as assembler! Embedded toolchains are pretty much useless unless you can get low-level access beyond what can be written in standard C with standard libraries, so there are normally either extensions to the compiler, or extra library functions (often just wrappers around embedded assembly). > > 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. > It is usually automatically pulled in as an object file. > Although the compiler and its libraries will often handle this sort of thing, it is sometimes useful to write it yourself. Sometimes you want to use different memory layouts from the standard ones, and sometimes you need board-specific low-level code at the start. For example, I have a card with external sdram - I needed to initialise the sdram before copying the program over from flash to sdram and running it there. I also have two separate sets of .bss and .data - one in the sdram, and one in fast internal ram. So I had a specific startup routine to handle that copying. Depending on your tools, however, this sort of thing can often be written in C - even though your real C environment is not yet ready (for example, initialised data are not yet initialised, and for C++ your global objects are not yet constructed). I find that my assembly can often be reduced to two or three op-codes at the very start (if the toolchains standard startup code is not suitable), along with some embedded assembly macros or function wrappers for things like interrupt control, or accessing cpu-space registers on some targets. > That said you can program most of these micros in pure C with no > extensions (compiler or targets) BUT it is usually very inefficient code > and no one is likely to employ you if you do that. > You usually need to use your compiler's target extensions (for interrupts, if nothing else), unless you have a ready-made OS layer that handles that sort of thing for you. For "general" C programming, it is rare that you can write significantly smaller or faster code using assembly than a good compiler will generate. This is especially true for big processors where manually tracking things like register allocations, pipelining, and instruction overlap will drive you up the wall - the compiler does this quickly and easily, and thus will generate better code than all but the most dedicated assembly programmers. Similarly, for very small and limited cpus, modern compilers can optimise things like bank switching and data placement better than a human can while still writing legible and maintainable code. Compilers often have other extensions which *can* make a big difference, however. Extensions giving hints to the compiler ("inline" is often available as an extension when compiling for older C standards) can make the generated code smaller and/or faster. Extensions for source code, such as unnamed structs and unions, or flexible array types, can lead to clearer and neater source code. Obviously you must be aware of when such extensions make your code non-portable between targets and/or compilers - it's a tradeoff you have to evaluate. 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. |