Thread overview
D with no druntime
Aug 21, 2014
uri
Aug 21, 2014
maarten van damme
Aug 22, 2014
Kagamin
Aug 22, 2014
Marc Schütz
Aug 22, 2014
bearophile
August 21, 2014
Hi All,

I am playing with a small hack OS for fun and in 2066 there are these undefined refs (I have no druntime):

_d_arraybounds (new to 2066)
_d_assert (new to 2066)
_d_unittest (new to 2066)
_Dmodule_ref (also in 2065)
_d_dso_registry (also in 2065)

It is trivial to stub these out but it got me wondering...

Is there any way to compile D that has no dependencies?


Thanks,
uri



August 21, 2014
There were 2 talks about bare metal D this year at the D conference.

The first one is about someone able to use D on microcontrollers with a few
k ram.:
https://www.youtube.com/watch?v=o5m0m_ZG9e8

The second one is about someone trying to strip almost everything out and
see what works:
https://www.youtube.com/watch?v=qErXPomAWYI

They both go through the process of striping down the runtime and showing what works.


2014-08-21 7:13 GMT+02:00 uri via Digitalmars-d-learn < digitalmars-d-learn@puremagic.com>:

> Hi All,
>
> I am playing with a small hack OS for fun and in 2066 there are these undefined refs (I have no druntime):
>
> _d_arraybounds (new to 2066)
> _d_assert (new to 2066)
> _d_unittest (new to 2066)
> _Dmodule_ref (also in 2065)
> _d_dso_registry (also in 2065)
>
> It is trivial to stub these out but it got me wondering...
>
> Is there any way to compile D that has no dependencies?
>
>
> Thanks,
> uri
>
>
>
>


August 22, 2014
On Thursday, 21 August 2014 at 05:13:34 UTC, uri wrote:
> _d_arraybounds (new to 2066)

This one is very useful, I recommend to implement it. It's just easier to live with it, than try to get rid of it.
August 22, 2014
On Friday, 22 August 2014 at 17:52:30 UTC, Kagamin wrote:
> On Thursday, 21 August 2014 at 05:13:34 UTC, uri wrote:
>> _d_arraybounds (new to 2066)
>
> This one is very useful, I recommend to implement it. It's just easier to live with it, than try to get rid of it.

But it would need to halt the system of course, because throwing a RangeError might not work in his minimalistic environment.
August 22, 2014
Marc Schütz:

> But it would need to halt the system of course, because throwing a RangeError might not work in his minimalistic environment.

Halting the system, or jumping to a error routine seems better than running in undefined state.

Bye,
bearophile