www.digitalmars.com         C & C++   DMDScript  

D.gnu - d bare bones

reply "eles" <eles eles.com> writes:
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:

$nasm -f elf -o start.o start.asm
$gdc -m32 -nostdlib -nodefaultlibs -g -c -o kernel.main.o 
kernel.main.d
$LDEMULATION="elf_i386" ld -T linker.ld -o kernel.bin start.o 
kernel.main.o

(in order to emulate the 32-bits architecture).

The first command went just fine, the second command emitted 
warnings:

kernel.main.d:13: Deprecation: volatile statements deprecated; 
use synchronized statements instead
kernel.main.d:16: Deprecation: volatile statements deprecated; 
use synchronized statements instead
kernel.main.d:18: Deprecation: volatile statements deprecated; 
use synchronized statements instead

while the third one was merciless:

kernel.main.o: In function `main':
/home/user/bootloader/kernel.main.d:12: undefined reference to 
`_d_criticalenter'
/home/user/bootloader/kernel.main.d:12: undefined reference to 
`_d_criticalexit'
/home/user/bootloader/kernel.main.d:15: undefined reference to 
`_d_criticalenter'
/home/user/bootloader/kernel.main.d:15: undefined reference to 
`_d_criticalexit'
/home/user/bootloader/kernel.main.d:16: undefined reference to 
`_d_criticalenter'
/home/user/bootloader/kernel.main.d:16: undefined reference to 
`_d_criticalexit'
kernel.main.o: In function 
`kernel.main._D6kernel4main9__modinitFZv':
/home/user/bootloader/kernel.main.d:18: undefined reference to 
`_Dmodule_ref'
/home/user/bootloader/kernel.main.d:18: undefined reference to 
`_Dmodule_ref'

Any clues? It is because of the deprecated volatile statements?
Sep 06 2013
next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 6 September 2013 10:35, eles <eles eles.com> 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:

 $nasm -f elf -o start.o start.asm
 $gdc -m32 -nostdlib -nodefaultlibs -g -c -o kernel.main.o kernel.main.d
 $LDEMULATION="elf_i386" ld -T linker.ld -o kernel.bin start.o kernel.main.o

 (in order to emulate the 32-bits architecture).

 The first command went just fine, the second command emitted warnings:

 kernel.main.d:13: Deprecation: volatile statements deprecated; use
 synchronized statements instead
 kernel.main.d:16: Deprecation: volatile statements deprecated; use
 synchronized statements instead
 kernel.main.d:18: Deprecation: volatile statements deprecated; use
 synchronized statements instead

 while the third one was merciless:

 kernel.main.o: In function `main':
 /home/user/bootloader/kernel.main.d:12: undefined reference to
 `_d_criticalenter'
 /home/user/bootloader/kernel.main.d:12: undefined reference to
 `_d_criticalexit'
 /home/user/bootloader/kernel.main.d:15: undefined reference to
 `_d_criticalenter'
 /home/user/bootloader/kernel.main.d:15: undefined reference to
 `_d_criticalexit'
 /home/user/bootloader/kernel.main.d:16: undefined reference to
 `_d_criticalenter'
 /home/user/bootloader/kernel.main.d:16: undefined reference to
 `_d_criticalexit'
 kernel.main.o: In function `kernel.main._D6kernel4main9__modinitFZv':
 /home/user/bootloader/kernel.main.d:18: undefined reference to
 `_Dmodule_ref'
 /home/user/bootloader/kernel.main.d:18: undefined reference to
 `_Dmodule_ref'

 Any clues? It is because of the deprecated volatile statements?

