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
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
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?
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,
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.
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.
what I was thinking about was a bootloader that was written as part of the code, but would run when the 'actual' code was erased. of course, there you would be up the proverbial creek if a runtime libary (over which you have no control) was used by the bootloader and linked in the area you erase.