On 15/04/2011 5:00 AM, d.gnu-request@puremagic.com wrote:
> Date: Wed, 13 Apr 2011 23:30:24 +0000 (UTC)
> From: Iain Buclaw <ibuclaw@ubuntu.com>
>
> == Quote from Brendan Simon (eTRIX) (brendan.simon@etrix.com.au)'s article
>> > >> > Can D be used in low-level drivers for Linux or other RTOS
>> (e.g. freertos)
>>> > > D is not really suitable for a freestanding environment.
>>> Especially if you intendto use any non-POD features of the language
>>> (C++ has the same problem too).
>> > So is it possible to use D in a limited capacity for a bare-metal, or low-level (rtos/kernel, driver) environment ??
> Yes an no for the same reasons C++ is suitable for such a task.
>
> It probably *could* be done (see the XOMB exo-kernel project), but requires you implement a bespoke runtime, not use the one that comes bundled with DMD/GDC.
Had a quick look at XOmB and XOmB Bare Metal.  It sounds very interesting, but also very young.  I don't even think they have a filesystem or moderately complex C application working yet.

I wonder how it performs compared to other C based OSes ??  Probably hard to compare as it is not a traditional micro-kernel.

I believe that eCos is written in C++ (or a restricted subset), and I presume that it performs quite well, so given that, I see no reason why a D based OS/RTOS could not perform as well as eCos or other OSes.

-- Brendan.

On 4/16/2011 9:21 PM, Brendan Simon (eTRIX) wrote:

> I believe that eCos is written in C++ (or a restricted subset), and I
> presume that it performs quite well, so given that, I see no reason why
> a D based OS/RTOS could not perform as well as eCos or other OSes.
Squeak is a good example of that too.  The smalltalk language is interpreted but the developers of Squeak have managed to extract a subset that can be compiled as  C code.  Allowing Squeak to be written in smalltalk.

One obstacle is D's runtime is coupled to the compiler.  Several runtime functions are part of the code the compiler outputs.  I am not aware of any documentation other than phobos and tango source that describes that coupling.

For example 'new' requires _d_newclass and 'throw' requires _d_throw. In addition to the module related output per file.

The Windows driver module, possibly others I'm just familiar with that one, may be a good way to think of the problem.  Essentially one has layers that would give access to an increasing subset of D until you reach the full capabilities offered.

bare-metal : D subset WYSIWYG.  D requires no support functions. Outputs
	minimal extra code.
kernel : Basic support functions.
driver(low): Kernel allocated objects. Maybe GC.
driver(high): Templates, GC, TLS, basically full D at this point.
user: Phobos or equivalent runtime.


That's just my perception of the problem.  I have no experience with actually designing such a system.

Daniel Green Wrote:

> The Windows driver module, possibly others I'm just familiar with that one, may be a good way to think of the problem.  Essentially one has layers that would give access to an increasing subset of D until you reach the full capabilities offered.
> 
> bare-metal : D subset WYSIWYG.  D requires no support functions. Outputs
> 	minimal extra code.
> kernel : Basic support functions.
> driver(low): Kernel allocated objects. Maybe GC.
> driver(high): Templates, GC, TLS, basically full D at this point.
> user: Phobos or equivalent runtime.

Such feature would be fantastic.
Where belong asserts and bound checks?

On 4/18/2011 5:15 AM, Kagamin wrote:
> Such feature would be fantastic.
I don't see this becoming a feature of D for quite some time if ever although it would make the enforcement easier.
Once the subsets are defined the next challenge is enforcing them.  Two ideas come to me right now.  Enforcing it by checking object symbols, most restrictions would generate some form of standardized symbol request.  The other is to use the D frontend and create a sort of lint checker.

> Where belong asserts and bound checks?
_d_array_bounds does bounds checking.
_d_assert_msg does asserts.
That is what I meant by symbol checking.  Since they exist as separate features with separate symbols They could be filtered into whatever level is most appropriate.  asserts I'd place in kernel  and bounds checking in drivers.  Possibly low, but definately high.

== Quote from Daniel Green (venix1@gmail.com)'s article
> On 4/18/2011 5:15 AM, Kagamin wrote:
> > Such feature would be fantastic.
> I don't see this becoming a feature of D for quite some time if ever
> although it would make the enforcement easier.
> Once the subsets are defined the next challenge is enforcing them.  Two
> ideas come to me right now.  Enforcing it by checking object symbols,
> most restrictions would generate some form of standardized symbol
> request.  The other is to use the D frontend and create a sort of lint
> checker.
> > Where belong asserts and bound checks?
> _d_array_bounds does bounds checking.
> _d_assert_msg does asserts.
> That is what I meant by symbol checking.  Since they exist as separate
> features with separate symbols They could be filtered into whatever
> level is most appropriate.  asserts I'd place in kernel  and bounds
> checking in drivers.  Possibly low, but definately high.

Contracts would be out of the picture in kernel mode, and replaced with something creative. For example:

Code:
  assert(condition);

Userspace:
  // Raise Exception if false
  _d_assert(condition);

Kernel space:
  //  Emit barrier saying that control flow will not pass here. ie: hlt for x86
  if (unlikely(foo))
    unreachable();