Yep - this is probably the big problem with deprecating volatile statements (actually, volatile is no longer in the compiler). You are removing a low level feature and forcing users to use a high level user-land feature instead. The key thing you must know if you intend to do some low level pokery is that you must ditch druntime and phobos and re-implement druntime from scratch in the most minimalistic way possible (and so that it doesn't depend on libc). There is a minimal druntime kicking about I think that an exokernel written in D1 uses... you could perhaps recycle that. Back to volatile.... the only (faintly close) alternative is 'shared'. But there's no equivalent to volatile statements other than implementing your own low level thread library for use in kernel-land to allow synchronized to work properly. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Sep 06 2013
prev sibling next sibling parent reply "eles" <eles eles.com> writes:
On Friday, 6 September 2013 at 10:43:38 UTC, Iain Buclaw wrote:
 On 6 September 2013 10:35, eles <eles eles.com> wrote:
   But there's no equivalent to volatile statements other than
 implementing your own low level thread library for use in 
 kernel-land
 to allow synchronized to work properly.

Frankly, but each day D becomes better, it becomes worse for systems programming. I'll have more&more difficulties to defend it as an acceptable solution at my workplace. I am sorry about that, but I cannot do much about it... :(
Sep 06 2013
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Sep 07, 2013 at 08:37:02AM +0200, Ramon wrote:
 On Saturday, 7 September 2013 at 05:35:04 UTC, H. S. Teoh wrote:
I find that it's much more convincing for me to say "feature X is
broken, here's the code change to make it better", than to say
"feature X is broken, D sucks, you lazy bums better start working to
fix X or else I'm leaving".  It feels good to rant and get it off my
chest, but it feels even better to have my changes merged and feature
X to get fixed because of me.

My intention was and is not ranting, nor saying D sucks, nor asking other to do work nor threatening. And this can found proven in what I wrote.

I did not intend to imply that you were ranting. I was only speaking generally. [...]
 Neither is there a need to decide; the options are not mutually
 exclusive. As a seasoned programmer that I take you to be you
 certainly can agree that leaning back and looking, incl. looking
 critically at was has been done so far not only is not harmful
 but it actually is positive and often even necessary. And you
 will quite certainly also degree that a non trivial project will
 need some planning and management.

What I said doesn't preclude that. All I'm saying is, *after* you stand back and look at what's there and find it unsatisfactory, you can write some code and then show it to others and say, "The current way we do X is unsatisfactory; here is my code to prove this (or better yet, here's my code to do it a better way)."
 Unlike what you seem to think, my point isn't hitting on D
 (actually that's obviously nonsensical as I wrote just yesterday
 or today that meanwhile I'm happily humming along with D).

I never implied that you were hitting on D. As you said yourself, that's nonsensical.
 But neither can it be a healthy attitude to ignore less pleasant
 things or events. We should ask what's behind it and what we can
 make better.

Well yes, what I was saying was just to take it one step further: once you identify the problem, write the code to improve it and show that to others. I don't think that kind of proposal will be easily turned down. T -- The fact that anyone still uses AOL shows that even the presence of options doesn't stop some people from picking the pessimal one. - Mike Ellis
Sep 07 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 6 September 2013 13:25, 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:
   But there's no equivalent to volatile statements other than
 implementing your own low level thread library for use in kernel-land
 to allow synchronized to work properly.

Frankly, but each day D becomes better, it becomes worse for systems programming. I'll have more&more difficulties to defend it as an acceptable solution at my workplace. I am sorry about that, but I cannot do much about it... :(

It's still systems level, just in user-land applications. It has always been the case that if you want to enter kernel-space with D, you have to drop phobos and implement a more low level druntime. For instance, the GC that comes with D is wholly infeasible for use inside a kernel . -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Sep 06 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
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:
  But there's no equivalent to volatile statements other than
 implementing your own low level thread library for use in 
 kernel-land
 to allow synchronized to work properly.

Frankly, but each day D becomes better, it becomes worse for systems programming. I'll have more&more difficulties to defend it as an acceptable solution at my workplace. I am sorry about that, but I cannot do much about it... :(

Yes, I feel quite the same way and I have almost abandoned any hopes to use it in C domain. Currently D is more like native faster C# - still pretty cool in lot of applications but definitely not the breakthrough.
Sep 06 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
On Friday, 6 September 2013 at 10:43:38 UTC, Iain Buclaw wrote:
 On 6 September 2013 10:35, eles <eles eles.com> wrote:
 Back to volatile.... the only (faintly close) alternative is 
 'shared'.

After some thinking, it wasn't about synchronization between threads as the error message was misleading. Was not about volatile statements, but about the POD volatile variables as in C, marked like that for the compiler to never optimize away their effect. That is, whenever you write: *p=3; a=*p; it should not blindly assume that a=3, since p could be the address of some hardware register, with continuously changing (ie: volatile) content. Besides, writing and reading to hardware registers (mapped address) has a side effect (a hardware one). So, as a workaround, I dropped the volatile keyword in front of my variables and imposed the -O0 flag on the compiler, to avoid any optimization. I still find myself facing those error: undefined reference to `_Dmodule_ref' (actually, the error message is printed *twice*, but *for the same line*). Any clues?
Sep 06 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Friday, 6 September 2013 at 13:34:33 UTC, eles wrote:
 Any clues?

I think you need own light-weight runtime stubs linked with the binary. Adam has done some nice experiments in that direction : http://arsdnet.net/dcode/minimal.zip
Sep 06 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
On Friday, 6 September 2013 at 13:47:47 UTC, Dicebot wrote:
 I think you need own light-weight runtime stubs linked with the 
 binary. Adam has done some nice experiments in that direction : 
 http://arsdnet.net/dcode/minimal.zip

Thank you, you are kind, I hope to have an working example. But, with such state of facts, it will never ever never ever be accepted at my workplace. My feeling is that is a language running forward so fast that tools and improvements will never catch up with it. Nor will real use... That's its bad. My boss might not be joking when he says that using Java would be simpler.
Sep 06 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
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:
  But there's no equivalent to volatile statements other than
 implementing your own low level thread library for use in kernel-land
 to allow synchronized to work properly.

Frankly, but each day D becomes better, it becomes worse for systems programming. I'll have more&more difficulties to defend it as an acceptable solution at my workplace. I am sorry about that, but I cannot do much about it... :(

Yes, I feel quite the same way and I have almost abandoned any hopes to use it in C domain. Currently D is more like native faster C# - still pretty cool in lot of applications but definitely not the breakthrough.

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. - In a kernel, you don't have the liberty of using malloc, realloc, free, or any other libc functions. So these allocation routines that are a part of the GC need to be re-written for use in the kernel. - The GC that comes with D itself is a bit too heavy for use in a kernel -> re-write. - pthread library is also out -> write your own lock system specific for use in the kernel. - Using exceptions in a kernel? You are having a laugh... - The D compiler may generate calls to libc functions, such as memcmp or fmod or pow -> avoid these like the plague. (Actually this isn't necessary a bad thing to note upon, as eg: gcc could do the same thing also, and so Linux devs tend to write in a very peculiar way because of this anyway). But lets try to be positive. How would I pragmatically approach this? Well, we are going to have to build a runtime from ground up either way you look at it. 1) Minimal D runtime. Only recent example I can think of is here: http://arsdnet.net/dcode/minimal.zip Though this is for DMD only. Older examples of a minimal D runtime are for D1. https://github.com/xomboverlord/xomb/tree/unborn/runtimes Ideally you'd want to try and marriage the two together. 2) GDC-specific modules. Only set of modules you need to worry about are the EH modules (unwind.d). These are based off of libstdc++ EH functions, there is a minimal C++ runtime here which is available here: https://github.com/pathscale/libcxxrt/tree/master/src Simply convert the EH routines over to D as required. 3) Entrypoint functions. See Xomb link above for assembly files, etc. 4) glibc/pthread Write your own replacements. See for example how Linux does this (kmalloc/kfree, etc). Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Sep 06 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
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:
 Back to volatile.... the only (faintly close) alternative is 'shared'.

