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