On Friday, 6 September 2013 at 14:09:15 UTC, Iain Buclaw wrote:
> On 6 September 2013 14:13, Dicebot <public@dicebot.lv> wrote:
>> On Friday, 6 September 2013 at 12:25:56 UTC, eles wrote:
>>>
>>> On Friday, 6 September 2013 at 10:43:38 UTC, Iain Buclaw wrote:
>>>>
>>>> On 6 September 2013 10:35, eles <eles@eles.com> wrote:
> And all I'm saying is that if you want to use it on bare metal then
> you have to strip out phobos and re-implement everything from
> druntime.

Yes, I know, the kernel provides an almost complete and fully from-scratch reimplementation of the C standard lib. It would be almost impossible to rely on the libc provided by GNU, as the latter... relies on the kernel.

While reimplementing the C standard lib is simpler than reimplemented Druntime/Phobos, it could be argued that writing code using the libraries should be easier when relying on Druntime/Phobos, so this could be acceptable.

Problem is that D is needing those libraries not only for functions, but also for functionalities (of the language itself).

In C, you can use the language without a library, and I mean any subset of the language (yes, that will be a bare does-nothing application, but you know what you can rely on and what not).

In D you cannot. You have to avoid features *of the language* relying on Druntime and, worse, it is not even clear or guaranteed which of them.

On Friday, 6 September 2013 at 14:10:06 UTC, Iain Buclaw wrote:
> On 6 September 2013 14:34, eles <eles@eles.com> wrote:
>> On Friday, 6 September 2013 at 10:43:38 UTC, Iain Buclaw wrote:
>>>
>>> On 6 September 2013 10:35, eles <eles@eles.com> wrote:
>>
>> *p=3;
>> a=*p;
>>
>
> 'p' should be marked as 'shared' in this instance.

That will help, but it completely misleads. First, is not just about the data being shared, but it is about the hardware side-effect. If writing 3 to the *p register makes your front-panel LED to light up, you need to rely on the fact that 3 is written (for real) at that address. And written when you ask it to be, not some 5 minutes later, because the compiler detected that no other thread accesses that variable, so decided to cache it. 5 minutes later the plane could be already landed. Without survivors.

"Shared" synchronizes within the D world. There is a world outside the D world, and I mean the hardware.

On Friday, 6 September 2013 at 14:09:15 UTC, Iain Buclaw wrote:
> And all I'm saying is that if you want to use it on bare metal then
> you have to strip out phobos and re-implement everything from
> druntime.

I am mostly aware of this and have studied Xomb sources and runtime reimplementation quite closely at some point. Main problem for me that amount of micro-management required for D (because of all language/runtime magic) is much more intensive than with C (just throw away libc and be careful with stack) - and that largely shadows the value of using D instead of C in the very first place.

Once you step into this domain, compiler becomes your enemy instead of your trusty friend and this is the most frustrating part. Adam Ruppe minimal.d module is a promising approach of a common starting point for own runtime implementation but I honestly think it is as much language issues as implementation issue.

eles, el  6 de September a las 16:20 me escribiste:
> On Friday, 6 September 2013 at 14:09:15 UTC, Iain Buclaw wrote:
> >On 6 September 2013 14:13, Dicebot <public@dicebot.lv> wrote:
> >>On Friday, 6 September 2013 at 12:25:56 UTC, eles wrote:
> >>>
> >>>On Friday, 6 September 2013 at 10:43:38 UTC, Iain Buclaw wrote:
> >>>>
> >>>>On 6 September 2013 10:35, eles <eles@eles.com> wrote:
> >And all I'm saying is that if you want to use it on bare metal
> >then
> >you have to strip out phobos and re-implement everything from
> >druntime.
> 
> Yes, I know, the kernel provides an almost complete and fully from-scratch reimplementation of the C standard lib. It would be almost impossible to rely on the libc provided by GNU, as the latter... relies on the kernel.
> 
> While reimplementing the C standard lib is simpler than reimplemented Druntime/Phobos, it could be argued that writing code using the libraries should be easier when relying on Druntime/Phobos, so this could be acceptable.
> 
> Problem is that D is needing those libraries not only for functions, but also for functionalities (of the language itself).
> 
> In C, you can use the language without a library, and I mean any subset of the language (yes, that will be a bare does-nothing application, but you know what you can rely on and what not).
> 
> In D you cannot. You have to avoid features *of the language* relying on Druntime and, worse, it is not even clear or guaranteed which of them.

