February 11, 2012
On 11 February 2012 17:47, Artur Skawina <art.08.09@gmail.com> wrote:
> On 02/11/12 02:46, Era Scarecrow wrote:
>>>
>>> There is no way you get a D application into 64K. The language is not powerful enough. Only C can achieve that.
>>
>> I'll need to agree. Porting D to a smaller memory space and with cramped features in all of this is not going to be good no matter how you look at it. I'm sure it's similar to comparing using perl in something with only 64k of memory, one must ask where you can put the interpreter, decoding and working with the source text, and many other things, not to mention even if you pulled it off, the speed penalty.
>>
>> With only 64k, you aren't going to need anything extremely complex or elaborate.
>> You MIGHT get away with exporting D code to using C symbols, but you'll likely be stuck working with structs, no library support, no heap, no memory management, and fixed-sized arrays. I doubt you'd need templates, or any of the higher functions. All structures and types must be basic or known statically at compile time. Unlikely for lambdas to be used, and a score of other features.
>>
>> This is all just speculation, but I think you get the picture. If you make a subset of D, it would most likely be named Mini-D. But at that point you've got an enhanced C without going C++.
>>
>
> I assumed the poster you're replying to was not being serious.
> There's absolutely no difference between the code generated from C and D,
> unless you use a few D-only concepts; ignoring compiler issues.
> Having several levels of modules and templates, that in the end emit
> single CPU instructions is not only possible, it lets you write
> completely generic code that's both safer and not less efficient than
> writing the equivalent in assembler.
> I can easily see D being acceptable for 8K projects, 64K would probably
> allow for a mostly complete runtime.
>


I'd imagine the general idea is, just how much of druntime can we strip away and still have the compiler be happy with all it's implicit library calls.  After that, then decide what we don't *need*, or could do in an alternative way and achieve the same result (without loosing safeness).  I'd imagine there's quite a few things that could be done differently depending on whether the compiler is building with the assumption the program is going to be free standing environment, or will depend on some sort of runtime existing that we'll link to.  What can't be done may most likely be an error.




-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
February 11, 2012
On 02/11/2012 06:43 PM, Piotr Szturmaj wrote:
> Nick Sabalausky wrote:
>> "Andrei Alexandrescu"<SeeWebsiteForEmail@erdani.org> wrote in message
>> news:jh40oq$26p0$1@digitalmars.com...
>>> On 2/10/12 12:54 PM, Tim Krimm wrote:
>>>> On Friday, 10 February 2012 at 20:21:53 UTC, Andrei Alexandrescu wrote:
>>>>> On 2/10/12 11:02 AM, Tim Krimm wrote:
>>>>>> We have C and C++
>>>>>>
>>>>>> How about D- and D?
>>>>>
>>>>> No please.
>>>>>
>>>>> Andrei
>>>>
>>>> Please elaborate.
>>>
>>> The last thing we need is balkanization of the community. You are of
>>> course free to initiate such a project but if you care about D it
>>> would be
>>> great to apply your talent in a different direction.
>>>
>>
>> I absolutely agree: We've learned a very hard lession from the
>> community-fragmenting failure that was known as SafeD.
>
> So now SafeD is only thing of the past?

Nick was quite obviously being sarcastic. ;)
February 11, 2012
On 02/11/2012 06:55 PM, Andrei Alexandrescu wrote:
> On 2/11/12 8:48 AM, Nick Sabalausky wrote:
>> "Andrei Alexandrescu"<SeeWebsiteForEmail@erdani.org> wrote in message
>> news:jh40oq$26p0$1@digitalmars.com...
>>> On 2/10/12 12:54 PM, Tim Krimm wrote:
>>>> On Friday, 10 February 2012 at 20:21:53 UTC, Andrei Alexandrescu wrote:
>>>>> On 2/10/12 11:02 AM, Tim Krimm wrote:
>>>>>> We have C and C++
>>>>>>
>>>>>> How about D- and D?
>>>>>
>>>>> No please.
>>>>>
>>>>> Andrei
>>>>
>>>> Please elaborate.
>>>
>>> The last thing we need is balkanization of the community. You are of
>>> course free to initiate such a project but if you care about D it
>>> would be
>>> great to apply your talent in a different direction.
>>>
>>
>> I absolutely agree: We've learned a very hard lession from the
>> community-fragmenting failure that was known as SafeD.
>
> Not sure what you mean there. As far as I can tell SafeD did not fail
> and there was no community fragmentation at any point because of it.
>
> Andrei
>

