On processors for D

[Nic Tiger]

Walter Bright wrote:
> This capability of linkers (eliminating unreferenced functions) first 
> appeared in the late 80's, and quickly became standard practice. If 
> you've got a linker that doesn't support that, you're likely to have 
> many other serious problems with it, as D (and C++) depend on other 
> linker features introduced in the late 80's.
> 
> D doesn't require anything of a linker that C++ doesn't already 
> realistically require.

Last 3 years I had to use Microsoft linker (from VS98, VS2003) and it 
really foolish (especially if compared with DMC optimizing linker).

I fulfilled investigations and it seems MS linker uses "hungry" 
algorithm - it wants any extern symbol declared in module, even if it is 
not used, then walk though all objects in libs in search for those 
symbols; meanwhile it includes all data found in that objects. After 
this cycle,  /optref switch tries to drop unreferenced functions - but a 
lot of data get linked in anyway and sometimes this unnecessary data 
references a lot of code.
Most problems we had with static objects of virtual classes - when only 
existence of such object added references for all its virtual methods 
and so on.

The only solution against this awful linker strategy was to split 
modules into *very* small files and manually predict dependencies and 
try to prevent linker from wanting something that nobody else wants.
It was hard. For previous 3 years with DMC I never needed such handwork.

Digital Mars linker is great in this field, but you definitely cannot 
assume that all linkers sing late 80's are as smart as DMC.

Nic Tiger.