www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Rust-based provocation :)

reply "Dicebot" <m.strashun gmail.com> writes:
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
May 27 2013
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
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.
May 27 2013
parent reply "Dicebot" <m.strashun gmail.com> writes:
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.
May 27 2013
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
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.
May 27 2013
parent reply "Dicebot" <m.strashun gmail.com> writes:
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.
May 27 2013
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
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
May 27 2013
next sibling parent reply "nazriel" <spam dzfl.pl> writes:
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/typein o/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/typein o/ti_Acfloat.d(42): Error: cannot implicitly convert expression (s1.length) of type ulong to uint" blown off my enthusiasm ;)
May 28 2013
next sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Tuesday, 28 May 2013 at 07:26:34 UTC, nazriel wrote:
 I tried to port your package to x86_64 but dozens of:

 "/home/raz/.dvm/compilers/dmd-2.063/src/druntime/src/rt/typein
o/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/typein
o/ti_Acfloat.d(42): 
 Error: cannot implicitly convert expression (s1.length) of type 
 ulong to uint"

 blown off my enthusiasm ;)
Those should go away once you change size_t and related alias meaning from uint to ulong and tweak few places where it is hard-coded.
May 28 2013
prev sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
I'm just playing with this a little more and the bgi thing that 
seems to be bugging me is TLS doesn't work here. D assumes it, so 
if you use a tls var (as opposed to __gshared or local) you get 
annoying segfaults. Blargh.
May 28 2013
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
anyway exceptions work after copy/pasting more code from druntime 
and adding some __gshared and removing some printfs. No stack 
traces, but the mechanics are there.

My test program is now 15k stripped (23k 64 bit), quite a bit 
larger than the really naked thing, but still a lot smaller than 
full druntime+phobos apps, but this really is a good bulk of the 
language; I feel like this would be a seriously usable subset.

I also got it kinda working on 64 bit. The command line argument 
and environment variable fetching is another one of those things 
I've done on linux 32 bit asm, but never 64 bit and varargs are 
apparently different.... so I just left those blank for now. So 
if you play on 64 bit, remember args and environment will always 
be null for now.

But otherwise my test program worked as much as I ran it.



Anyway if you want to play with it, the zip file is updated
arsdnet.net/dcode/minimal.zip

object.d is now up to about 1200 lines, over half of it being 
selectively copy/pasted from full druntime.
May 28 2013
parent reply "Dicebot" <m.strashun gmail.com> writes:
On Wednesday, 29 May 2013 at 01:07:58 UTC, Adam D. Ruppe wrote:
 ...
Thanks for doing this, very appreciated. This thread unexpectedly got really useful to me, now I know that there is at least one more D programmer interested in this :) Won't be really able to test it until next week, but have added to bookmarks. My main interest here is to get something running to experiment with what changes can be made to compiler to allow to remove unused stubs and still get the useful stuff running. Like "no exceptions" and "no rtti" switches in g++.
May 29 2013
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 29 May 2013 at 09:58:02 UTC, Dicebot wrote:
 My main interest here is to get something running to experiment 
 with what changes can be made to compiler to allow to remove 
 unused stubs and still get the useful stuff running. Like "no 
 exceptions" and "no rtti" switches in g++.
That might be possible through -version switches on object.d, which would give either a stub (my original d_throw function before copy/pasting from druntime just said { write("exception thrown"); exit(1); } or something like that) or left out entirely, leading to linker errors. The same thing might be possible for more features. BTW I just tried new int[](10), and that needs even more code. But I think using that in a non-gc environment is actually a mistake anyway. It could be done like classes, where the new function mallocs and you are responsible for freeing, but the problem is new int[](10) and arr[0 .. 10] look the same in user code. You would be responsible for freeing the former, but not the slice. So I think keeping them a different type is a feature, not a bug, in this situation. My thought is array slices are always "borrowed" references. You don't free them, and you should avoid keeping a copy of it unless that is well documented. (Actually I think this would be nice addition to D proper, a special type qualifier that promises you'll never store a reference to this except in local variables. So you can still slice it and so on, but never stuff it in a member variable because the owner might free it without informing you.) Anyway the arrays themselves are a different library type StackArray!int blah; HeapArray!int blah; and so on, and you've gotta be responsible for freeing them appropriately. The StackArray of course dies when it goes out of scope, and maybe the HeapArray could be reference counted. Again, built in slices won't count toward the count, so can only use them temporarily, but the rest could be. And when this is written it might be a good idea to put in phobos too!
May 29 2013
parent reply "Dicebot" <m.strashun gmail.com> writes:
On Wednesday, 29 May 2013 at 12:41:25 UTC, Adam D. Ruppe wrote:
 You would be responsible for freeing the former, but not the 
 slice. So I think keeping them a different type is a feature, 
 not a bug, in this situation.
I have been thinking about this long time ago. Clearly, slice semantics will change in GC-less environment and will require more restrictive operation set. No automatic slice concatenation at the very least.
 (Actually I think this would be nice addition to D proper, a 
 special type qualifier that promises you'll never store a 
 reference to this except in local variables. So you can still 
 slice it and so on, but never stuff it in a member variable 
 because the owner might free it without informing you.)
Isn't it what "scope" was supposed to be all about? :) Qualifier that prohibits leaking data outside of the current scope.
 And when this is written it might be a good idea to put in 
 phobos too!
Dunno. If something like this can be done, it will need full re-implementation of standard library (similar to minlibd) as assumption made about feature set allowed and druntime differ a lot.
May 29 2013
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 29 May 2013 at 12:50:36 UTC, Dicebot wrote:
 I have been thinking about this long time ago. Clearly, slice 
 semantics will change in GC-less environment and will require 
 more restrictive operation set. No automatic slice 
 concatenation at the very least.
Right. Without implementing the append function, there's a linker error if you try to do it: minimal.d:29: undefined reference to `_d_arrayappendcTX' which really isn't half bad, the line number is there too, I'll take it. Another thing I'm thinking about is immutable data. String literals are immutable(char)[] and ok to store, so maybe any immutable data would be ok. I'm thinking there might be a newImmutable function I can make that puts the data on a special heap that is never free()'d. Maybe. idk, I should probably get back to my actual work soon anyway.
 Isn't it what "scope" was supposed to be all about? :) 
 Qualifier that prohibits leaking data outside of the current 
 scope.
Maybe, but it doesn't actually work like that right now anyway.
 Dunno. If something like this can be done, it will need full 
 re-implementation of standard library (similar to minlibd) as 
 assumption made about feature set allowed and druntime differ a 
 lot.
Yeah, but manual memory stuff would be useful even if you have the gc so there should be some carryover possible.
May 29 2013
prev sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Tuesday, 28 May 2013 at 00:43:25 UTC, Adam D. Ruppe wrote:
 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.
Ah thanks, did not know that. Excited to port and try this :)
May 28 2013
prev sibling parent reply Brad Roberts <braddr puremagic.com> writes:
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
May 27 2013
next sibling parent "Dicebot" <m.strashun gmail.com> writes:
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
May 27 2013
prev sibling parent "Dicebot" <m.strashun gmail.com> writes:
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.
May 27 2013