LDC used to have a --no-runtime switch or something like that, that aborted compilation if a call to the runtime was emitted. I don't know if it still does, but that's extremely useful if you want to use the D subset that only generates assembly without calling to external functions. D runtime is mostly written in D, and for obvious reasons can't use those language constructions that uses the features you are implementing. So is possible (although extremely inconvenient right now).

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
FINALMENTE EL CABALLITO FABIAN VA A PASAR UNA BUENA NAVIDAD
	-- Crónica TV

On Friday, 6 September 2013 at 17:09:03 UTC, Leandro Lucarella wrote:
> eles, el  6 de September a las 16:20 me escribiste:
>> On Friday, 6 September 2013 at 14:09:15 UTC, Iain Buclaw wrote:
>> >On 6 September 2013 14:13, Dicebot <public@dicebot.lv> wrote:
>> >>On Friday, 6 September 2013 at 12:25:56 UTC, eles wrote:
>> >>>
>> >>>On Friday, 6 September 2013 at 10:43:38 UTC, Iain Buclaw
>> >>>wrote:
>> >>>>
>> >>>>On 6 September 2013 10:35, eles <eles@eles.com> wrote:
> LDC used to have a --no-runtime switch or something like that, that
> aborted compilation if a call to the runtime was emitted. I

That's good, but is rather a workaround for a limitation of the language. Is D the first language with a compiler unable to compile its own standard library? There is no guarantee in the language that one day even the most innocent operation in the language won't require the standard library and what compiles with "--no-runtime" today might as well not compile tomorrow.

In C or C++, while the standard library is part of the language standard, is not part of the language per sé. It is not part of the compiler, after all. It is provided with.

> don't know
> if it still does, but that's extremely useful if you want to use the
> D subset that only generates assembly without calling to external
> functions. D runtime is mostly written in D, and for obvious reasons
> can't use those language constructions that uses the features you are
> implementing. So is possible (although extremely inconvenient right
> now).

This will likely be the most limiting issue for the embedded world.

On 2013-09-06 11:35, eles wrote:
> I am starting a new thread, since I am afraid that the other one will
> become too cluttered with issues...
>
> It is about this OS kernel:
>
> http://wiki.osdev.org/D_Bare_Bones
>
> I tried to duplicate the steps. However, on my x86_64 machine, the
> actual commands that I had to use are:

This might be a useful link:

http://3d.benjamin-thaut.de/?p=20

It's a blog post that contains links to a druntime and Phobos fork that doesn't use the GC.

-- 
/Jacob Carlborg

OK, OK, completely overblown but for the sake of the point: Well,
if you bend and strip down Clarion or php far enough, you might use it for
a kernel, too.

Frankly, when hacking the kernel you use C, period. There are
alternatives, Ada for instance but they have a price tag too. And
D, with all the warm feelings we might have for it, is not one of
those alternatives.

I wouldn't say D is intentionally "marketed" so as to make
people think D can be - reasonably - used where it can not, at
least not reasonably. But it's at least, let's say, selling
itself in a way that invites people to wrong conclusions.

This is not even so much a moral issue but a rather practical
one. I understand that dicebot and some others are enjoying
experimenting around the periphery of D-land and that's perfectly
OK; they are quite grown up experienced guys who, so it seems,
make their experiments for hacking and learning purposes.

eles on the other hand seems to have walked into a comittment (trying to avoid the term "trap") by believing that systems programming, "very C like", "doing right what C++ was meant to achieve" and the like can actually deliver
on the promises. Now, Pardon me talking straight, he is in danger
of looking like a fool to his peers - and D is in danger to look
like a bragging fullmouth that just can't deliver.
Because it allowed itself to sound like promising what it can not.

Let's be honest. D, as Iain correctly indicated, is a userland language
that has strengths in userland systems programming and offers
high efficieny, even some comfort and other goodies without
keeping the programmer away from the lower levels incl. (more or
less) direct access to C code.

That's a lot. That's great stuff. Kudos. *And that's damn enough
and good enough to afford honesty*, the honesty, for instance, to
say "D is not for kernels or for MCUs (other than fat arms etc),
period. As for stdlib/clib like stuff it's on its way but far
from having arrived".

A propos "on the way". Maybe we should concentrate more efforts
on reliability (as in "private" and "public" being properly
implemented and respected) and on really making phobos into a
properly designed and structured library.

If one convinces 1 person that something is good he might bring 3
others. If one allows 1 person to feel left alone or betrayed or
reasonably disappointed 30 other will be driven away.

