www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Gdc & avr

reply Andrea Fontana <advmail katamail.com> writes:
Is it possible to compile for avr (atmel) platform using gdc? It would
be interesting for arduino development...
Feb 03 2012
next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
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
Feb 03 2012
parent reply Andrea Fontana <advmail katamail.com> writes:
How much work is needed to support atmel in your opinion?

Il giorno ven, 03/02/2012 alle 10.40 +0100, Alex R=C3=B8nne 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...


=20
 Not currently. We don't even have a standard version identifier for that=


=20

 platform.
=20
 --
 - Alex
Feb 03 2012
parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
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
Feb 03 2012
parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 3 February 2012 10:36, Alex R=F8nne 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=F8nne Petersen ha
 scritto:

 On 03-02-2012 09:47, Andrea Fontana wrote:

 =A0Is it possible to compile for avr (atmel) platform using gdc? It w=








ould

 =A0be interesting for arduino development...


 Not currently. We don't even have a standard version identifier for tha=






t

 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 identif=
iers.


--=20
Iain Buclaw

*(p < e ? p++ : p) =3D (c & 0x0f) + '0';
Feb 03 2012
prev sibling next sibling parent reply "Alex_Dovhal" <alex_dovhal yahoo.com> writes:
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

"Andrea Fontana" <advmail katamail.com> wrote:

Is it possible to compile for avr (atmel) platform using gdc? It would =


be interesting for arduino development...=20

AVR is 8-bit harward architecture while D is designed for at least 32 =
bits. Besides that AVR's have from (less then 1) to (a few) kB of RAM so =
it needs another standard library with no GC. Guess that's a lot of =
work, so don't expect it any time soon even if someone will try to =
implement it.
Feb 03 2012
next sibling parent reply Manu <turkeyman gmail.com> writes:
On 3 February 2012 13:34, Alex_Dovhal <alex_dovhal yahoo.com> wrote:


 **
 "Andrea Fontana" <advmail katamail.com> wrote:

Is it possible to compile for avr (atmel) platform using gdc? It would be


 interesting for arduino development...

 AVR is 8-bit harward architecture while D is designed for at least 32
 bits. Besides that AVR's have from (less then 1) to (a few) kB of RAM so it
 needs another standard library with no GC. Guess that's a lot of work, so
 don't expect it any time soon even if someone will try to implement it.


I think you'll find that most arduino projects are using a much more
capable avr chip, probably avr32 chips.
I wouldn't expect D will ever work well on 16bit microcontrollers, but on
32bit avr's I can't see any reason from my (limited) experience why the
toolchain wouldn't just build and work out of the box (at least under
linux).
You'll basically need to write the runtime yourself. If you avoid the GC
and OS stuff, you can basically stub out phobos, and you might be able to
run raw code quite easily...
Feb 03 2012
next sibling parent "Alex_Dovhal" <alex_dovhal yahoo.com> writes:
"Manu" <turkeyman gmail.com> wrote:
I think you'll find that most arduino projects are using a much more 
capable avr chip, probably avr32 chips.


Never actually used arduino, but it's site and wikipedia mentiones 8-bit 
devices http://en.wikipedia.org/wiki/Arduino .
Here also http://arduino.cc/en/Main/Hardware - all PCB contain 8-bit 
devices.
Feb 03 2012
prev sibling parent "Alex_Dovhal" <alex_dovhal yahoo.com> writes:
"Manu" <turkeyman gmail.com> wrote:
I think you'll find that most arduino projects are using a much more 
capable avr chip, probably avr32 chips.


Never used Arduino but it's site and wikipedia mentiones only 8-bit AVR's 
http://en.wikipedia.org/wiki/Arduino
Here http://arduino.cc/en/Main/Hardware also all AVR's are 8-bit
Feb 03 2012
prev sibling next sibling parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

There are 32 bit avrs.  Search for 'AVR32'.
  "Alex_Dovhal" <alex_dovhal yahoo.com> wrote in message =
