http://www.reddit.com/r/programming/comments/1f2nwe/zerors_rust_without_a_runtime/

It really makes me sad to see that Rust, despite being that immature and unstable is _already_ closer to embedded environments than D.

Any possibility of a change? :P

most minimal, few D features actually work:
http://arsdnet.net/dcode/minimal.d

slightly less minimal, with a few more things working:
http://arsdnet.net/dcode/minimal.zip

I haven't spent a lot of time on this, more just wondering if it could be done, so most of D still doesn't actually work but enough does for hello world (on linux here) at least. The example minimal.d program will spit out its own name and a newline when you run it, demonstrating command line args work, as well as a custom type.

On Monday, 27 May 2013 at 14:21:24 UTC, Adam D. Ruppe wrote:
> most minimal, few D features actually work:
> http://arsdnet.net/dcode/minimal.d
>
> slightly less minimal, with a few more things working:
> http://arsdnet.net/dcode/minimal.zip
>
> I haven't spent a lot of time on this, more just wondering if it could be done, so most of D still doesn't actually work but enough does for hello world (on linux here) at least. The example minimal.d program will spit out its own name and a newline when you run it, demonstrating command line args work, as well as a custom type.

Ye, there is also https://bitbucket.org/timosi/minlibd , quite a mature attempt. But issue is not creating minimal run-time, it is creating minimal one that still has most part of language usable.

Quoting one of reddit comments: "You still have all the other language features, including unique pointers, generics, trait objects, stack/unique closures, etc."

Currently possibility of D run-time tweaking is very limited by compiler expectations about its capabilities. Automatic memory allocation is widely known but emitting TypeInfo's for almost everything is as much painful.

On Monday, 27 May 2013 at 14:36:59 UTC, Dicebot wrote:
> But issue is not creating minimal run-time, it is creating minimal one that still has most part of language usable.

eh the question is what is "most"? Even my little 200 line thing has: functions, templates, scope closures, structs including operator overloading, static arrays, slices, pointers, __traits+ctfe, scope guards, switches, and more.

I just now added basic classes and that wasn't too hard (copy/pasted some code from the real druntime for the typeinfo and so on).

But it doesn't do AAs, throwing exceptions, dynamic arrays and other nice features. Looking at druntime's src, exceptions look hard, and while dynamic arrays, heap closures, and others can easily 'work', they will leak memory, so I don't think they will ever be really good without gc. Exceptions are doable though from what I can tell.


Anyway I think this is enough to do some real programs and feel kinda nice. Surely no worse than C at least.

> Automatic memory allocation is widely known but emitting TypeInfo's for almost everything is as much painful.

Yeah, the typeinfos are a pain in the butt, even trying to copy/paste it from druntime isn't that easy. I'm sure this would strike again if we actually tried writing a real program.

On 5/27/13 7:03 AM, Dicebot wrote:
> http://www.reddit.com/r/programming/comments/1f2nwe/zerors_rust_without_a_runtime/
>
>
> It really makes me sad to see that Rust, despite being that immature and
> unstable is _already_ closer to embedded environments than D.
>
> Any possibility of a change? :P

Of course there's a possibility of change.  Like any aspect of a project like D, it needs a champion.  Someone who decides it's important enough for them that they do the work required.

It's extremely rare for something to happen that others claim they need just out of pure altruism.

So, embedded support is important to you, right?  What have you done to make it happen?

My 2 cents,
Brad

On Monday, 27 May 2013 at 17:18:33 UTC, Brad Roberts wrote:
> On 5/27/13 7:03 AM, Dicebot wrote:
>> http://www.reddit.com/r/programming/comments/1f2nwe/zerors_rust_without_a_runtime/
>>
>>
>> It really makes me sad to see that Rust, despite being that immature and
>> unstable is _already_ closer to embedded environments than D.
>>
>> Any possibility of a change? :P
>
> Of course there's a possibility of change.  Like any aspect of a project like D, it needs a champion.  Someone who decides it's important enough for them that they do the work required.
>
> It's extremely rare for something to happen that others claim they need just out of pure altruism.
>
> So, embedded support is important to you, right?  What have you done to make it happen?
>
> My 2 cents,
> Brad

On Monday, 27 May 2013 at 17:18:33 UTC, Brad Roberts wrote:
> Of course there's a possibility of change.  Like any aspect of a project like D, it needs a champion.  Someone who decides it's important enough for them that they do the work required.
>
> It's extremely rare for something to happen that others claim they need just out of pure altruism.

It is an issue that has some roots in language design. I have
literally zero ideas how to fix it without changing the spec and
this is out of random pull request / library capabilities. I
would have been glad to work on this but only after at least some
form of approval for chosen course of actions. Given the
stability aim, it is unlikely to happen. Thus, "provocation".

> So, embedded support is important to you, right?  What have you done to make it happen?

Helping the guys developing Volt fork of D2, within my limits.

> My 2 cents,
> Brad

You're welcome :)

P.S. Ugh, something is wrong with reCAPTCHA.

