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