There is good reason I respect and praise Iain. He delivered.

After days of frustration and being laughed at or even being attacked
I'm humming away productively since I switched to GDC. This, too,
didn't come for free; it like so many things D-related took some
efforts but it definitely was worth it.

A+ -R

On Friday, 6 September 2013 at 19:24:22 UTC, Ramon wrote:
> Let's be honest. D, as Iain correctly indicated, is a userland language

Unfortunately, in this case, it brings to my actual workplace nothing more than does C#. And we already use the latter for GUI and so on. When really needed some pointer action, a bit of C will ensure that just fine: after all, grunt pointer work in code is less than 5% (don't count for that abstractions as arrays, as the latter are provided by C# and co.).

And you know C quite well, because, surprise, you are using it a lot for the kernel programming.

It was a time when Walter answered to some post telling that there are no OSs written with garbage collectors someting like: "maybe it should". Understanding that this will also mean better safety, as less memory leaks and so on.

Well, it seems that you could have an almost OS: the GNU without the Linux. And that OS will be something like D/C, just as today we have GNU/Linux. C standing for the kernel...

> There is good reason I respect and praise Iain. He delivered.

I concur.

> After days of frustration and being laughed at or even being attacked
> I'm humming away productively since I switched to GDC.

I wish I could say the same.

eles

Risking to find myself in hot water ...

I think that gc is grossly overestimated and it's too often painted in promised land colours. For one, there are, of course, trade offs; sometimes gc's advantages outweigh the disadvantages, sometimes not and close to hardware basically hardly ever.
Second, the problems to be solved by gc are equally overestimated, too. Looking back at many, many years of using C, memory management was basically never among the top trouble sources.

I don't know your situation in any detail but when doing work with MCUs (as in 8051, 68K, coldfire, mpc430, not as in Arm Cortex) I wouldn't even consider D.

D provides for interfacing C to quite some extent and I see that as extremely desirable and very much related (looking pragmatically) to D being C-like (unlike, say, Ada, which also provides quite nicely for interfacing C). I find that attractive for a simple reason; I don't need to switch my mindset and habits too much and can comfortably afford to follow the old and wise saying "Use the right tool for any job". Kernel, drivers etc -> C, userland system stuff, low level app stuff -> D, higher level stuff -> D with objects.
Yowsa, that's what I looked for.

If I were to criticize D then mainly for 2 points:
- It's following C's mindset too much on one hand and too little on the other hand. It seems visible to me that WB was driven by an itch and not so much by a vision (this is meant neither negatively nor positively; it's simply my impression and "driven by vision" doesn't necessarily lead to better results).
- It's not as consistent as I'd like it to be. phobos seems, uhm, worthy a discussion e.g. concerning at least its design (e.g. layers, OS interface), safety has been a concern but might have profitted by learning more from other languages, etc. Similarly there are bits all over the place but very little consistently implemented. That's another example why I value Iains work so emminently; he has brought us a complete and (at least principally) portable toolchain incl. debugging which is a conditio sine qua non.
As one example that relates to your situation, it might have been wiser to say "Our lower boundary is close to hardware or OS core stuff; we don't do that, that's were we cut off. But we provide a well designed interface to the tools of the plumbing trade, namely C and stdlib" rather than playing with the idea of (low level) system programming and not implementing it consistently.

But for fairness sake: Little (besides phobos, which *can* be improved) is in the way of doing it right, i.e. plumbing in C and anything higher up in D.

In case kernel and close to the metal jobs isn't the major part of your job it might be attractive to look at the C/D combo.

A+ -R

On Friday, 6 September 2013 at 19:24:22 UTC, Ramon wrote:
> Frankly, when hacking the kernel you use C, period. There are
> alternatives, Ada for instance but they have a price tag too. And
> D, with all the warm feelings we might have for it, is not one of
> those alternatives.

Lot of confusion comes from some earlier times when D was implicitly advertised as systems programming language. It simply gave too much hope - one needs to be get engaged deep into kernel/embedded industry to understand how freaking fed up some programmers are from C in that domain. Thus all the frustration - one sees the possibility of final salvation from 60 year old tool stack only to find out that it in practice competes in C# domain.

Which is pretty bold move because it has completely missed possible niche with zero alternatives and thus competence.

Eventually I got used to it and currently only try to make some buzz so that situation won't get even worse - but consequences of false advertising still roam across the internet.