Re: Startup code

Meindert Sprang wrote: 
"Jet Morgan" <jm@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:d9tsta$po7$1@xxxxxxxxxxxxxxxxxxxxxxx

That is still startup code, even if written in C. 


In my opinion, startup code is code executed from the reset of the CPU,
until the call to main().
So any function you call from main() to setup up further things, no matter
how low level and essential they are, is not called startup code.


What you call "startup code" is a matter of taste. There are a few things that need to be done before the main part of a program can run - setting up critical hardware (chip selects, memory areas, etc.), setting up the stack, clearing out bss, copying initial data segments, copying program data from flash to ram (if necessary), calling C++ constructors (for C++ only, obviously), starting main(), initializing other hardware and software.

Normally everything after the start of main() is the application programmer's domain, and it is written in C (I'm assuming the main language here is C/C++). You can call it startup code if you like.

Code for setting up the stack, clearing bss, and copying the initial data segment is generally part of the "crt0" module that comes with your C compiler. It's frequently written in assembler, by the compiler library designers.

Code for configuring critical hardware like chip selects is generally only necessary on "big" microcontrollers with flexible external memories. Code to do this is often part of a boot loader of some kind, and may or may not come with the compiler. It's often part of a "board support package" for an OS, and is also frequently written in assembler.

Personally, I tend to use compiler-generated startup code for small micros, but write my own for bigger micros. I have a couple of lines of assembly (typically "enable internal ram, set stack pointer, jump to C code") to get started, then the rest of the setup is in C. Such code has to be a little careful - bss variables and const are not yet initialized - but it's far more convenient than doing everything in assembly.



The compiler vendor will not typically know how the processor
is connected to the other devices, such as memory bus widths,
clock timings etc. That's why YOU (the designer) has to write it.



If need be, yes.


There seems to be this perception that startup code is specifically
assembler. It *could* be written that way but I've always
written my startup code in a combination of C and assembler.



Again, all startup codes I have seen so far, were written in assembler.
Probably because at startup time, there is no environment set up yet to run
compiled C code at all. But this only holds true with "my" definition of
startup code, where the call to main() is not executed yet.

Meindert


.

Relevant Pages

  • Re: No wars
    ... > assembler, because you can look at the compiler output to see how the ... > compiler is doing things, you can concentrate on learning things one at ... familiar with that has inline assembler capacity, ... and going without all of the difficult startup code. ...
    (comp.lang.asm.x86)
  • Re: mixing C and assembly
    ... The system level work like switching the contexts of the tasks, ... Do not forget the startup code ... There are small bits of the startup that must be in assembler (I use ... I've written the startup code in C on the SDCC compiler and the small ...
    (comp.arch.embedded)
  • Re: mixing C and assembly
    ... The system level work like switching the contexts of the tasks, ... Do not forget the startup code ... There are small bits of the startup that must be in assembler. ...
    (comp.arch.embedded)
  • Re: Startup code
    ... >In my opinion, startup code is code executed from the reset of the CPU, ... >> The compiler vendor will not typically know how the processor ... >Again, all startup codes I have seen so far, were written in assembler. ... there is no environment set up yet to run ...
    (comp.arch.embedded)
  • Re: Startup code
    ... In my opinion, startup code is code executed from the reset of the CPU, ... > The compiler vendor will not typically know how the processor ... > written my startup code in a combination of C and assembler. ...
    (comp.arch.embedded)