-ffreestanding option

[Zheng Luo (Vic)]

On Tuesday, 5 May 2015 at 17:51:51 UTC, Johannes Pfau wrote:
> Am Tue, 05 May 2015 11:37:17 +0000
> schrieb "Mike" <none at none.com>:
>
>> 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.
>
> Isn't this simply two ways of looking at the same thing? You 
> want to disable language features (I guess mostly those 
> requiring runtime hooks), -ffreestanding disables all these 
> features.
>
> I realize you want fine-grained control. But then:
>
> -ffreestanding:
>    -fno-exceptions
>    -fno-rtti
>    -fno-gc
>    -fno-invariants
>    -fno-moduleinfo
>    -fno-string-switch
>    -fno-utf-support (foreach over utf strings)
>    -fno-boundscheck
>    -fno-switch-error
>
> From an implementation point of view these are the same and 
> fine-grained switches are easy to support.
>
> Access using .di is then simple to add as well. If the compiler 
> is clever it can look if the required features/hooks are 
> implemented. This requires some compiler work. Simpler 
> alternative: Enum values in special d module (e.g. rt.config) 
> enum RUNTIME_SUPPORTS_GC = false;
>
>> 
>> 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'll implement fno-rtti next weekend. We can think about more 
> fine-grained solutions in the future but fno-rtti should be a 
> good start.
>
>> 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

Current implementation of compilers assumes the existence of some 
symbols from libc, which leads to an infinite loop if we want to 
implement primitives like "memset" with our own code because the 
compiler will optimize consecutive set with "memset". This 
suggests that we cannot write a freestanding program without 
supports from compiler. With "-betterC" flag, dmd/gdc/ldc also 
come into this issue[5], which also applies to C/C++[1] and rust 
[2][3][4].

It would be better to provide a standard flag like 
"-ffreestanding" (or -fno-builtin?) to disable such optimizations 
to facilitate freestanding programming instead of forcing the 
developers to hack around different compiler implementations, so 
I was wondering is there any progress on this problem?

[1] https://godbolt.org/g/5gVWeN
[2] 
https://play.rust-lang.org/?gist=64f2acafa8cec112893633a5f2e12a9a&version=stable&mode=release&edition=2015
[3] https://github.com/rust-lang/rust/issues/10116
[4] https://github.com/thestinger/rust-core#freestanding
[5] https://run.dlang.io/is/nnKWnZ