On 18 Sep 2001, at 20:38, Frank Heckenbach wrote:
Marco van de Voort wrote:
One should create a .s parser that can detect global syms and breaks the .s in pieces there, piping the different small .s files to the back end .assembler
so e.g.
- compiler pipes gpc.s to our filter program.
- the filter program splits gpc.s per global symbol up in gpc00.s
gpc01.s gpc02.s etc - the filter programs pipes each .s separately through as, generating a .o per .s - all .s files are combined to a .a by AR, which is executed by the filterprogram
Actually, I've had exactly the same idea -- but no time yet to pursue it further ...
This sounds promising ...
[...]
E.g. a windows API unit generates 20000 .s files.
Nope. They're just external declarations that don't produce any code of their own. Such a unit would be only one file (in fact, such units currently have very small .o files and large .gpi files which are not relevant for linking and executable size, of course).
True. My "Windows" unit which imports most of the Win32 API has a .o file that is 3k in size and a .gpi file that is 2.2mb in size ...
Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Author of Chief's Installer Pro for Win32 Email: African_Chief@bigfoot.com http://www.bigfoot.com/~african_chief/