On 22 January 2013 13:43, Freddie Chopin <freddie_chopin@op.pl> wrote:

> On Tuesday, 22 January 2013 at 13:37:38 UTC, deadalnix wrote:
>
>> What is the problem with gdc ? I used to use it for ages.
>>
>
> Have you tried compiling it for something like bare-metal ARM (arm-none-eabi target)? Check the thread about embedded D in the GDC (D.GNU) forum to see what problems exist when you want to compile that for an OS-less target that doesn't provide hundreds of POSIX functions.
>
> Do note that embedded does not mean "smartphone with Android".
>
> When GDC will be part of GCC a proper support for other platforms will probably appear, not only for PC with Windows/Linux/MacOS.
>
> 4\/3!!
>

That's a common misconception.  Other platform support are already appearing (ARM, MIPS, PPC), it just requires users who have the hardware and knowledge to port the D runtime over.


Regards,
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Tuesday, 22 January 2013 at 13:50:51 UTC, Iain Buclaw wrote:
> That's a common misconception.  Other platform support are already
> appearing (ARM, MIPS, PPC), it just requires users who have the hardware
> and knowledge to port the D runtime over.

That's what I meant (; A small misunderstanding [;

4\/3!!

Well, "porting druntime" is not exactly the thing I can call "support from GDC", it is somewhat orthogonal from compiler.

On Tuesday, 22 January 2013 at 13:55:05 UTC, Freddie Chopin wrote:
> On Tuesday, 22 January 2013 at 13:50:51 UTC, Iain Buclaw wrote:
>> That's a common misconception.  Other platform support are already
>> appearing (ARM, MIPS, PPC), it just requires users who have the hardware
>> and knowledge to port the D runtime over.
>
> That's what I meant (; A small misunderstanding [;
>
> 4\/3!!

On 22 January 2013 14:02, mist <none@none.none> wrote:

> Well, "porting druntime" is not exactly the thing I can call "support from GDC", it is somewhat orthogonal from compiler.
>
>
>
I could argue the toss, but I'm instead going to have talk about why you are wrong... in May perhaps... :o)


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

Please do, looking forward to watching video about how I am wrong :)

On Tuesday, 22 January 2013 at 14:29:11 UTC, Iain Buclaw wrote:
> On 22 January 2013 14:02, mist <none@none.none> wrote:
>
>> Well, "porting druntime" is not exactly the thing I can call "support from
>> GDC", it is somewhat orthogonal from compiler.
>>
>>
>>
> I could argue the toss, but I'm instead going to have talk about why you
> are wrong... in May perhaps... :o)

