Concept: druntime getting rid of libc dependency

[denizzzka]

The names of the members of the Mem structure are deliberately chosen so as not to appear to be names functions of one well-known OS or library.

Actually I make names and locations without much thought - please suggest better choices!

upd: maybe, rt.backend?

upd2: together with the core.thread.*_impl modules and some similar changes in core.sync.* (not implemented for now, but it is not so difficult) this approach provides interface to easy porting druntime to any system

[QuantumSegfault]

When I was considering the same, I found that printf was one of the more annoying ones. Though USUALLY the format strings are pretty simple, and the subset used could probably be implemented fairly easily. Or we could replace the format strings with something else. We have IES now...?

parseoptions is all sorts of annoying. We'd need a custom float parser to replace sscanf.

[denizzzka]

@QuantumSegfault

parseoptions is all sorts of annoying. We'd need a custom float parser to replace sscanf.

If we are talking about CLI options for setting up the GC, then in my practice, completely replacing the parser with something of my own (hardcoded values, for example :-)) has worked well. You can take your own Config struct with your own default values ​​and your own initializer.

We must keep in mind that the command line from which the options are taken is an optional thing. So I think this can be solved like this: f20ede3

[Herringway]

I do like the idea of this. It could make porting the runtime to new platforms much easier.

The lack of feedback from the core team has me quite concerned for this PR's future, though...

[github-actions]

DMD perf check

Metric	Base	PR	delta
compile hello.d (instr)	215.9 M	215.9 M	0.00%
compile hello.d -O (instr)	234.5 M	234.5 M	0.00%
compile Phobos (instr)	5,078.8 M	5,077.1 M	-0.03%
compile Phobos codegen (instr)	1,454.8 M	1,453.1 M	-0.12%
compile vibe.d (instr)	15,136.5 M	15,136.9 M	0.00%
dmd binary size (stripped)	6.92 MB	6.92 MB	0.00%
hello binary size	0.72 MB	0.72 MB	+0.01%
peak RSS (compile hello.d)	44 MB	44 MB	-0.21%
peak RSS (compile Phobos)	632 MB	633 MB	+0.05%
peak RSS (compile vibe.d)	1982 MB	1981 MB	-0.06%

[denizzzka]

@Herringway Thank you very much!

[QuantumSegfault]

@QuantumSegfault

parseoptions is all sorts of annoying. We'd need a custom float parser to replace sscanf.

If we are talking about CLI options for setting up the GC, then in my practice, completely replacing the parser with something of my own (hardcoded values, for example :-)) has worked well. You can take your own Config struct with your own default values ​​and your own initializer.

We must keep in mind that the command line from which the options are taken is an optional thing. So I think this can be solved like this: f20ede3

Well, right now I'm not aware of any easy way to opt-out of being able to configure the runtime...at runtime (via ENV or cli args). Even configuring at compile time with rt_options brings in string handling.

It'd be nice if there was an easy way to version all of that out, AND to configure the various config in a structured manner at compile time.

[QuantumSegfault]

Is this being kept long term (i.e. will freestanding platforms have to write their own printf)?

[denizzzka]

Yes.
In fact, I've almost written started to write a simple replacement. It's will be enough for tasks not related to hardcore druntime debugging at first time

I plan to add it to debug builds so that when testing I can make sure it responds similarly as current libc versions

[denizzzka]

@QuantumSegfault

Well, right now I'm not aware of any easy way to opt-out of being able to configure the runtime...at runtime (via ENV or cli args). Even configuring at compile time with rt_options brings in string handling.

1. On systems where this is needed, some string processing is usually already available
2. We should be able to write our own processing if it is not provided
3. Not all software need this. (I'm sure most computer systems in the World never use it - default values ​​or hardcode is enough)

It'd be nice if there was an easy way to version all of that out, AND to configure the various config in a structured manner at compile time.

That's what will happen. But we don't need to do it right away. It is just need to give anyone opportunity to do it if necessary.

[denizzzka]

We have IES now...?

Good point!

We can try to substitute Sys.printf() to the something another when this PR is accepted (changes need to be small, otherwise this huge patch won't be reviewable)

[xoxorwr]

Great project! However, regarding memory handling, it makes the same mistake by using a global allocator.

While I understand this is a huge undertaking, finalizing the custom allocator API would be a better first step imo, that would allow the runtime to benefit from it right away, making APIs much nicer to use and to port.

[denizzzka]

@xoxorwr thank you for support!

But I'm completely against the approach you're proposing: doing it right the first time is difficult.
I think that's why we've been stuck with lack of supporting various systems/OSes for about ~10 years.

Thus, in my opinion, it is much better to first take out and "contour" memory dealing in the same format in which libc offers it (i.e. using malloc, free & Co)

Then, as the second stage, we can try to implement something lower-level (or highter-level?) using knowledges about one or two well-known OSes, then it will become clear what API we want.

This is, of course, if I understood your proposal correctly.

upd:

would be a better first step imo

There's another reason I'm doing it by this way: I have successfully tested this approach on my own druntime branch