On Monday, 27 May 2013 at 15:45:04 UTC, Adam D. Ruppe wrote:
> On Monday, 27 May 2013 at 14:36:59 UTC, Dicebot wrote:
>> But issue is not creating minimal run-time, it is creating minimal one that still has most part of language usable.
>
> eh the question is what is "most"? Even my little 200 line thing has: functions, templates, scope closures, structs including operator overloading, static arrays, slices, pointers, __traits+ctfe, scope guards, switches, and more.

I am intrigued. I have tried to create something to support at least "C with templates" style but hit the wall when found out that templates currently require TypeInfo's. Looking at object.d source, it looks like you are generating TypeInfo stubs that can be optimized away, have I understood it right?

P.S. I can't get to run your "minimal.zip" example because of "object.d(87): Error: mismatch between compiler and object.d or object.di found." which does not really make sense in scope of line 87. Any ideas? Have changes all relevant stuff from x32 to x64 as far as I can see.

On Monday, 27 May 2013 at 17:51:33 UTC, Dicebot wrote:
> Looking at object.d source, it looks like you are generating TypeInfo stubs that can be optimized away, have I understood it right?

I'm not sure if they can be optimized away, but all I was doing is putting the bare minimum so the compiler would shut up.

> P.S. I can't get to run your "minimal.zip" example because of "object.d(87): Error: mismatch between compiler and object.d or object.di found." which does not really make sense in scope of line 87. Any ideas? Have changes all relevant stuff from x32 to x64 as far as I can see.


Hmm I already modified the file I have locally. I'll update the zip but I don't think this will work in 64 bit anyway because the syscall functions are all written in 32 bit inline asm. (I've never written a 64 bit asm program so I'm not even sure what the calling convention would look like there. If you ripped that out and used C functions instead, with an extern(C) main even maybe, you might be in business though.)

I think line 87 was one of the TypeInfos though, and dmd expects them to be a particular size, and it is slightly different on 64 bit. If it is TypeInfo_Struct, on 32 bit void*[13] stuff; is good enough for dmd to shut up.

I believe on 64 bit it expects two more words, so void*[15] stuff should be good enough.

this should be updated and hitting "make" worked on my box, building 32 bit, with the test program being a bit of class stuff. The write() and exit() functions are moved to object.d right now, along with a dead stupid "allocator" that gives you a pointer to a static buffer (that it never frees) to play with new class. If you are using libc, malloc/free should be able to do the job instead, see the manual_alloc and manual_free stubs in object.d

http://arsdnet.net/dcode/minimal.zip

On Tuesday, 28 May 2013 at 00:43:25 UTC, Adam D. Ruppe wrote:
> On Monday, 27 May 2013 at 17:51:33 UTC, Dicebot wrote:
>> Looking at object.d source, it looks like you are generating TypeInfo stubs that can be optimized away, have I understood it right?
>
> I'm not sure if they can be optimized away, but all I was doing is putting the bare minimum so the compiler would shut up.
>
>> P.S. I can't get to run your "minimal.zip" example because of "object.d(87): Error: mismatch between compiler and object.d or object.di found." which does not really make sense in scope of line 87. Any ideas? Have changes all relevant stuff from x32 to x64 as far as I can see.
>
>
> Hmm I already modified the file I have locally. I'll update the zip but I don't think this will work in 64 bit anyway because the syscall functions are all written in 32 bit inline asm. (I've never written a 64 bit asm program so I'm not even sure what the calling convention would look like there. If you ripped that out and used C functions instead, with an extern(C) main even maybe, you might be in business though.)
>
On x86_64 you need to use syscall instead of int 80h
You pass system call id in RAX, then arguments goes into RDI, RSI, RDX, R10, etc.

Table of syscalls is also different
http://blog.rchapman.org/post/36801038863/linux-system-call-table-for-x86-64

> I think line 87 was one of the TypeInfos though, and dmd expects them to be a particular size, and it is slightly different on 64 bit. If it is TypeInfo_Struct, on 32 bit void*[13] stuff; is good enough for dmd to shut up.
>
> I believe on 64 bit it expects two more words, so void*[15] stuff should be good enough.
>
> this should be updated and hitting "make" worked on my box, building 32 bit, with the test program being a bit of class stuff. The write() and exit() functions are moved to object.d right now, along with a dead stupid "allocator" that gives you a pointer to a static buffer (that it never frees) to play with new class. If you are using libc, malloc/free should be able to do the job instead, see the manual_alloc and manual_free stubs in object.d
>
> http://arsdnet.net/dcode/minimal.zip

I tried to port your package to x86_64 but dozens of:

"/home/raz/.dvm/compilers/dmd-2.063/src/druntime/src/rt/typeinfo/ti_Acfloat.d(35): Error: cannot implicitly convert expression (s.length * 8LU) of type ulong to uint
/home/raz/.dvm/compilers/dmd-2.063/src/druntime/src/rt/typeinfo/ti_Acfloat.d(42): Error: cannot implicitly convert expression (s1.length) of type ulong to uint"

blown off my enthusiasm ;)