"Jacob Carlborg" <doob@me.com> wrote in message news:jh63p2$17li$1@digitalmars.com...
> On 2012-02-11 15:36, Nick Sabalausky wrote:
>> "Era Scarecrow"<rtcvb32@yahoo.com>  wrote in message news:jzavmzbmjoyujhqyfvhp@dfeed.kimsufi.thecybershadow.net...
>>>>> What are your thoughts?
>>>>
>>>> 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++.
>>
>> That would *still* be a very notable improvement over C. Hell, if you ask
>> me, a proper module system alone is one of the killer features of D over
>> C.
>> Header files? Seriously? Fuck that shit. What the hell is this, 1970? And
>> then there's other things that are *at the very least* icing on the cake:
>> Faster compilation, slicing, better safety, metaprogramming (esp CTFE)
>> that
>> whups C's ass and makes it much less less tempting to do things at
>> runtime
>> that don't need to be done at runtime. That's all just off the top of my
>> head.
>
> I think slicing is quite difficult without a GC. Not the actual slicing but freeing the memory.
>

Those are orthogonal concerns. Just because you're taking a slice doesn't mean you aren't still using the rest. And if you're not using the rest, then the problem just reduces to the classic old "GC vs manual" issue.

On 02/11/2012 12:58 AM, Paulo Pinto wrote:
> Am 10.02.2012 20:02, schrieb Tim Krimm:
>> We have C and C++
>>
>> How about D- and D?
>>
>> D- would be the have a similar use as today's C compilers.
>>
>> ===========================
>> Why create this language?
>> ===========================
>>
>> Well I would love to have a D compiler that supports microcontrollers.
>> The ones that have say 32 K of RAM and 64K of FLASH.
>> A language that is targeted for embedded and/or low resource
>> environments.
>> It would be nice to have a modern language for low resource environments.
>>
>> A potential way to implement this language is to use the DMD frontend,
>> then flag the unsupported features of D,
>> Next create a backend, like "C front" that outputs C code instead of
>> assembler.
>>
>>
>> ===========================
>> What do I envision with D-,
>> D-- or Dm or what ever you want to call it.
>> ===========================
>>
>> This language would basically be D without the garbage collection.
>> For example there would be structures but no classes.
>> There would be regular arrays but no dynamic arrays.
>> Code that is mostly equivalent to C, but you would still have structures
>> with functions and overloading support,
>> and other features like templates etc.
>>
>> I think you get the idea.
>>
>> What are your thoughts?
>
>
> I don't see the point.
>
> C++ was the last systems programming language without GC getting market
> share. I seriously doubt any new systems programming language without GC
> will ever suceed.
>
> Specially since systems programming in MacOS X and Windows world is

Systems programming in the MacOS X and Windows world isn't real systems programming. The closest you get is kernel and driver work but even there you have most of an OS to work with. I think the kind of systems programming being considered is embedded work and/or things like BIOS work.

> slowly meaning the use of reference counting or GC in the vendor
> supported systems programming languages. Objective-C in MacOS X supports
> GC and Reference Counting (GC). C++ in Windows has the std::*ptr and
> handles in C++/CX. Then there is also C# for systems programming, when
> used in context of Microsoft Research projects like Singularity.
>
> So sum this up. If you need a languague without GC, C and C++ are quite
> good, have lots of tools and excellent compilers available.
>
> Do you need a very simple C like language, but with GC and a few
> improvements, Go might be an option.
>
> Do you need a language with GC, that is C++ done right and quite capable
> for systems programming, pick D.
>
> There is no need to D-.
>
> --
> Paulo

Am 11.02.2012 18:00, schrieb bcs:
> On 02/11/2012 12:58 AM, Paulo Pinto wrote:
>> Am 10.02.2012 20:02, schrieb Tim Krimm:
>>> We have C and C++
>>>
>>> How about D- and D?
>>>
>>> D- would be the have a similar use as today's C compilers.
>>>
>>> ===========================
>>> Why create this language?
>>> ===========================
>>>
>>> Well I would love to have a D compiler that supports microcontrollers.
>>> The ones that have say 32 K of RAM and 64K of FLASH.
>>> A language that is targeted for embedded and/or low resource
>>> environments.
>>> It would be nice to have a modern language for low resource
>>> environments.
>>>
>>> A potential way to implement this language is to use the DMD frontend,
>>> then flag the unsupported features of D,
>>> Next create a backend, like "C front" that outputs C code instead of
>>> assembler.
>>>
>>>
>>> ===========================
>>> What do I envision with D-,
>>> D-- or Dm or what ever you want to call it.
>>> ===========================
>>>
>>> This language would basically be D without the garbage collection.
>>> For example there would be structures but no classes.
>>> There would be regular arrays but no dynamic arrays.
>>> Code that is mostly equivalent to C, but you would still have structures
>>> with functions and overloading support,
>>> and other features like templates etc.
>>>
>>> I think you get the idea.
>>>
>>> What are your thoughts?
>>
>>
>> I don't see the point.
>>
>> C++ was the last systems programming language without GC getting market
>> share. I seriously doubt any new systems programming language without GC
>> will ever suceed.
>>
>> Specially since systems programming in MacOS X and Windows world is
>
> Systems programming in the MacOS X and Windows world isn't real systems
> programming. The closest you get is kernel and driver work but even
> there you have most of an OS to work with. I think the kind of systems
> programming being considered is embedded work and/or things like BIOS work.


