gcc fault

[josephma at attbi dot com]

Fundamental changes in the compile and link step for 
building simulation tools would significantly improve 
modeling and design of whole systems. This note explores 
that idea briefly.

Flaws in available tools for simulation of systems limit 
the usefulness of simulation methodologies in system 
design.  I write this to explore interest in simulation 
tool methodologies.  In recent times, my energies 
focused on IC design and verification.  My work has more 
than once led to simulation of multiple, large ICs in a 
single simulation context. Uniformly, the multiple IC 
simulation problem is greatly exasperated by limitations 
in current tools.  I want to encourage development on 
tool issues that could greatly expand the role 
simulation of multiple ICs plays in system design.  
Significant progress in this area ought to improve 
modeling and design of whole systems.

Typically, a simulation model of a large IC is developed 
by a team of designers over a 6-12 month period. 
Multiple ICs developed by a variety of teams inevitably 
lead to models that overlap in their usage of names for 
objects.  In all my past attempts, building a single 
simulation of multiple IC models could only be achieved 
by absolute elimination of overlapping name usage.  That 
is, each model had to be rewritten by renaming objects 
to force uniqueness of names.  Touching IC models to
fix tool limitations is a fundamentally flawed approach 
to the multiple IC modeling problem.  Once a model has 
been certified by a design team for fabrication of a 
device, any touching of the model destroys its 
integrity.  What, then, are the tool changes needed?

Although there are numerous tools associated with this 
area, my looking at tools leads beyond the primary tools 
to system tools used for building the primary tools.  
What I see as limiting simulations in a fundamental way 
is the compiling and linking step (e.g., gcc).  The
compiler should support linking of independently 
developed modules with their extern name spaces 
referenced to libraries that differ with each module.  
Currently, gcc allocates some priority sequence for 
searching libraries to resolve names and the first one 
that matches gets used. Tagging module object files with 
library search sequence information seems like one way 
to fix the problem of multiple name spaces.  It is
possible that this is not fixable by merely a change in 
the compile/link tool and that some kernel changes need 
to accompany the change in the compile/link tool.

I am not an expert in designing compilers, but my usage 
of them convinces me that flaws in available compilers 
prevent important design methodologies from emerging.  
If you who maintain gcc find this idea interesting, 
please contact me for additional discussion.


Joseph Patterson
email: josephma@attbi.com