He was setting up an analogy between SafeD and 'EmbedD' in a satirical attempt to ridicule non-uniform treatment of the concepts.
February 11, 2012
On Saturday, February 11, 2012 19:00:51 q66 wrote:
> What's so difficult on that? Slices do not require the GC, you allocate once, slice many times, deallocate once.

With dynamic arrays, the GC owns the memory, and _all_ dynamic arrays are slices. _None_ of them own their own memory. The GC keeps track of whether you have any slices for a particular memory block and deals with freeing up wth the block if you don't. However, if you allocate a dynamic array without the GC, then all of a sudden, it effectively owns its own memory, so the semantics of dealing with arrays and memories changes drastically. What happens when you slice it? Which one owns the memory? What happens when you try and do stuff like popFront on an array? All of a sudden, you have memory which is no longer referenced. It's been leaked.

If you have a very careful scheme for handling memory, you _can_ slice arrays without a GC, but you have to worry about all the bookkeeping of keeping track of the originally allocated memory and how many slices reference it so that you can free it when appropriate.

Also, you can't concatenate to arrays at all, because that requires the GC.

So, you're dealing with a mine field if you try and use D's array capabilities without a GC. Yes, you _can_ use some of them if you're _very_ careful, but I'd seriously advise just sticking to using arrays like you would in C except for the fact that arrays know their length.

- Jonathan M Davis
February 11, 2012
On 2/11/12 12:07 PM, H. S. Teoh wrote:
> On Sat, Feb 11, 2012 at 11:55:07AM -0600, Andrei Alexandrescu wrote:
>> On 2/11/12 8:48 AM, Nick Sabalausky wrote:
> [...]
>>> I absolutely agree: We've learned a very hard lession from the
>>> community-fragmenting failure that was known as SafeD.
>>
>> Not sure what you mean there. As far as I can tell SafeD did not fail
>> and there was no community fragmentation at any point because of it.
> [...]
>
> AFAIK, SafeD is just incompletely implemented, right? But it exists and
> it will be done one day.

That is correct. A nicer way to put it is @safe needs more work.

Andrei

February 11, 2012
On 2/11/12 12:28 PM, Timon Gehr wrote:
> Nick was quite obviously being sarcastic. ;)

oops...

Andrei
February 11, 2012
On Saturday, 11 February 2012 at 18:53:13 UTC, Andrei Alexandrescu wrote:
> On 2/11/12 12:28 PM, Timon Gehr wrote:
>> Nick was quite obviously being sarcastic. ;)
>
> oops...
>
> Andrei

I am sorry Andrei, I think I stirred up a rats nest with this D- or EmbeddedD stuff.
February 11, 2012
Jonathan M Davis wrote:
> On Saturday, February 11, 2012 19:00:51 q66 wrote:
>> What's so difficult on that? Slices do not require the GC, you
>> allocate once, slice many times, deallocate once.
>
> With dynamic arrays, the GC owns the memory, and _all_ dynamic arrays are
> slices. _None_ of them own their own memory. The GC keeps track of whether you
> have any slices for a particular memory block and deals with freeing up wth
> the block if you don't. However, if you allocate a dynamic array without the
> GC, then all of a sudden, it effectively owns its own memory, so the semantics
> of dealing with arrays and memories changes drastically. What happens when you
> slice it? Which one owns the memory? What happens when you try and do stuff
> like popFront on an array? All of a sudden, you have memory which is no longer
> referenced. It's been leaked.
>
> If you have a very careful scheme for handling memory, you _can_ slice arrays
> without a GC, but you have to worry about all the bookkeeping of keeping track
> of the originally allocated memory and how many slices reference it so that
> you can free it when appropriate.
>
> Also, you can't concatenate to arrays at all, because that requires the GC.
>
> So, you're dealing with a mine field if you try and use D's array capabilities
> without a GC. Yes, you _can_ use some of them if you're _very_ careful, but
> I'd seriously advise just sticking to using arrays like you would in C except
> for the fact that arrays know their length.