Systems programming is everything you need to get an OS up and running. At least it was so a few decades back when I attended computer science and informatics engineering course.

Regarding embedded and BIOS work, many systems being used today still required a custom C compiler without full ANSI C support, so how would
such systems support a D- implementation?

--
Paulo

Jacob Carlborg wrote:
> On 2012-02-10 20:23, Zachary Lund wrote:
>> On 02/10/2012 01:02 PM, Tim Krimm wrote:
>>> This language would basically be D without the garbage collection.
>>> For example there would be structures but no classes.
>>> There would be regular arrays but no dynamic arrays.
>>> Code that is mostly equivalent to C, but you would still have structures
>>> with functions and overloading support,
>>> and other features like templates etc.
>>>
>>> I think you get the idea.
>>>
>>> What are your thoughts?
>>
>> I would love this as well. I *think* you wouldn't have to recreate the
>> language, just recreate the runtime. You can currently use D and can
>> completely avoid the use of the GC by just using static functions. From
>> what I understand, dynamic arrays are also controlled and provided
>> through the runtime. You can also export C symbols if you wanted to.
>
> No need to restrict yourself yo static functions. Functions in structs
> are not virtual and doesn't require the GC.

Virtual functions don't require the GC either.

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?

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.

The answer isn't to butcher the language, it's to fix the shortcomings.
So, for example: all array ops need to be lowered and mapped to D code
so that they can be intercepted. Then you can either disallow everything
not supported or allow some subset and fail for every other operation.
Slicing probably counts too, as you may want to disallow or limit its use.
(Intercepted) pseudo-GC allocation might even work for some cases, even
if i'm not sure that it would be very useful, w/o things like scoped args
and more compiler support.
"synchronized" needs to accept anything that implements opLock() and
opUnlock(). Not only does that let you change the locking primitives,
it also lets you use it for things like CLI/STI-type UP exclusion,
since I doubt the 64K machine would be MP. "synchronized" is better
than RAII/scope because it gives the compiler more information; once
it knows that the code inside the critical region is much more expensive
to run, it can more aggressively move certain parts outside, keeping
the critical region as small as possible (think "immutable" accesses,
that are hidden under a layer of functions/templates).
Classes are probably not a good idea in such a small system, yes.
A compiler option to turn off the default TLS model would help too.
What did I miss?

artur

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

On Saturday, 11 February 2012 at 16:08:02 UTC, Jacob Carlborg wrote:
> On 2012-02-11 15:36, Nick Sabalausky wrote:
>> "Era Scarecrow"<rtcvb32@yahoo.com>  wrote in message
>> news:jzavmzbmjoyujhqyfvhp@dfeed.kimsufi.thecybershadow.net...
>>>>> What are your thoughts?
>>>>
>>>> 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++.
>>
>> That would *still* be a very notable improvement over C. Hell, if you ask
>> me, a proper module system alone is one of the killer features of D over C.
>> Header files? Seriously? Fuck that shit. What the hell is this, 1970? And
>> then there's other things that are *at the very least* icing on the cake:
>> Faster compilation, slicing, better safety, metaprogramming (esp CTFE) that
>> whups C's ass and makes it much less less tempting to do things at runtime
>> that don't need to be done at runtime. That's all just off the top of my
>> head.
>
> I think slicing is quite difficult without a GC. Not the actual slicing but freeing the memory.

What's so difficult on that? Slices do not require the GC, you allocate once, slice many times, deallocate once.

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.


T

-- 
Жил-был король когда-то, при нём блоха жила.

On 2012-02-11 18:40, Piotr Szturmaj wrote:
> Jacob Carlborg wrote:
>> On 2012-02-10 20:23, Zachary Lund wrote:
>>> On 02/10/2012 01:02 PM, Tim Krimm wrote:
>>>> This language would basically be D without the garbage collection.
>>>> For example there would be structures but no classes.
>>>> There would be regular arrays but no dynamic arrays.
>>>> Code that is mostly equivalent to C, but you would still have
>>>> structures
>>>> with functions and overloading support,
>>>> and other features like templates etc.
>>>>
>>>> I think you get the idea.
>>>>
>>>> What are your thoughts?
>>>
>>> I would love this as well. I *think* you wouldn't have to recreate the
>>> language, just recreate the runtime. You can currently use D and can
>>> completely avoid the use of the GC by just using static functions. From
>>> what I understand, dynamic arrays are also controlled and provided
>>> through the runtime. You can also export C symbols if you wanted to.
>>
>> No need to restrict yourself yo static functions. Functions in structs
>> are not virtual and doesn't require the GC.
>
> Virtual functions don't require the GC either.

No they don't, but the will add other overhead.

-- 
/Jacob Carlborg