news:jgggnk$2vev$1 digitalmars.com...
  "Andrea Fontana" <advmail katamail.com> wrote:
  >Is it possible to compile for avr (atmel) platform using gdc? It =
would be interesting for arduino development...=20

  AVR is 8-bit harward architecture while D is designed for at least 32 =
bits. Besides that AVR's have from (less then 1) to (a few) kB of RAM so =
it needs another standard library with no GC. Guess that's a lot of =
work, so don't expect it any time soon even if someone will try to =
implement it.
Feb 03 2012
next sibling parent Danni Coy <danni.coy gmail.com> writes:
 Atmel also Arm based 32bit microcontrollers

On Fri, Feb 3, 2012 at 9:44 PM, Daniel Murphy <yebblies nospamgmail.com>wrote:


 **
 There are 32 bit avrs.  Search for 'AVR32'.

 "Alex_Dovhal" <alex_dovhal yahoo.com> wrote in message
 news:jgggnk$2vev$1 digitalmars.com...
 "Andrea Fontana" <advmail katamail.com> wrote:

Is it possible to compile for avr (atmel) platform using gdc? It would be


 interesting for arduino development...

 AVR is 8-bit harward architecture while D is designed for at least 32
 bits. Besides that AVR's have from (less then 1) to (a few) kB of RAM so it
 needs another standard library with no GC. Guess that's a lot of work, so
 don't expect it any time soon even if someone will try to implement it.
Feb 03 2012
prev sibling next sibling parent Danni Coy <danni.coy gmail.com> writes:
also do Arm based 32bit microcontrollers...

On Fri, Feb 3, 2012 at 10:10 PM, Danni Coy <danni.coy gmail.com> wrote:


  Atmel also Arm based 32bit microcontrollers
Feb 03 2012
prev sibling parent reply "Alex_Dovhal" <alex_dovhal yahoo.com> writes:
"Daniel Murphy" <yebblies nospamgmail.com> wrote:

There are 32 bit avrs.  Search for 'AVR32'.


Thanks, I know :) But Arduino uses 8-bit.
Feb 03 2012
next sibling parent Danni Coy <danni.coy gmail.com> writes:
reply but a 32bit version is in the works --
http://arduino.cc/blog/2011/09/17/arduino-launches-new-products-in-maker-faire/

On Fri, Feb 3, 2012 at 10:21 PM, Alex_Dovhal <alex_dovhal yahoo.com> wrote:


 "Daniel Murphy" <yebblies nospamgmail.com> wrote:

There are 32 bit avrs.  Search for 'AVR32'.


 Thanks, I know :) But Arduino uses 8-bit.
Feb 03 2012
prev sibling next sibling parent reply Danni Coy <danni.coy gmail.com> writes:
32bit version will be arm architecture
Feb 03 2012
parent reply Andrea Fontana <advmail katamail.com> writes:
In this case can we hope for a d frontend?

Il giorno ven, 03/02/2012 alle 22.33 +1000, Danni Coy ha scritto:


 32bit version will be arm architecture=20
=20
Feb 03 2012
parent reply "Alex_Dovhal" <alex_dovhal yahoo.com> writes:
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


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.
Feb 03 2012
parent reply Manu <turkeyman gmail.com> writes:
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)
Feb 03 2012
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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)
Feb 03 2012
next sibling parent Danni Coy <danni.coy gmail.com> writes:
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)
Feb 03 2012
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
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)
Feb 03 2012
next sibling parent Johannes Pfau <nospam example.com> writes:
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.
Feb 04 2012
prev sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
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)
Feb 04 2012
next sibling parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
I'll take it you've never actually used c on a small embedded system?

Of course you're doing all those things, if they're needed.  Very low level 
programming in c does not need a runtime at all.
Feb 04 2012
next sibling parent "Alex_Dovhal" <alex_dovhal yahoo.com> writes:
"Daniel Murphy" <yebblies nospamgmail.com> wrote:

 I'll take it you've never actually used c on a small embedded system?

 Of course you're doing all those things, if they're needed.  Very low 
 level programming in c does not need a runtime at all.