After some thinking, it wasn't about synchronization between threads as the error message was misleading. Was not about volatile statements, but about the POD volatile variables as in C, marked like that for the compiler to never optimize away their effect. That is, whenever you write: *p=3; a=*p;

'p' should be marked as 'shared' in this instance. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Sep 06 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
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:



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.
Sep 06 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
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.
Sep 06 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
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.
Sep 06 2013
prev sibling next sibling parent Leandro Lucarella <luca llucax.com.ar> writes:
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:



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
Sep 06 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
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:





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.
Sep 06 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
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
Sep 06 2013
prev sibling next sibling parent "Ramon" <spam thanks.no> writes:
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
Sep 06 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
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.
Sep 06 2013
prev sibling next sibling parent "Ramon" <spam thanks.no> writes:
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
Sep 06 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
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.
Sep 06 2013
prev sibling next sibling parent "Ramon" <spam thanks.no> writes:
On Saturday, 7 September 2013 at 00:05:08 UTC, Dicebot wrote:
 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.

I tried to stay positive but you are right. This is a good example for what I meant and for what I perceive throughout different spots with D. It strikes me as hard to understand when very important factors seem to be simply ignored. In the embedded world where 1KB can be a lot and where one tries to squeeze out another 50us or another 200 Bytes other laws and priorities are valid than in userland where libraries in the MB range are seen as granted. My point wasn't that C is perfect for embedded. My point was that D is the wrong tool there. If, on the other hand, one wanted to develop an improved "C2e" for embedded (and probably kernel) that language almost certainly would disappoint in the userland application development - those two worlds are just too different. I don't mean to sound blunt but I see another point that rarely gets addressed. WB wanted to scratch an itch. That's OK and he was free to do that in any way he saw fit or felt fine. But - luckily for us - he went further and opened it and wanted, if I'm not very mistaken, D to become (more) widely used. From that moment on the target audience was to be heard and included. Similarly I value AA's work very highly but I feel that we should have 1 (in words: one) complete and widely acceptable toolchain on the major platforms - and - have a reliable and reliably working version of whatever first before adding and changing things. Probably some wouldn't be happy with, say, Scite (with D support) and GDB (with D support) and, for instance, not yet supporting 64bit linux. But it would be a base to say "You *can* work. No let's go and enhance and grow D, it's standard lib and it's eco system". Unfortunately the path chosen led us to a situation where D and phobos are somewhat floating, the advertisements aren't honest, unmistakable and to the point, and the tools are quite floating and often half-cooked or limited, too. Let me shed light on what I mean from another perspective: There is a reason for a language having lots of alpha, broken, and quit projects in its environment. It very often (if not almost always) translates to: people discovered the language, were attracted by the first impression, even had a need for it, invested time, efforts, and know-how - and then left. If we really want D to grow and spread, we will have to see and realize that and to think hard about it and about how to improve. I'm sorry, honestly sorry, that I myself can not (yet) contribute much more than thoughts and constructive(!) criticism. I'm working on it and - thanks to Iain (I was just a split second away from leaving D) - I stayed. That's not much but it's the best I can give as a D newbie and it's much more than just leaving like so many before me. Have a nice weekend, everyone -R
Sep 06 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Sep 07, 2013 at 05:35:48AM +0200, Ramon wrote:
[...]
 I'm sorry, honestly sorry, that I myself can not (yet) contribute
 much more than thoughts and constructive(!) criticism. I'm working
 on it and - thanks to Iain (I was just a split second away from
 leaving D) - I stayed. That's not much but it's the best I can give
 as a D newbie and it's much more than just leaving like so many
 before me.

