View mode: basic / threaded / horizontal-split · Log in · Help
January 22, 2013
Re: Trust about D programming.
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';
January 22, 2013
Re: Trust about D programming.
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!!
January 22, 2013
Re: Trust about D programming.
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!!
January 22, 2013
Re: Trust about D programming.
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';
January 22, 2013
Re: Trust about D programming.
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)
January 22, 2013
Re: Trust about D programming.
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
January 22, 2013
Re: Trust about D programming.
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!!
January 22, 2013
Re: Trust about D programming.
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
January 22, 2013
Re: Trust about D programming.
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!!
January 22, 2013
Re: Trust about D programming.
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.
1 2 3 4
Top | Discussion index | About this forum | D home