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.

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...

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.

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.

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.

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)

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)

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)

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.
--

>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)

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)

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)

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';

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...

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';

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...

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*?

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

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.