The only language without runtime is pure assembly.

All high level languages require a runtime library, even C, despite what many people think.

Now in this case what would be nice would be the possibility to generate code that runs on top of the arduino without any
real OS. This is a common use case in embedded systems and here the runtime has even an higher value as it takes the
role of an OS.

--
Paulo

"Manu" <turkeyman@gmail.com> wrote in message news:mailman.312.1328277504.25230.digitalmars-d@puremagic.com... On 3 February 2012 15:37, Alex_Dovhal <alex_dovhal@yahoo.com> wrote:

  >Andrea Fontana" <advmail@katamail.com> wrote:
  >In this case can we hope for a d frontend?

  That depends if it's MCU or MPU. If it will be MCU(like ARM7TDMI), which means Harvard Architecture (where Program code and RAM are physically different). Also internal RAM of a few KB and no Linux.
  If it'll be MCU then it can have Linux OS, so theoretically it can have GDC ported.

Eh? Why would GDC depend on linux at all? If you disable the GC (and dependent language functionality), and manage to do something about the horrible exe bloat, there's no reason it shouldn't be able to target anything...
The obvious advantage over C is the syntax features. Clearly D as a *language* shouldn't DEPEND on the druntime, other than some language features that imply GC, like dynamic arrays/etc.

Is the toolchain not capable of producing a working exe without linking any library? Surely you can write a totally raw app with no libs at all? (assuming you avoid language features that make implicit druntime calls)

One can use C without an OS on any of the Atmel microcontroller range... why would D need an OS to support it?

On Sat, Feb 4, 2012 at 12:45 AM, Paulo Pinto <pjmlp@progtools.org> wrote:

>   The only language without runtime is pure assembly.
>
> All high level languages require a runtime library, even C, despite what many people think.
>
> Now in this case what would be nice would be the possibility to generate
> code that runs on top of the arduino without any
> real OS. This is a common use case in embedded systems and here the
> runtime has even an higher value as it takes the
> role of an OS.
>
> --
> Paulo
>
>  "Manu" <turkeyman@gmail.com> wrote in message
> news:mailman.312.1328277504.25230.digitalmars-d@puremagic.com...
>  On 3 February 2012 15:37, Alex_Dovhal <alex_dovhal@yahoo.com> wrote:
>
>> **
>> >Andrea Fontana" <advmail@katamail.com> wrote:
>>  >In this case can we hope for a d frontend?
>> That depends if it's MCU or MPU. If it will be MCU(like ARM7TDMI), which
>> means Harvard Architecture (where Program code and RAM are physically
>> different). Also internal RAM of a few KB and no Linux.
>> If it'll be MCU then it can have Linux OS, so theoretically it can have
>> GDC ported.
>>
>
> Eh? Why would GDC depend on linux at all? If you disable the GC (and
> dependent language functionality), and manage to do something about the
> horrible exe bloat, there's no reason it shouldn't be able to target
> anything...
> The obvious advantage over C is the syntax features. Clearly D as a
> *language* shouldn't DEPEND on the druntime, other than some language
> features that imply GC, like dynamic arrays/etc.
>
> Is the toolchain not capable of producing a working exe without linking any library? Surely you can write a totally raw app with no libs at all? (assuming you avoid language features that make implicit druntime calls)
>

On 3 February 2012 10:36, Alex Rønne Petersen <xtzgzorex@gmail.com> wrote:
> On 03-02-2012 11:33, Andrea Fontana wrote:
>>
>> How much work is needed to support atmel in your opinion?
>>
>> Il giorno ven, 03/02/2012 alle 10.40 +0100, Alex Rønne Petersen ha scritto:
>>>
>>> On 03-02-2012 09:47, Andrea Fontana wrote:
>>> >  Is it possible to compile for avr (atmel) platform using gdc? It would  be interesting for arduino development...
>>>
>>> Not currently. We don't even have a standard version identifier for that platform.
>>>
>>> --
>>> - Alex
>>
>>
>
> I'm not really qualified to say. Iain?
>
> --
> - Alex

In the event that we can't match the platform / cpu to a pre-defined identifier, we just emit what the configure scripts tell us.

So, for CPU-VENDOR-TARGET, gdc would emit CPU and TARGET as version identifiers.