Probably you can stub all C runtime initializations. But why? Common C at 
least adjusts stack pointer, generates interrupt jumps/calls table, 
initializes data, clear bss and calls main(), doing this manually wouldn't 
make code shorter.
Feb 04 2012
prev sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On 04.02.2012 13:56, Daniel Murphy wrote:

 I'll take it you've never actually used c on a small embedded system?

 Of course you're doing all those things, if they're needed.  Very low level
 programming in c does not need a runtime at all.


All those things are language runtime according to the Computer Science 
definition, without them your C code won't run.
Feb 04 2012
prev sibling parent Manu <turkeyman gmail.com> writes:
On 4 February 2012 14:47, Paulo Pinto <pjmlp progtools.org> wrote:


 So are you writting your own crt0 startup code?


Absolutely. Most microcontroller based systems will have a custom written
init routine.

Are you also creating the code that takes care to validate if there

 are atexit() handlers in need to be called after main?


main will never exit on a typical microcontroller implementation.

Are you writing the code that takes care to handle program arguments

 and passing them to main() or whatever is your program entry point?


Unlikely. Embedded systems/microcontrollers typically just begin executing
when they receive power.
You probably won't even have main, you just declare a 'void start()'
function and make sure to place it at the boot address.



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


I've never linked a c runtime to a microcontroller app.


All that said, some of the faster arduino systems are reasonably capable,
and have little linux kernels. They might work fine with an adapted
druntime, as long as the exe doesn't bloat, and it doesn't allocate like a
hog.
But D should at least be *capable* of producing a raw exe without any libs
either way. It's just a compiler, there's no technical reason why it
shouldn't, except a few language features that depend on intrinsic library
calls which you would have to avoid.


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)
Feb 04 2012
prev sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
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';
Feb 03 2012
prev sibling parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
Heh, I didn't realize that.  I actually build an fpga clone of atmega64 last 
year and would love to get D compiling on it, but other things tend to take 
priority.

It probably wouldn't be too hard (if you could get the cross compiler 
working) to stub out most of druntime and get it to compile.  The syntax 
improvement would alone would make it a great alternative to c.

"Alex_Dovhal" <alex_dovhal yahoo.com> wrote in message 
news:jggjg1$2i7$3 digitalmars.com...

 "Daniel Murphy" <yebblies nospamgmail.com> wrote:

There are 32 bit avrs.  Search for 'AVR32'.


 Thanks, I know :) But Arduino uses 8-bit.
Feb 03 2012
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Daniel Murphy" <yebblies nospamgmail.com> wrote in message 
news:jggok5$b5i$1 digitalmars.com...

 The syntax improvement would alone would make it a great alternative to c.


Abolutely. I'd love to see a "Lean D" for such uses.
Feb 03 2012
prev sibling parent Andrea Fontana <advmail katamail.com> writes:
That's my point! Arduino use c++, dmd syntax will be a really good
alternative. We just need a subset of druntime and we need to port
arduino/wiring library...

Il giorno sab, 04/02/2012 alle 00.48 +1100, Daniel Murphy ha scritto:


 It probably wouldn't be too hard (if you could get the cross compiler=20
 working) to stub out most of druntime and get it to compile.  The syntax=


=20

 improvement would alone would make it a great alternative to c.
Feb 03 2012
prev sibling parent reply Avr Dude <avr dude.com> writes:
On Friday, 3 February 2012 at 11:34:13 UTC, Alex_Dovhal wrote:

 "Andrea Fontana" <advmail katamail.com> wrote:

Is it possible to compile for avr (atmel) platform using gdc? 
It would be interesting for arduino development...


 AVR is 8-bit harward architecture while D is designed for at 
 least 32 bits. Besides that AVR's have from (less then 1) to (a 
 few) kB of RAM so it needs another standard library with no GC. 
 Guess that's a lot of work, so don't expect it any time soon 
 even if someone will try to implement it.


(Sorry to bump such an old post).

