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?

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';

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... :(

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';

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.

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?

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

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.

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';

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';