-- 
Iain Buclaw

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

On 3 February 2012 08:47, Andrea Fontana <advmail@katamail.com> wrote:
> Is it possible to compile for avr (atmel) platform using gdc? It would be interesting for arduino development...

gdc actually asserts that the target it is building for is either 32bit or 64bit, anything greater or less than will fail to compile anything with a solid ICE.

For Arduino, it was my understanding that development uses neither C or C++ -  something more of an abstract C-like language, unless I'm thinking of NViDIA CUDA...


-- 
Iain Buclaw

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

On 3 February 2012 16:45, Paulo Pinto <pjmlp@progtools.org> wrote:

>   The only language without runtime is pure assembly.
>

And C.. there's no requirement to link the CRT in a C app. In fact, in many
of my projects, I don't.
I frequently find that the ONLY function I use from the CRT is sprintf...
which I really should write(/copy) my own version of, so I can never link a
CRT again :P

All high level languages require a runtime library, even C, despite what
> many people think.
>

Wrong, the C *language* depends on NOTHING in the CRT. I prefer to avoid linking it wherever possible. Strangely enough, I find the 'standard' C library to be one of the least standard libraries out there, and avoid it for that reason.

Now in this case what would be nice would be the possibility to generate
> code that runs on top of the arduino without any
> real OS. This is a common use case in embedded systems and here the
> runtime has even an higher value as it takes the
> role of an OS.
>

All that's required is a toolchain that's capable of producing an exe without the requirement to link any compulsory library.

--
> Paulo
>
>  "Manu" <turkeyman@gmail.com> wrote in message
> news:mailman.312.1328277504.25230.digitalmars-d@puremagic.com...
>  On 3 February 2012 15:37, Alex_Dovhal <alex_dovhal@yahoo.com> wrote:
>
>> **
>> >Andrea Fontana" <advmail@katamail.com> wrote:
>>  >In this case can we hope for a d frontend?
>> That depends if it's MCU or MPU. If it will be MCU(like ARM7TDMI), which
>> means Harvard Architecture (where Program code and RAM are physically
>> different). Also internal RAM of a few KB and no Linux.
>> If it'll be MCU then it can have Linux OS, so theoretically it can have
>> GDC ported.
>>
>
> Eh? Why would GDC depend on linux at all? If you disable the GC (and
> dependent language functionality), and manage to do something about the
> horrible exe bloat, there's no reason it shouldn't be able to target
> anything...
> The obvious advantage over C is the syntax features. Clearly D as a
> *language* shouldn't DEPEND on the druntime, other than some language
> features that imply GC, like dynamic arrays/etc.
>
> Is the toolchain not capable of producing a working exe without linking any library? Surely you can write a totally raw app with no libs at all? (assuming you avoid language features that make implicit druntime calls)
>

On 3 February 2012 19:32, Manu <turkeyman@gmail.com> wrote:
> On 3 February 2012 16:45, Paulo Pinto <pjmlp@progtools.org> wrote:
>>
>> The only language without runtime is pure assembly.
>
>
> And C.. there's no requirement to link the CRT in a C app. In fact, in many
> of my projects, I don't.
> I frequently find that the ONLY function I use from the CRT is sprintf...
> which I really should write(/copy) my own version of, so I can never link a
> CRT again :P
>
>> All high level languages require a runtime library, even C, despite what many people think.
>
>
> Wrong, the C language depends on NOTHING in the CRT. I prefer to avoid linking it wherever possible. Strangely enough, I find the 'standard' C library to be one of the least standard libraries out there, and avoid it for that reason.
>

When building without -nostdlib, the compiler can make some assumptions on the fact that it is being linked to libc.  I'm not sure if it is still the case, but I've seen Linux devs work around areas where gcc will implicitly put in calls to memcpy on some rather costly copy assignments.

-- 
Iain Buclaw

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

On Fri, 03 Feb 2012 17:13:04 +0100, Iain Buclaw <ibuclaw@ubuntu.com> wrote:

> On 3 February 2012 08:47, Andrea Fontana <advmail@katamail.com> wrote:
>> Is it possible to compile for avr (atmel) platform using gdc? It would be
>> interesting for arduino development...
It's unlikely that D will run on systems without a MMU.

