On processors for D ~ decoupling

[Georg Wrede]

Walter Bright wrote:
> kris wrote:
> 
>> Yes, that's correct. But typeinfo is a rather rudimetary part of the 
>> language support. Wouldn't you agree? If I, for example, declare an 
>> array of 10 bytes (static byte[10]) then I'm bound over to import 
>> std.string ~ simply because TypeInfo_StaticArray wants to use 
>> std.string.toString(int), rather than the C library version of itoa() 
>> or a "low-level support" version instead.
> 
> 
> It has nothing to do with having a static byte[10] declaration. For the 
> program:
> 
> void main()
> {
>     static byte[10] b;
> }
> 
> The only things referenced by the object file are _main, __acrtused_con, 
> and __Dmain. You can verify this by running obj2asm on the output, which 
> gives:

> 
> It's just not a big deal. Try the following:
> 
> extern (C) int printf(char* f, ...) { return 0; }
> 
> void main()
> {
>     static byte[10] b;
> }
> 
> and compare the difference in exe file sizes, with and without the 
> printf stub.
> 
> 
>>> printf doesn't pull in the floating point library (I went to a lot of 
>>> effort to make that so!). It does pull in the C IO library, which is 
>>> very hard to not pull in (there always seems to be something 
>>> referencing it). It shouldn't pull in the C wide character stuff. D's 
>>> IO (writefln) will pull in C's IO anyway, so the only thing extra is 
>>> the integer version of the specific printf code (about 4K).
>>
>> How can it convert %f, %g and so on if it doesn't use FP support at all? 
> 
> 
> It's magic! Naw, it's just that if you actually use floating point in a 
> program, the compiler emits a special extern reference (to __fltused) 
> which pulls in the floating point IO formatting code. Otherwise, it 
> defaults to just a stub. Try it.
> 
>> Either way, it's not currently possible to build a D program without a 
>> swathe of FP support code,
>> printf,
>> the entire C IO package,
>> wide-char support,
>> and a whole lot more besides. I'd assumed the linked FP support was 
>> for printf, but perhaps it's for std.string instead? I've posted the 
>> linker maps (in the past) to illustrate exactly this.
> 
> 
> My point is that assuming what is pulled in by what is about as reliable 
> as guessing where the bottlenecks in one's code is.