Delphi has dynamic arrays and appendable strings without a GC. In Delphi pointers and objects are managed manually, but arrays and strings are managed automatically (ref counted with Copy-On-Write). Take a look at http://www.codexterity.com/delphistrings.htm. Maybe some Delphi solutions may be used in NoGcD?
February 11, 2012
On Saturday, 11 February 2012 at 19:21:49 UTC, Piotr Szturmaj wrote:
> Jonathan M Davis wrote:
>> On Saturday, February 11, 2012 19:00:51 q66 wrote:
>>> What's so difficult on that? Slices do not require the GC, you
>>> allocate once, slice many times, deallocate once.
>>
>> With dynamic arrays, the GC owns the memory, and _all_ dynamic arrays are
>> slices. _None_ of them own their own memory. The GC keeps track of whether you
>> have any slices for a particular memory block and deals with freeing up wth
>> the block if you don't. However, if you allocate a dynamic array without the
>> GC, then all of a sudden, it effectively owns its own memory, so the semantics
>> of dealing with arrays and memories changes drastically. What happens when you
>> slice it? Which one owns the memory? What happens when you try and do stuff
>> like popFront on an array? All of a sudden, you have memory which is no longer
>> referenced. It's been leaked.
>>
>> If you have a very careful scheme for handling memory, you _can_ slice arrays
>> without a GC, but you have to worry about all the bookkeeping of keeping track
>> of the originally allocated memory and how many slices reference it so that
>> you can free it when appropriate.
>>
>> Also, you can't concatenate to arrays at all, because that requires the GC.
>>
>> So, you're dealing with a mine field if you try and use D's array capabilities
>> without a GC. Yes, you _can_ use some of them if you're _very_ careful, but
>> I'd seriously advise just sticking to using arrays like you would in C except
>> for the fact that arrays know their length.
>
> Delphi has dynamic arrays and appendable strings without a GC. In Delphi pointers and objects are managed manually, but arrays and strings are managed automatically (ref counted with Copy-On-Write). Take a look at http://www.codexterity.com/delphistrings.htm. Maybe some Delphi solutions may be used in NoGcD?

It's possible that we just create our own dynamic array similar to that of std::vector from C++ except using cleaner syntax available in D. I'd really rather not do that though since it feels redundant.
February 11, 2012
"Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.242.1328986002.20196.digitalmars-d@puremagic.com...
> On Saturday, February 11, 2012 19:00:51 q66 wrote:
>> What's so difficult on that? Slices do not require the GC, you allocate once, slice many times, deallocate once.
>
> With dynamic arrays, the GC owns the memory, and _all_ dynamic arrays are slices.

But not all slices are slices of dynamic arrays.

> _None_ of them own their own memory. The GC keeps track of whether you
> have any slices for a particular memory block and deals with freeing up
> wth
> the block if you don't. However, if you allocate a dynamic array without
> the
> GC, then all of a sudden, it effectively owns its own memory, so the
> semantics
> of dealing with arrays and memories changes drastically. What happens when
> you
> slice it? Which one owns the memory? What happens when you try and do
> stuff
> like popFront on an array? All of a sudden, you have memory which is no
> longer
> referenced. It's been leaked.
>
> If you have a very careful scheme for handling memory, you _can_ slice
> arrays
> without a GC, but you have to worry about all the bookkeeping of keeping
> track
> of the originally allocated memory and how many slices reference it so
> that
> you can free it when appropriate.
>

Yea, manual memory management is hard and you have to be careful. That's true slices or not.

> Also, you can't concatenate to arrays at all, because that requires the GC.
>

That's true (at least without providing some way to provide an alternate concatenation allocator). But nobody said that all D features would be usable.

> So, you're dealing with a mine field if you try and use D's array
> capabilities
> without a GC. Yes, you _can_ use some of them if you're _very_ careful,
> but
> I'd seriously advise just sticking to using arrays like you would in C
> except
> for the fact that arrays know their length.
>

Arrays knowing their own length *is* a notable improvement over C.