<div class="gmail_quote">On 4 February 2012 14:47, Paulo Pinto <span dir="ltr"><<a href="mailto:pjmlp@progtools.org">pjmlp@progtools.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So are you writting your own crt0 startup code?<br></blockquote><div><br></div><div>Absolutely. Most microcontroller based systems will have a custom written init routine.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Are you also creating the code that takes care to validate if there<br>
are atexit() handlers in need to be called after main?<br></blockquote><div><br></div><div>main will never exit on a typical microcontroller implementation.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Are you writing the code that takes care to handle program arguments<br>
and passing them to main() or whatever is your program entry point?<br></blockquote><div><br></div><div>Unlikely. Embedded systems/microcontrollers typically just begin executing when they receive power.</div><div>You probably won't even have main, you just declare a 'void start()' function and make sure to place it at the boot address.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Because if you aren't, then you are using C runtime library no matter what.<br></blockquote><div><br></div>
<div>I've never linked a c runtime to a microcontroller app.</div><div><br></div><div><br></div><div>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.</div>
<div>But D should at least be <i>capable</i> 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.</div>
<div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On <a href="tel:03.02.2012%2020" value="+61302201220" target="_blank">03.02.2012 20</a>:32, Manu wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On 3 February 2012 16:45, Paulo Pinto <<a href="mailto:pjmlp@progtools.org" target="_blank">pjmlp@progtools.org</a><br></div><div class="im">
<mailto:<a href="mailto:pjmlp@progtools.org" target="_blank">pjmlp@progtools.org</a>>> wrote:<br>
<br>
    The only language without runtime is pure assembly.<br>
<br>
<br></div><div class="im">
And C.. there's no requirement to link the CRT in a C app. In fact, in<br>
many of my projects, I don't.<br>
I frequently find that the ONLY function I use from the CRT is<br>
sprintf... which I really should write(/copy) my own version of, so I<br>
can never link a CRT again :P<br>
<br></div><div class="im">
    All high level languages require a runtime library, even C, despite<br>
    what many people think.<br>
<br>
<br></div>
Wrong, the C _language_ depends on NOTHING in the CRT. I prefer to avoid<div class="im"><br>
linking it wherever possible. Strangely enough, I find the 'standard' C<br>
library to be one of the least standard libraries out there, and avoid<br>
it for that reason.<br>
<br></div><div class="im">
    Now in this case what would be nice would be the possibility to<br>
    generate code that runs on top of the arduino without any<br>
    real OS. This is a common use case in embedded systems and here the<br>
    runtime has even an higher value as it takes the<br>
    role of an OS.<br>
<br>
<br></div><div class="im">
All that's required is a toolchain that's capable of producing an exe<br>
without the requirement to link any compulsory library.<br>
<br></div>
    --<br>
    Paulo<br>
    "Manu" <<a href="mailto:turkeyman@gmail.com" target="_blank">turkeyman@gmail.com</a> <mailto:<a href="mailto:turkeyman@gmail.com" target="_blank">turkeyman@gmail.com</a>>> wrote in<div class="im">
<br>
    message news:mailman.312.1328277504.<u></u>25230.digitalmars-d@puremagic.<u></u>com...<br>
    On 3 February 2012 15:37, Alex_Dovhal <<a href="mailto:alex_dovhal@yahoo.com" target="_blank">alex_dovhal@yahoo.com</a><br></div>
    <mailto:<a href="mailto:alex_dovhal@yahoo.com" target="_blank">alex_dovhal@yahoo.com</a>><u></u>> wrote:<br>
<br>
        __<br>
         >Andrea Fontana" <<a href="mailto:advmail@katamail.com" target="_blank">advmail@katamail.com</a><div class="im"><br>
        <mailto:<a href="mailto:advmail@katamail.com" target="_blank">advmail@katamail.com</a>>> wrote:<br>
         >In this case can we hope for a d frontend?<br>
        That depends if it's MCU or MPU. If it will be MCU(like<br>
        ARM7TDMI), which means Harvard Architecture (where Program code<br>
        and RAM are physically different). Also internal RAM of a few KB<br>
        and no Linux.<br>
        If it'll be MCU then it can have Linux OS, so theoretically it<br>
        can have GDC ported.<br>
<br>
    Eh? Why would GDC depend on linux at all? If you disable the GC (and<br>
    dependent language functionality), and manage to do something about<br>
    the horrible exe bloat, there's no reason it shouldn't be able to<br>
    target anything...<br>
    The obvious advantage over C is the syntax features. Clearly D as a<br>
    *language* shouldn't DEPEND on the druntime, other than some<br>
    language features that imply GC, like dynamic arrays/etc.<br>
    Is the toolchain not capable of producing a working exe without<br>
    linking any library? Surely you can write a totally raw app with no<br>
    libs at all? (assuming you avoid language features that make<br>
    implicit druntime calls)<br>
<br>
<br>
</div></blockquote>
<br>
</blockquote></div><br>