Iain recently asked me to let him know what might be needed for a -ffreestanding implementation in GDC. I couldn't really give a good answer, so I tried to spend some more time thinking "What does freestanding mean in D?"
It is my understanding that the -ffreestanding switch in C prevents the compiler from generating any calls to built-ins and requires only a small subset of the C standard library (https://gcc.gnu.org/onlinedocs/gcc/Standards.html). In my C/C++ embedded work, I actually don't compile with the -ffreestanding switch even though I'm building right on the metal. Rather, I create a startup file that initializes the hardware and calls main. If the compiler generates any calls to built-ins, I implement them. Typically, I need built-ins like memcpy and memset for my startup file anyway. Compiling with -ffunction-sections, -fdata-sections, and linking with --gc-sections seems to get rid of any built-ins that my code is not using. It makes me wonder, though, "What would the compiler generate for copying or comparing structs if it couldn't generate those built-ins?" In my D work, I don't have much need for the C standard library. I typically only need a few functions from it, and they are easy enough to implement in D. So, perhaps in my ignorance, I have to say that I don't need a -ffreestanding option, but I don't consider myself much of an expert in this field. If you know of a need for the -ffreestanding option, please let it be known. What I really need is more granular control of the language features, either by adding compiler switches, or delegating implementation to the runtime. My dream would be to have runtime .di files inform the compiler what the language features look like, and have the compiler use that information to generate optimized code or compiler errors if the runtime doesn't provide what everything compiler needs. At the moment, the most pressing issue for me is the phony support I have to add for TypeInfo and the removal of dead code (or lack there of) due to GCC bug 192. Some binaries I've created are so full of TypeInfo stuff that I can't even get them to fit in my MCU's flash memory for testing and debugging. Not to mention the added upload time it takes, diminishing the efficiency of my development cycle. I remember from previous discussions that there was work to be done in binutils to get better LTO and dead-code removal. I'd be interested in hearing more details about that too. Thanks for the continued support, Mike
