Hi,

When writing compiler tools, a GC seems desirable as managing memory for the data structures used by compilers is a pain. I guess the better C option has no runtime, whereas normal D has the runtime with GC. I was wondering whether the runtime can be minimized to only support the GC. Or is that already the case, i.e. the D runtime is already the minimum needed for GC?

Thanks and Regards
Dibyendu

On Monday, 15 June 2020 at 08:54:45 UTC, Dibyendu Majumdar wrote:
> When writing compiler tools, a GC seems desirable as managing memory for the data structures used by compilers is a pain. I guess the better C option has no runtime, whereas normal D has the runtime with GC. I was wondering whether the runtime can be minimized to only support the GC. Or is that already the case, i.e. the D runtime is already the minimum needed for GC?
>

Just to clarify the context - the compiler needs to be built as a library that can be used in any project.

On Monday, 15 June 2020 at 08:54:45 UTC, Dibyendu Majumdar wrote:
> Hi,
>
> When writing compiler tools, a GC seems desirable as managing memory for the data structures used by compilers is a pain. I guess the better C option has no runtime, whereas normal D has the runtime with GC. I was wondering whether the runtime can be minimized to only support the GC. Or is that already the case, i.e. the D runtime is already the minimum needed for GC?
>
> Thanks and Regards
> Dibyendu

C does almost require a standard library which is clib. You can't do memcpy or memset without clib so C becomes kind of dependable on clib. However, you can use C without clib as well and D can that too with the -betterC switch.

I'm looking for a minimal druntime too. Right now it is all or nothing for druntime and it expect a full rich OS. There have been talks to partion druntime better so that you can incremental support, for example leave networking out if you want to. Also right now for all operating systems, druntime depends on clib itself. Nim has a compiler switch -os:any which means that the runtime will only depend on clib which makes it very portable. That would have been nice in druntime too.

On 6/15/2020 3:01 AM, IGotD- wrote:
> I'm looking for a minimal druntime too. Right now it is all or nothing for druntime and it expect a full rich OS. There have been talks to partion druntime better so that you can incremental support, for example leave networking out if you want to. Also right now for all operating systems, druntime depends on clib itself. Nim has a compiler switch -os:any which means that the runtime will only depend on clib which makes it very portable. That would have been nice in druntime too.

Since druntime is a library, only the functions actually referenced are pulled out of the library when linking.

On Monday, 15 June 2020 at 10:07:10 UTC, Walter Bright wrote:
>
> Since druntime is a library, only the functions actually referenced are pulled out of the library when linking.

Still you need to compile druntime and if it finds any missing symbol there, the build will fail. Also the in druntime files often include other files in druntime which doesn't make it that easy.

As we have discussed before, the best way for this in my opinion is to have an abstract interface in druntime for the OS functions. This way we could stub those functions that the programmer doesn't need.

On Monday, 15 June 2020 at 08:54:45 UTC, Dibyendu Majumdar wrote:
> I was wondering whether the runtime can be minimized to only support the GC. Or is that already the case, i.e. the D runtime is already the minimum needed for GC?

Eh, a good bulk of the d runtime is GC support, it would be hard to pull the gc out without most the rest of it.

In general, if you create a file called "object.d" in your work directory and compile it in, you can override druntime to nothing and build it back up from there just... that's a pain to get from nothing back up to GC point.

On Monday, 15 June 2020 at 12:21:08 UTC, Adam D. Ruppe wrote:
>
> Eh, a good bulk of the d runtime is GC support, it would be hard to pull the gc out without most the rest of it.
>

I think he means the opposite, remove everything but GC. You bascially need GC in order to get the benefits of D but you don't necessarily need everything else.

On Monday, 15 June 2020 at 16:45:21 UTC, IGotD- wrote:
> I think he means the opposite, remove everything but GC.

That's exactly what I meant... just I awkwardly worded it. I meant pull the GC out of full druntime and drop it into your minimal runtime so you have just it without the other stuff.

> You bascially need GC in order to get the benefits of D but you don't necessarily need everything else.

eh GC is a big win with D, but you can get lots of D benefits without it too.

On 6/15/2020 3:16 AM, IGotD- wrote:
> As we have discussed before, the best way for this in my opinion is to have an abstract interface in druntime for the OS functions. This way we could stub those functions that the programmer doesn't need.

If you include the line:

   extern (C) void printf() { }

somewhere in your code, printf() will *not* get linked in.

An extra interface layer is not necessary.

On 6/15/20 6:01 AM, IGotD- wrote:
> I'm looking for a minimal druntime too. Right now it is all or nothing for druntime and it expect a full rich OS. There have been talks to partion druntime better so that you can incremental support, for example leave networking out if you want to. Also right now for all operating systems, druntime depends on clib itself. Nim has a compiler switch -os:any which means that the runtime will only depend on clib which makes it very portable. That would have been nice in druntime too.

We really need to merge druntime and phobos in one. The entire distinction has long become nonsensical.

The new merged library ("hall" in honor of Asaph Hall who discovered Phobos and Deimos) would be built under a strict pay-as-you-go regime. That means an empty main uses virtually nothing, a main with a writeln() uses a little I/O, a main that allocates memory brings the GC in play (which auto-initializes on the first call), etc.

Templates and deduction must be heavily favored over old crummy C bindings. E.g. writeln() should actually link little else than a call to the fwrite() function.

We'd need at least 2 solid engineers for that.