On Sunday, 4 January 2015 at 17:25:49 UTC, Martin Nowak wrote:

> Exceptions on MC sounds like a bad idea,

That is a bias of old.  It is entirely dependent on the application.  Many modern uses of microcontrollers are not hard real-time, and while my work was primarily on ARM microcontrollers, my previous comments were about using D for bare-metal and systems programming in general.

> Last time I build an embedded ARM project the resulting D binary was as small as the C++ one.

Yes, my "Hello World!" was 56 bytes, but, it's not only about getting something to work.

> A group of people that builds the infrastructure is needed.
>
> I can't strictly follow your conclusion, that half of the language needs to be change.
> The only thing I needed to do last time, was to disable ModuleInfo generation in the compiler.

My conclusion is not that half the language needs to change.  As I said in a previous post, the changes needed are likely few, but fundamental, and can't be implemented in infrastructure alone if you want the result to be more than "Hey, I got it to work".

The original thread prompting this discussion was about having a bare-metal GSOC project.  As I and others have shown, such a project is possible, interesting, entertaining and educational, but it will always be just that without language/compiler/toolchain support.

A more worthwhile GSOC project would be to add those few, yet fundamental, language/compiler/toolchain changes to make the experience feel like the language was designed with intent for the purpose of systems programming.  But I don't think that will be of much interest to embedded/kernel/bare-metal programmers, but rather more for those with an interest in language and compiler design.

Mike

On Saturday, 3 January 2015 at 14:14:42 UTC, Adam D. Ruppe wrote:

> What changes did you have in mind?

I forgot to mention in my last post your proposal for moving TypeInfo to the runtime [1] is also one of the changes I had in mind. It would be an excellent start, an important precedent, and would avoid the ridiculous TypeInfo-faking hack necessary to get a build.

It's exactly silly hacks like that that degrade the experience. I don't have the skills to fix it, and even if I did, I'm confident it wouldn't be welcome due to the aversion to change in the leadership and community.  This is why I'm saying bare-metal programming in D will need to fork and break with this community and its current philosophy for it to be a real contender with C/C++ in this domain.

Mike

[1] http://forum.dlang.org/thread/bug-12270-3@https.d.puremagic.com%2Fissues%2F

On Sunday, 4 January 2015 at 19:50:48 UTC, Johannes Pfau wrote:

> One example of many: If you disable ModuleInfo we still happily compile
> module constructors, they'll never be called though. Sure you can avoid
> this if you know about it, but we can't promote D as a reasonable
> replacement for C as long as these issues exist.

Exactly, that's good example.

On Monday, 5 January 2015 at 03:33:15 UTC, Mike wrote:
> On Sunday, 4 January 2015 at 17:25:49 UTC, Martin Nowak wrote:
>
>> Exceptions on MC sounds like a bad idea,
>
> That is a bias of old.  It is entirely dependent on the application.  Many modern uses of microcontrollers are not hard real-time, and while my work was primarily on ARM microcontrollers, my previous comments were about using D for bare-metal and systems programming in general.
>
>> Last time I build an embedded ARM project the resulting D binary was as small as the C++ one.
>
> Yes, my "Hello World!" was 56 bytes, but, it's not only about getting something to work.
>
>> A group of people that builds the infrastructure is needed.
>>
>> I can't strictly follow your conclusion, that half of the language needs to be change.
>> The only thing I needed to do last time, was to disable ModuleInfo generation in the compiler.
>
> My conclusion is not that half the language needs to change.  As I said in a previous post, the changes needed are likely few, but fundamental, and can't be implemented in infrastructure alone if you want the result to be more than "Hey, I got it to work".
>
> The original thread prompting this discussion was about having a bare-metal GSOC project.  As I and others have shown, such a project is possible, interesting, entertaining and educational, but it will always be just that without language/compiler/toolchain support.
>
> A more worthwhile GSOC project would be to add those few, yet fundamental, language/compiler/toolchain changes to make the experience feel like the language was designed with intent for the purpose of systems programming.  But I don't think that will be of much interest to embedded/kernel/bare-metal programmers, but rather more for those with an interest in language and compiler design.
>
> Mike

Personally I would chose Netduino and MicroEJ capable boards if I ever do any electronics again as hobby.

Given your experience wouldn't D be capable to target such systems as well?

..
Paulo

