On processors for D

[Sean Kelly]

Fredrik Olsson wrote:
> Walter Bright skrev:
>> Georg Wrede wrote:
>>> I admit this is a "feelings based" thing with most people I've talked 
>>> with. It seems that on embedded platforms, many expect to write all 
>>> the needed code themselves. It's also felt (possibly unduely??) that 
>>> Phobos (or whatever general Win+*nix standard library) is mostly 
>>> useless in embedded applications.
>>
>> I'd like to get to the bottom of this feeling. For example, Kris was 
>> unhappy that typeinfo imported std.strings. I can't figure out what 
>> the problem with that is.
>>
> I think it is the perceived bloat, not what is in practice done. 
> Importing std.string while only using a single function still gives the 
> impression of needing the whole module.

As I don't do much embedded programming, the issue for me is somewhat 
different, though the goals are similar: I want there to be a clean 
separation or clearly defined interaction between the runtime and 
standard library code to allow for the link-time integration of 
third-party standard libraries and garbage collectors.  I have little 
problem with using C library calls in the runtime however, as I see that 
as largely unavoidable.  Rather, my primary concern is that the runtime 
should not have any compile-time dependencies on standard library or GC 
code.

> Perhaps having a module scope of hmm... sys where typeinfo, object and 
> anything needed by compiler, and runtime resides is a good idea. Totally 
> forbid anything in "sys" to import/depend on anything from the outside. 
> That way there would be no question for anyone about "how much is safe 
> to strip"?

See Ares for another possible solution.

> And besides, is it wise to depend on what a linker "should do"? If 
> current build chain nicely throws out what is not needed, does that make 
> it right to assume that all build chains should behave as such?

I think this is a reasonable assumption, as to do otherwise necessitates 
design compromises to keep modules as small and isolated as possible. 
And while this may be reasonable for small projects, I can't see it 
working very well for large ones.

> As I see it each module in std should be as self contained as ever 
> possible. I know the std.date I proposed imports std.conv, std.stdio, 
> std.string and std.c.time, but my intent is to not import any of them 
> when finished.

Again, I don't see much of a problem with calling C library functions in 
general, though I would prefer not doing so if it brings in an entire 
subsystem that is unrelated to anything done by the client code.

> But then my intention was never to bring up the internals to much 
> debate, I wanted to have input on the externals, how you as developers 
> use the code. That was perhaps futile, but I still think my approach of 
> a few but flexible, and overloaded functions is the best approach.

That leaves a lot of room for interpretation, but I tenatively agree.


Sean