On Tuesday, 22 January 2013 at 13:36:15 UTC, Freddie Chopin wrote:
> On Tuesday, 22 January 2013 at 11:41:14 UTC, Sergei Nosov wrote:
>> But for embedded programming I don't think D is a good practical choice. C and C++ shines there and I don't think things are changing soon.
>
> It would be a shame if D would be PC-only... Maybe when GDC will be ready things will change - who knows... Apart from the garbage collector, which really is not embedded-friendly (I'm talking about kilobytes of RAM, not megabytes) everything sounds quite OK in the specs (;
>
> 4\/3!!

Ah, you mean something like Astrobe, an Oberon compiler for
the ARM Cortex-M3 and NXP LPC2000 micro-controlers?

http://www.astrobe.com/default.htm

Presentation from the 2011 Oberon days,

http://www.oberonday2011.ethz.ch/talks/armembedded.pdf

It is possible to do C free development in embedded systems, using system programming languages with GC.

There are of course embedded systems, where the only way to program is either Assembly or a crippled down version of C due to hardware constraints.

However, if the hardware is able to execute full ANSI C code, then there are other options becoming available.

It is just a matter to get a more widespread acceptance.

--
Paulo

On Tuesday, 22 January 2013 at 15:42:04 UTC, Paulo Pinto wrote:
> It is possible to do C free development in embedded systems, using system programming languages with GC.

Instead of just ditching C or C++ for something related to Delphi, it would be nicer to use D, as it's multithreading options look quite nice (;

> There are of course embedded systems, where the only way to program is either Assembly or a crippled down version of C due to hardware constraints.

Well, a typical ARM Cortex-M3 is not THAT crippled, it just does not have that much RAM to waste - rarely there's more than 64kB, usually less than 32kB...

> However, if the hardware is able to execute full ANSI C code, then there are other options becoming available.

Well, it's not about "full ANSI C", because you could do that on 8051 30 years ago... it just the matter of:
a. RAM usage
b. heap usage
c. real-time constraints

For a typical ARM bare-metal microcontroller C++ exceptions are a-bit-too-much (taking ~60kB of flash code when almost not used, and 60kB quite often would be 95% of available code memory, but in more common cases 25-50%), in D these are probably inevitable and I could live with that (; But I just cannot imagine a GC on a microcontroller that has so little RAM and which has to do something in real-time - you probably will just get annoyed if an app on PC freezes for a second, but if a 100-tonne crane controller freezes for that time it can end really bad (;

Yes, GC and dynamic memory is really cool, but it costs just a lot of RAM... You can sometimes live with mallocs() (but modestly used), yet I cannot imaging GC in so small memory. It can be easily assumed that such applications don't do a lot of memory allocation at run-time (usually none), so the GC would just waste time and memory...

> It is just a matter to get a more widespread acceptance.

I think it's just a matter of realistic expectations (; A LOT (and I really mean that) people think that ARM based microcontrollers are an overkill for most of the tasks, so you'll just not convince them to use an even more expensive chip, which has 4x the amount of RAM just to use "a fancy language".

And do remember we're not talking about routers and smartphones that have 128MB of RAM, but rather about home automation systems, some industrial controllers (but not HMI with a fancy GUI, but the devices that really do the monitoring and control), maybe some electronics embedded in toys (RC models etc.).

4\/3!!

Am 22.01.2013 17:19, schrieb Freddie Chopin:
> On Tuesday, 22 January 2013 at 15:42:04 UTC, Paulo Pinto wrote:
>> It is possible to do C free development in embedded systems, using
>> system programming languages with GC.
>
> Instead of just ditching C or C++ for something related to Delphi, it
> would be nicer to use D, as it's multithreading options look quite nice (;

Sure, I was actually trying to point out the existence of strong type languages for (some type) of embedded development.

It would be surely nice to use something like D.

>
>> There are of course embedded systems, where the only way to program is
>> either Assembly or a crippled down version of C due to hardware
>> constraints.
>
> Well, a typical ARM Cortex-M3 is not THAT crippled, it just does not
> have that much RAM to waste - rarely there's more than 64kB, usually
> less than 32kB...
>
>> However, if the hardware is able to execute full ANSI C code, then
>> there are other options becoming available.
>
> Well, it's not about "full ANSI C", because you could do that on 8051 30
> years ago... it just the matter of:
> a. RAM usage
> b. heap usage
> c. real-time constraints

I had PIC micro-controlers with memory in the order of bytes, when I wrote that.

If I am not mistaken, many of the C compilers for such environments are limited on what is actually possible to use from ANSI C.

There was an assembler from TI which looked like C control flow with intrinsics, but I am no longer able to find the information.


>
> For a typical ARM bare-metal microcontroller C++ exceptions are
> a-bit-too-much (taking ~60kB of flash code when almost not used, and
> 60kB quite often would be 95% of available code memory, but in more
> common cases 25-50%), in D these are probably inevitable and I could
> live with that (; But I just cannot imagine a GC on a microcontroller
> that has so little RAM and which has to do something in real-time - you
> probably will just get annoyed if an app on PC freezes for a second, but
> if a 100-tonne crane controller freezes for that time it can end really
> bad (;

Agreed.

>
> Yes, GC and dynamic memory is really cool, but it costs just a lot of
> RAM... You can sometimes live with mallocs() (but modestly used), yet I
> cannot imaging GC in so small memory. It can be easily assumed that such
> applications don't do a lot of memory allocation at run-time (usually
> none), so the GC would just waste time and memory...

True, although in my naïve opinion, I would expect such systems to still be developed in Assembly.

>
>> It is just a matter to get a more widespread acceptance.
>
> I think it's just a matter of realistic expectations (; A LOT (and I
> really mean that) people think that ARM based microcontrollers are an
> overkill for most of the tasks, so you'll just not convince them to use
> an even more expensive chip, which has 4x the amount of RAM just to use
> "a fancy language".

Yes, I know the issues of a few cents per unit might imply.

>
> And do remember we're not talking about routers and smartphones that
> have 128MB of RAM, but rather about home automation systems, some
> industrial controllers (but not HMI with a fancy GUI, but the devices
> that really do the monitoring and control), maybe some electronics
> embedded in toys (RC models etc.).
>
> 4\/3!!

Faire enough, I guess even C has issues on those systems right?

Thanks for the comprehensive post,
Paulo

On Tuesday, 22 January 2013 at 18:14:30 UTC, Paulo Pinto wrote:
> If I am not mistaken, many of the C compilers for such environments are limited on what is actually possible to use from ANSI C.

From what I've heard D is 32- and 64-bits only, so that actually leaves things like ARM, MIPS, AVR32 and such cores, these usually have really good GCC support, so I guess there are no "special" limits... It also depends on what you mean by "ANSI C" - for example for ARM, GCC and newlib's libc you basically have everything [; Things that are "OS-dependent" - like malloc(), stdio functions (printf(), ...) and stuff like that require you to provide "re-targeting syscalls" (like sbrk(), write(), read(), ...) but that's not a big issue [;

You basically have whole libstdc++ too (from GCC), with all the templates, containers, iterators and stuff, plus typical C++ stuff - exceptions, RTTI, new, delete etc. - some of these things depend on the syscalls I mentioned above, some of these features take just too much memory [;

So I guess that 32-bit microcontrollers are really standards-compliant! (;

> True, although in my naïve opinion, I would expect such systems to still be developed in Assembly.

Do you mean controllers for 100-tonne crane of maybe just "general embedded microcontroller"? I guess that no one would go so low for things that can be done in C with a cheap chip like Cortex-M0 [;

> Faire enough, I guess even C has issues on those systems right?

If we stick to ARM (like Cortex-M3) there are no issues other than memory limitations, and it generally concerns mostly RAM, as code memory is usually big enough (hundreds of kB usually, up to 512kB, sometimes 1MB). That's why you cannot get too fancy with your code, and - unfortunately - most of nice programming "tricks" are dynamic-memory-only...

On the other hand, maybe I should ask what do you consider "an issue"? There's definitely nothing "non-standard" in the C/C++ that you use here - there's just no OS (but you can have an RTOS - scheduler), no POSIX (but there are POSIX-like RTOSes) and not-a-lot of RAM (there's no library for fixing that [; ).

4\/3!!

C requirements are extremely low. With only a couple of standard library functions (I think memcpy() and memcmp()) gcc starts to generate viable code. You can code on bare metal out of the box.
D 'flyes' much higher - it uses a whole runtime, and requires OS services. Of course there are ways to adapt D to bare metal, but C was born adapted.
But, for coding on top of fully fledged OS, looks like D is a good choice.