mixing C and assembly

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..

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

Most do these days.

Very often true.

- Bill

Those I use don't, at least if you don't count inline assembler macros.

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

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.

I actually agree with you it is very low level C. The purpose of ISO/IEC

w..

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.

ssor

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..

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?

on

ocessor

C's

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.

- Hide quoted text -

When C runs on embedded systems processors that are not hosted main should never return.

w..

Any hope of an example that demonstates your point?

... snip ...

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.

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

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).

processor

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.

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.

Can't interface with with external hardware without assembly.

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