>
> gdc actually asserts that the target it is building for is either
> 32bit or 64bit, anything greater or less than will fail to compile
> anything with a solid ICE.
>
> For Arduino, it was my understanding that development uses neither C
> or C++ -  something more of an abstract C-like language, unless I'm
> thinking of NViDIA CUDA...
>
It uses C++.

On 3 February 2012 23:15, Martin Nowak <dawg@dawgfoto.de> wrote:

> On Fri, 03 Feb 2012 17:13:04 +0100, Iain Buclaw <ibuclaw@ubuntu.com> wrote:
>
>  On 3 February 2012 08:47, Andrea Fontana <advmail@katamail.com> wrote:
>>
>>> Is it possible to compile for avr (atmel) platform using gdc? It would be interesting for arduino development...
>>>
>> It's unlikely that D will run on systems without a MMU.


Why?
It just compiles code. Why should it require dependence on anything?

Am Fri, 3 Feb 2012 21:32:21 +0200
schrieb Manu <turkeyman@gmail.com>:

> 
> All that's required is a toolchain that's capable of producing an exe without the requirement to link any compulsory library.

I'm not sure, but I think the D compilers currently depend on druntime. AFAIK you'll need at very least a object.di with certain stuff and I'm not sure if array ops / gc functions are required if you don't use them. Shouldn't be too much work to change that though.

So are you writting your own crt0 startup code?

Are you also creating the code that takes care to validate if there
are atexit() handlers in need to be called after main?

Are you writing the code that takes care to handle program arguments
and passing them to main() or whatever is your program entry point?

Because if you aren't, then you are using C runtime library no matter what.

--
Paulo


On 03.02.2012 20:32, Manu wrote:
> On 3 February 2012 16:45, Paulo Pinto <pjmlp@progtools.org
> <mailto:pjmlp@progtools.org>> wrote:
>
>     The only language without runtime is pure assembly.
>
>
> And C.. there's no requirement to link the CRT in a C app. In fact, in
> many of my projects, I don't.
> I frequently find that the ONLY function I use from the CRT is
> sprintf... which I really should write(/copy) my own version of, so I
> can never link a CRT again :P
>
>     All high level languages require a runtime library, even C, despite
>     what many people think.
>
>
> Wrong, the C _language_ depends on NOTHING in the CRT. I prefer to avoid
> linking it wherever possible. Strangely enough, I find the 'standard' C
> library to be one of the least standard libraries out there, and avoid
> it for that reason.
>
>     Now in this case what would be nice would be the possibility to
>     generate code that runs on top of the arduino without any
>     real OS. This is a common use case in embedded systems and here the
>     runtime has even an higher value as it takes the
>     role of an OS.
>
>
> All that's required is a toolchain that's capable of producing an exe
> without the requirement to link any compulsory library.
>
>     --
>     Paulo
>     "Manu" <turkeyman@gmail.com <mailto:turkeyman@gmail.com>> wrote in
>     message news:mailman.312.1328277504.25230.digitalmars-d@puremagic.com...
>     On 3 February 2012 15:37, Alex_Dovhal <alex_dovhal@yahoo.com
>     <mailto:alex_dovhal@yahoo.com>> wrote:
>
>         __
>          >Andrea Fontana" <advmail@katamail.com
>         <mailto:advmail@katamail.com>> wrote:
>          >In this case can we hope for a d frontend?
>         That depends if it's MCU or MPU. If it will be MCU(like
>         ARM7TDMI), which means Harvard Architecture (where Program code
>         and RAM are physically different). Also internal RAM of a few KB
>         and no Linux.
>         If it'll be MCU then it can have Linux OS, so theoretically it
>         can have GDC ported.
>
>     Eh? Why would GDC depend on linux at all? If you disable the GC (and
>     dependent language functionality), and manage to do something about
>     the horrible exe bloat, there's no reason it shouldn't be able to
>     target anything...
>     The obvious advantage over C is the syntax features. Clearly D as a
>     *language* shouldn't DEPEND on the druntime, other than some
>     language features that imply GC, like dynamic arrays/etc.
>     Is the toolchain not capable of producing a working exe without
>     linking any library? Surely you can write a totally raw app with no
>     libs at all? (assuming you avoid language features that make
>     implicit druntime calls)
>
>