www.digitalmars.com         C & C++   DMDScript  

D.gnu - -ffreestanding option

reply "Mike" <none none.com> writes:
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
May 05 2015
parent reply Johannes Pfau <nospam example.com> writes:
Am Tue, 05 May 2015 11:37:17 +0000
schrieb "Mike" <none 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.
=20
 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 =46rom 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 =3D false;
=20
 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.
=20
 Thanks for the continued support,
=20
 Mike
May 05 2015
parent "Jens Bauer" <doctor who.no> writes:
On Tuesday, 5 May 2015 at 17:51:51 UTC, Johannes Pfau wrote:
 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.
This is definitely a good move. :) I'm not yet ready to look at RTTI; I've not gotten through level 2 of this game yet. The next D-related thing I will look at, is trying to write an example hardware support file (or module). Nothing final, it's just to get an idea on how it can be done. But before that, I'll need to have a look at creating a new Makefile and possibly the linker-scripts.
May 06 2015