This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

How to Write C / C++ Code Without Any Runtime Library

Hello all,

How can i write a c or c++ program without any runtime library at all.My basic requirement is i will write all the functions myself and the compiler should only produce the code that my source code says.I will not use any function from the runtime library and i will not even include any header.If it could be done using command line swicthes then please let me know about it.I prefer C Compiler.

I would like to make a boot loader like program using either C or C++.With a little or no ASM

1.Which compiler the BIOS making people use.Do they code only in ASM ?.I assume they use both.
2.What compiler the Single board microprocessor trainer people use ?.
3.Is the simulator like Virtual PC).Like the one available for microcontrollers,like IARs,etc which has editor,compiler & simulator all built in.
4.Where can i get the latest Standard call info which is supported by all processors.Who is standardizing the code.

Thanks

Pak

  • You don't mention an architecture.

    It is hard to write a C program completely without any CRTL. You can replace - or avoid using - the "normal" CRTL functions, but the compiler oftan makes use of internal helper functions. These are hidden functions that are normally not documented anywhere, and you have to look through the produced assemply code to notice the accesses (or single-step in the debugger).

    You obviously can't ask what compilers people use to write a BIOS, since that depends on target platform. With a lot of resources, a C compiler may be possible but writing directly in assembler is often a very good idea. Note that the BIOS most people think about - then one in the PC - now has huge amount of flash available and sometimes even have part of the BIOS stored on a hard drive. All just to be able to display a more-or-less graphical configuration interface for setting a number of parameters.

    Most boot loaders for embedded systems are free of - or have very limited - configuration support. Since a boot loader are so hard to update (most systems don't allow it to be updated at all, or have a upload sequence where you loose the unit if you get a power loss when updating the boot loader) it is important to minimize the amount of code (and chances of bugs) in a boot loader.

    You mention C++. If C can be used, so can C++. However, that would not be the C++ of a normal PC program. A lot of features of C++ are not very suited for boot loaders or embedded systems, because they are aimed at minimizing number of source lines - not amount of RTL help functions.

    What compiler to use for embedded programming? Asked on a Keil forum? Wouldn't it be reasonable that we would say Keil???

    There are obviously no standard call info for a microcontroller. It is just raw hardware. It isn't until you select a standard language, that you will get a subset of the standard RTL for that language - a subset, since a microcontroller can't really make us of everything in the full language standard. Different compiler vendors differs a bit in how they adjust the standard to fit the target. The smaller the microcontoller, the more design decisions has to be made and the more the different compiler vendors will diverge from each other.

  • How can i write a c or c++ program without any runtime library at all.<p>

    Do not use any function from the run-time libraries.

    It sounds simple, but it is a very, very daunting task. Depending on your architecture (which you didn't specify), even the use of "standard" datatypes (like int, long, float, double, etc) might require library calls. You would have to roll your functions for dealing with these data types, which can be extremely hard since C doesn't let you go close enough to the processor to do this efficiently (try adding two 16-bit values on an 8-bit architecture without being able to use the carry flag ...).

  • Hi Pak,

    it is relatively easy to avoid the C run-time environment. At the end of your startup code do not branch to main. Create your C-entry function yourself, like C_Entry. By not calling main, the C run-time environment is not established, including the heap (there is no heap). Make also sure that you disable semihosting (use_no_semihosting). For the rest of your software you have to provide routines for your fixed point math operations depending on your platform (8 bit will be more complicated than 32 bit). If you need floating point math it will get really complicated, so stay away from it. I did several of such projects for safety critical applications and it works but expect a lot of work in front of you. Good luck!

    Frank

  • F D,
    I learn something today (from you! ).
    But of course, I verified you...this is an excerpt from http://www.arm.com:

    "Applications which contain a function main() can make stdio semihosting calls (e.g. printf) when linked with an ANSI C semihosting library. In this case, the C library is initialized automatically as part of __main(), generated by the compiler when it sees main().

    Applications which do not have a main() can still make stdio semihosting calls if an ANSI C semihosting library is (forcibly) linked in. However, in this case the C library is NOT initialized automatically (because the symbol __main was not generated), so the C library must be initialized manually instead."

  • Hi Tamir,

    what you say does not contradict with my posting.
    The ARM C run-time environment is created in a multi-step procedure:

    When you call main:

    - You branch to __main which will copy non root execution regions from their load to execution region and decompress data sections.

    - After __main is finished it will call __rt_entry which will first create the required heap environment (__rt_stack_heap()) and then initialize the library (__rt_lib_init()).

    - After __rt_entry is done your provided main() is called and your programm execution begins.

    As you can see, the ARM runtime environment is quiet flexible and allows you to provide your own methods for all these steps or avoid them at all.

    Frank

  • Frank,
    I only tried to THANK you!

  • why on earth would anyone want to "develop a C program without any runtime libarry"

    Erik

  • why on earth would anyone want to "develop a C program without any runtime libarry"

    If you don't know of a reason and you've never considered the need, then it's probably something you don't need to concern yourself with.

    I worked on a V55 project a few years ago and although I didn't totally exclude the runtime library, I had to make sure that absolute minimal use was made of it.

    With sufficient understanding of the tools being used (in my case Microsoft), it is a reasonably straightforward task - And there is the key; you must have sufficient understanding of the tools being used.

  • Jeff,
    Your comments were very correct. I just had a look at the "libraries and floating point support guide" for RVCT 3.1: Man, giving up the runtime library is a messy business unless you really know what your doing!

  • If you don't know of a reason and you've never considered the need, then it's probably something you don't need to concern yourself with.
    I, actually, can think of one psssible reason, and your answer does in no way relieve my curiousity. If i do not know the reason to take vitamins that does not mean that it would be worthless for me to know, I might start taking them.

    so once more WHY?

    Erik

  • Good morning Erik,

    the C run-time library is written by a third party. You don't know which SW development process was used, what are the requirements, how it was tested and what design principle are the base of this code.
    For safety critical applications you need to know the answers to these questions in detail. Further, the standard I/O system is normally based on dynamic memory allocation methods, which is very critical in software certification. Your testing of such code would be subtantial and it is easier to implement your own dedicated version of such code.
    Once you know how the run-time library works, it is relatively easy to develop your own dedicated version. The advantage is that you are in full control. To get there is a lot of work.

    Frank

  • Frank,

    That's a good eloquent description; and exceptionally close to my reasoning.

    I trust Erik's curiosity is now satisfied ;)

  • FD,

    But the compiler itself is written by a third party. Do you validate the compiler? If the libraries are written and/or validated by the compiler vendor as well as the compiler, then why not use the libraries too?

    Sauli

  • Hi Sauli,

    there is a distinct difference between using a compiler to generate code and using third party code in your final application.

    You are right, you have to setup a process to establish a certain degree of confidence into your development tools. At the same time you test the resulting code extensivly. You do unit testing, black-box testing, robustness testing, coverage testing and acceptance testing. Throughout all these tests you will catch problems introduced by your development tools.
    Important is that your compiler is not part of the final software!

    Third party code is part of your software. You do not have requirements for this code and therefore you don't know for what to test the code. If you test only for your purposes you miss big parts of this third party code and you would have a high degree of uncertainty in your software. By the way, it would be very hard to get 100% code coverage for the run-time library. For safety critical applications this is not acceptable.

    Frank

  • You make a good argument except:
    "the standard I/O system is normally based on dynamic memory allocation methods" That would depend on the compiler and the function. The 8051 does not.
    And with the full version you get the source. So you can verify if need be.