Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!dali.cs.montana.edu!milton!wiml From: wiml@milton.u.washington.edu (William Lewis) Newsgroups: comp.sys.next Subject: Re: Small executables (was Re: 16mb minimum for next machines) Message-ID: <1991May6.061836.28477@milton.u.washington.edu> Date: 6 May 91 06:18:36 GMT References: <1991May1.062022.1056@nntp-server.caltech.edu> <1991May2.142103.6047@potomac.ads.com> Organization: University of Washington, Seattle Lines: 24 In article <1991May2.142103.6047@potomac.ads.com> jtn@potomac.ads.com (John T. Nelson) writes: >... ahem yes well all this talk about the size of binaries implies >that compiler writers are no longer concerned with space effeciency as >they used to be since internal memory is now cheap as dirt and >besides, you've got virtual memory so no problem right? Hmmmm... >still compilers should be more effecient about what they generate. Actually, if I understand things, the two switches that dropped things from 48k to ~2k ( -s and -object ) don't modify the code generation at all, just the packaging. In a standard Mach-Object file, for reasons of virtual memory efficiency probably, all segments are rounded to a multiple of 8k bytes. A stripped binary ( -s ) contains the text and data segments, for 16k after being rounded up. An unstripped binary includes debugging information, a symbol table, indexes to the original source code, and probably a copy of the Gnu Manifesto (why not, it gets into everything else) which bumps things up another 32k. But it's the same code running either way. -- wiml@milton.acs.washington.edu Seattle, Washington (William Lewis) | 47 41' 15" N 122 42' 58" W "Just remember, wherever you go ... you're stuck there."