On Saturday, 3 January 2015 at 16:17:44 UTC, Mathias LANG wrote:
> On Wednesday, 31 December 2014 at 03:25:53 UTC, Craig Dillabaugh wrote:
>> I was hoping folks to take a brief break from bickering about features, and arguing over which posters have been naughty, and which have been nice, to get a bit of input on our 2015 Google Summer of Code Proposal  ... :o)
>
> Thanks for doing this, we definitely need more manpower.
> I would be willing to mentor something related to Vibe.d, however I don't have anything to propose ATM. Bt if you find something, feel free to email me.
>
> There was a discussion about redesigning the dlang.org. It looks like there's some WIP ( https://github.com/w0rp/new-dlang.org ), but I didn't follow the discussion closely enough (and it's now around 400 posts).
> Could it be a possible project, provided that such project would have to be done in D ?

Rikki wants to do D web development (see this thread), and his
project is using Vibe D.  Perhaps you can check it out.  Do you
think you might be interested in serving as the backup mentor for
that one?

As for the web page, that would possibly be a tough sell to Google
if they consider it more of a 'documentation' project than a
'coding' project, since they explicitly state that documentation
projects are not allowed (I was considering suggesting a Phobos
documentation project submission, so did a bit of research on that).

However, there has been some talk of improvements to DDOC around here,
maybe something could be cooked up there ... we still have a bit
more than a month to get projects lined up.

On 01/05/2015 04:50 AM, Mike wrote:
> Exactly, that's good example.

Can we please file those as betterC bugs in https://issues.dlang.org/.
If we sort those out, it will be much easier next time.

On 01/05/2015 04:38 AM, Mike wrote:
> I forgot to mention in my last post your proposal for moving TypeInfo to
> the runtime [1] is also one of the changes I had in mind. It would be an
> excellent start, an important precedent, and would avoid the ridiculous
> TypeInfo-faking hack necessary to get a build.

And again, you have a good chance to convince people that -betterC shouldn't generate TypeInfo.

On 01/05/2015 02:59 AM, Craig Dillabaugh wrote:
> Do you feel the current posting on the Wiki accurately best reflects
> what work needs to be done on this project.

Yeah, it's pretty good.
I've thrown out the hosted ARM project (AFAIK gdc and ldc are almost done) and filled in some details for the bare-metal project.

On Monday, 5 January 2015 at 14:46:25 UTC, Martin Nowak wrote:
> On 01/05/2015 02:59 AM, Craig Dillabaugh wrote:
>> Do you feel the current posting on the Wiki accurately best reflects
>> what work needs to be done on this project.
>
> Yeah, it's pretty good.
> I've thrown out the hosted ARM project (AFAIK gdc and ldc are almost done) and filled in some details for the bare-metal project.

Thanks.

On Monday, 5 January 2015 at 11:38:17 UTC, Paulo  Pinto wrote:
>
> Personally I would chose Netduino and MicroEJ capable boards if I ever do any electronics again as hobby.
>
> Given your experience wouldn't D be capable to target such systems as well?
>

Yes, D is perfectly capable of targeting those boards using GDC and potentially even LDC, although LDC still has a few strange bugs [1].  In fact, with the right hackery, I assume D will generate far better code (smaller and faster) than the .Net Micro Framework or MicroEJ.

Another interesting offering is the Intel Edison/Galileo boards [2].  I'm under the impression that DMD would be able to generate code for those boards as well.  Although those boards are less like microcontrollers and more like micro PCs (e.g. Raspberry Pi, BeagleBone Black)

As a hobby, I highly recommend anyone interested getting themselves a board and trying it out.  The boards are surprisingly inexpensive.  With the right knowledge, it takes very little to get started, and can be quite rewarding to see the hardware "come alive" with your code.

1. Get yourself a GDC cross-compiler [3], and whatever tools are needed to interface a PC to your board (OpenOCD, or vendor-supplied tools).
2. Throw out Phobos and D Runtime, and create a small object.d with a few stubs as your runtime.
4. Write a simple program (e.g. blinky, semi-hosted "hello world" [4])
5. Create a linker script for your board.  This can be difficult the first time as you need an intimate understanding of your hardware and how the compiler generates code.
6. Use OpenOCD or your vendor's tools to upload the binary to your board, and bask in the satisfaction of bringing the board to life.

You won't be able to use classes, dynamic arrays, and a multitude of other language features unless you find a way to implement them in your runtime, but you will be able to write C-like code only with added bonuses like CTFE, templates, and mixins.

I'm sure those that actually take the plunge will find it to be a fun, educational, and rewarding exploration.

Mike

[1] - https://github.com/ldc-developers/ldc/issues/781
[2] - http://www.intel.com/content/www/us/en/do-it-yourself/maker.html
[3] - http://wiki.dlang.org/Bare_Metal_ARM_Cortex-M_GDC_Cross_Compiler
[4] - http://wiki.dlang.org/Minimal_semihosted_ARM_Cortex-M_%22Hello_World%22