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.

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

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.

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

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

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

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

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

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?

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