Now that betterC is a thing, it seems like D on avr is much more 
possible. What are your thoughts on using betterC on avr?
Feb 23 2019
parent reply Andrea Fontana <nospam example.org> writes:
On Saturday, 23 February 2019 at 22:16:03 UTC,
On Saturday, 23 February 2019 at 22:16:03 UTC, Avr Dude wrote:

 (Sorry to bump such an old post).

 Now that betterC is a thing, it seems like D on avr is much 
 more possible. What are your thoughts on using betterC on avr?


I'm still waiting for it :)
It would be cool to be able to compile code with d+betterc on 
esp32, for example (and iot is an hot topic in these days)

Andrea
Feb 24 2019
parent Avr Dude <avr dude.com> writes:
On Sunday, 24 February 2019 at 10:37:23 UTC, Andrea Fontana wrote:

 On Saturday, 23 February 2019 at 22:16:03 UTC,
 On Saturday, 23 February 2019 at 22:16:03 UTC, Avr Dude wrote:

 (Sorry to bump such an old post).

 Now that betterC is a thing, it seems like D on avr is much 
 more possible. What are your thoughts on using betterC on avr?


 I'm still waiting for it :)
 It would be cool to be able to compile code with d+betterc on 
 esp32, for example (and iot is an hot topic in these days)

 Andrea


I did some research, and LLVM actually supports avr as a target. 
It shouldn't be too hard to use ldc to output LLVM IR and then 
use llc to output AVR elf.
Feb 24 2019
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
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';
Feb 03 2012
prev sibling next sibling parent "Martin Nowak" <dawg dawgfoto.de> writes:
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++.
Feb 03 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
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?
Feb 03 2012
prev sibling next sibling parent reply "Martin Nowak" <dawg dawgfoto.de> writes:
On Fri, 03 Feb 2012 23:42:39 +0100, Manu <turkeyman gmail.com> wrote:


 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?


Arrays, AA, string switch, array ops, boundary checks, closures, exception  
handling, class factory, module constructors, unittests, RTTI.
Just to name some deeply integrated features that require runtime support  
and or heap allocation. Some of them even rely on GC in their current  
implementation.

Obviously you can compile and link a simple "double add(double a, double  
b) { return a + b; }" without using the runtime.

What's that thing about not using the C runtime? Don't you use malloc,  
atexit, str*?
Feb 04 2012
parent "Nick Sabalausky" <a a.a> writes:
"Martin Nowak" <dawg dawgfoto.de> wrote in message 
news:mailman.9.1328397449.20196.digitalmars-d puremagic.com...

 What's that thing about not using the C runtime? Don't you use malloc, 
 atexit, str*?


That sort of stuff isn't always appropriate on an embedded system.
Feb 04 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
On 5 February 2012 01:17, Martin Nowak <dawg dawgfoto.de> wrote:


 On Fri, 03 Feb 2012 23:42:39 +0100, Manu <turkeyman gmail.com> wrote:

  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?


 Arrays, AA, string switch, array ops, boundary checks, closures, exception
 handling, class factory, module constructors, unittests, RTTI.
 Just to name some deeply integrated features that require runtime support
 and or heap allocation. Some of them even rely on GC in their current
 implementation.

 Obviously you can compile and link a simple "double add(double a, double
 b) { return a + b; }" without using the runtime.

 What's that thing about not using the C runtime? Don't you use malloc,
 atexit, str*?


God no. You just case the appropriate address to some sort of pointer and
manage it however you like.
str*? you mean char*.. Of course you use that, that's a buffer :P
Feb 04 2012
prev sibling parent "Martin Nowak" <dawg dawgfoto.de> writes:
 God no. You just case the appropriate address to some sort of pointer and
 manage it however you like.
 str*? you mean char*.. Of course you use that, that's a buffer :P


strtol et.al.

The bottom line is you can't avoid the CRT/C++RT when you use certain  
language constructs, same goes for D.
Because D incorporates higher level constructs it might be more difficult  
than in C to actually do this.
Feb 04 2012