Don't be sorry; D is really not *that* hard to learn (it's certainly simpler than C++, speaking from my experience!). Once you get a good grip on it, start making pull requests. Make the changes you'd like to see happen. That's what I'm doing. I see a lot of flaws and problems in various areas, but I don't see much value in complaining -- it often only makes people angry and the problem still remains. Instead, I tell myself, OK, I may not know everything about D, but I do know *something* about programming, so I'm going to make the code changes and submit them. If they don't like it, then it's a good opportunity for me to learn how to make my code changes better; if they accept it, even better, I made a difference. I find that it's much more convincing for me to say "feature X is broken, here's the code change to make it better", than to say "feature X is broken, D sucks, you lazy bums better start working to fix X or else I'm leaving". It feels good to rant and get it off my chest, but it feels even better to have my changes merged and feature X to get fixed because of me. T -- Latin's a dead language, as dead as can be; it killed off all the Romans, and now it's killing me! -- Schoolboy
Sep 06 2013
prev sibling next sibling parent "Ramon" <spam thanks.no> writes:
On Saturday, 7 September 2013 at 05:35:04 UTC, H. S. Teoh wrote:
 I find that it's much more convincing for me to say "feature X 
 is
 broken, here's the code change to make it better", than to say 
 "feature
 X is broken, D sucks, you lazy bums better start working to fix 
 X or
 else I'm leaving".  It feels good to rant and get it off my 
 chest, but
 it feels even better to have my changes merged and feature X to 
 get
 fixed because of me.

My intention was and is not ranting, nor saying D sucks, nor asking other to do work nor threatening. And this can found proven in what I wrote. Your personal attitude, which many others have, too, is one to be respected and a necessary and productive one. Bot not the only valid or constructive one. Neither is there a need to decide; the options are not mutually exclusive. As a seasoned programmer that I take you to be you certainly can agree that leaning back and looking, incl. looking critically at was has been done so far not only is not harmful but it actually is positive and often even necessary. And you will quite certainly also degree that a non trivial project will need some planning and management. Unlike what you seem to think, my point isn't hitting on D (actually that's obviously nonsensical as I wrote just yesterday or today that meanwhile I'm happily humming along with D). But neither can it be a healthy attitude to ignore less pleasant things or events. We should ask what's behind it and what we can make better. Simply fixing issues one at a time is not a solution per se but rather one step in solving a problem albeit an important one. Identifying reasons and patterns is also a step and often one that considerably enhances the situation. If today I'm a better devoloper than 20 years ago than not merely by experience alone but by learning from mistakes and (in my case an important lesson) by thinking extensively *before* I hack, by learning the importance of good design and well proven principles and, last but not least, by learning to recognize patterns in my errors. I try to be polite and respectful because I highly value the work of WB, AA and others but I feel a suspicion that "shut up and write code!" is not a solution but part of the problem in certain regards. But I respect your right to rant *g A+ -R
Sep 06 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 6 September 2013 19:40, eles <eles eles.com> wrote:
 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.=

 D the first language with a compiler unable to compile its own standard
 library?

And you rephrase that question? I think you asked it wrong. :)
 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 tomorro=


I don't think that's true. Any compiler operations being moved into the library will be separate from the language keyword. eg: creal -> Complex!real.
 In C or C++, while the standard library is part of the language standard,=

 not part of the language per s=E9. It is not part of the compiler, after =

 It is provided with.

C++ required a minimal runtime as it does emit library calls through code generation (see libcxxrt link earlier in this thread) - there are however compiler switches which mean that the c++ compiler will error if you try to use any of these features. --=20 Iain Buclaw *(p < e ? p++ : p) =3D (c & 0x0f) + '0';
Sep 07 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 7 September 2013 00:17, Ramon <spam thanks.no> wrote:
 - 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.

You can thank GNU for that portable toolchain too... :o) -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Sep 07 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 06/09/13 15:11, Iain Buclaw wrote:
 It has always been the case that if you want to enter kernel-space
 with D, you have to drop phobos and implement a more low level
 druntime.  For instance, the GC that comes with D is wholly infeasible
 for use inside a kernel .

To what extent can that situation be improved with respect to Phobos? The ideal would be to make it non-GC-reliant and agnostic with respect to how the runtime manages memory. More generally, this makes a case for something like a well defined "dmicroruntime" which can be used as a general solution for embedded and low-level programming.
Sep 08 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 07/09/13 07:33, H. S. Teoh wrote:
 I find that it's much more convincing for me to say "feature X is
 broken, here's the code change to make it better", than to say "feature
 X is broken, D sucks, you lazy bums better start working to fix X or
 else I'm leaving".  It feels good to rant and get it off my chest, but
 it feels even better to have my changes merged and feature X to get
 fixed because of me.

Of course, but many potential users don't have the free time to be able to do this, and even if they do, sometimes the techniques required to make the fix are outside their understanding (and the time required for learning may be prohibitive). I don't think there's any excuse for ranting, but it's understandable that there can be frustration in circumstances where a user says: "Hey, this feature is broken, having it work is really important for me," and that concern is not reciprocated by the principal developers. I don't think D is particularly an offender here -- where it is, it's usually down to manpower rather than unwillingness to recognize problems. But when anything like this happens, it's very demotivating to users.
Sep 08 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 8 September 2013 13:00, Joseph Rushton Wakeling
<joseph.wakeling webdrake.net> wrote:
 On 06/09/13 15:11, Iain Buclaw wrote:
 It has always been the case that if you want to enter kernel-space
 with D, you have to drop phobos and implement a more low level
 druntime.  For instance, the GC that comes with D is wholly infeasible
 for use inside a kernel .

To what extent can that situation be improved with respect to Phobos? The ideal would be to make it non-GC-reliant and agnostic with respect to how the runtime manages memory.

Wouldn't want to change Phobos in any way really, it serves it's purpose.
 More generally, this makes a case for something like a well defined
 "dmicroruntime" which can be used as a general solution for embedded and
 low-level programming.

This could be done - don't like the name though. ;) -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Sep 08 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 08/09/13 15:04, Iain Buclaw wrote:
 This could be done - don't like the name though. ;)

smalld... ? :-)
Sep 08 2013
prev sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 8 September 2013 17:04, Joseph Rushton Wakeling
<joseph.wakeling webdrake.net> wrote:
 On 08/09/13 15:04, Iain Buclaw wrote:
 This could be done - don't like the name though. ;)

smalld... ? :-)

libdrt? Like libdruntime, but based on a minimalist contents of /rt/ :o) -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Sep 08 2013