Path: chuka.playstation.co.uk!news From: Chris Chadwick Newsgroups: scee.yaroze.programming.gnu_compiler Subject: Re: Optimise Problem - trunced data Date: Thu, 07 Aug 1997 01:53:16 -0700 Organization: PlayStation Net Yaroze (SCEE) Lines: 92 Message-ID: <33E98CFC.522B@dial.pipex.com> References: <333d7fd9.23907964@news.playstation.co.uk> <33424023.72C4@interactive.sony.com> <33D5B732.3AC9@dial.pipex.com> <01bc9c44$3fe961e0$ca2c9ac2@martin.snsys.com> <33E39782.6C3F@dial.pipex.com> <01bca0db$fb8dfdc0$ca2c9ac2@martin.snsys.com> <33E8377F.366F@dial.pipex.com> <5s9g9e$oj8@chuka.playstation.co.uk> NNTP-Posting-Host: an099.du.pipex.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.02 (Win95; I; 16bit) Hi, Gil! Gil Jaysmith wrote: > > Chris Chadwick wrote: > > >I've tried this method too and it seems to work fine ;) > >You are obviously more clued about the workings of the > >compiler than me (not difficult :) so I was wondering > >if you could explain what the 4 program sections - that are > >listed when dowloading a prog - actually contain: .text, .sdata, > >.rdata and .data ... > > >I assume .text is the actual executable program code and, from your > >above desciption, .sdata (s for session?) holds global data ? > > Wotcher Chris... > > (compiler slave butts in since boss isn't in office yet :=) > > .text holds the executable program code. > .data holds initialised data. > .rdata holds initialised read-only data. (Sometimes it takes a little > effort to convince the compiler of the difference.) > .sdata holds small items of initialised data which are accessed > slightly faster. > > There are also sections called .bss (for uninitialised data) and .sbss > (for small items of uninitialised data). > > The -G option for the compiler determines what 'small' means. I think > it defaults to 8 bytes. So if you declare an int variable, the > compiler will allocate it in .sbss if you declare it simply as "int > a;", or in .sdata if you declare it as "int a = 1;". > > Anything bigger than that -G limit, which generally means most structs > and arrays, goes into .data if you give an initialiser, or .bss if > not. > > Why not set the -G limit to a huge number if access to it is faster? > Because access is with a signed 16-bit offset from the GP register, > which is set to point into the middle of the .sdata/.sbss combined > section. So you have a limit of 64K of 'small' data. I wondered why the GP register was set to point to the *middle* and indexed with a signed offset instead of simply pointing to the base and using an unsigned offset. I didn't realize this section was shared! I guess, then, negative offsets index into .sdata and positive offsets index into .sbss (or vice versa)... > This limit is > discovered, so to speak, at link time, which is why a project can > compile perfectly well but crash out with linker errors because it > can't fit the offset into 16 bits. There isn't a good heuristic for > determining a good value for -G during compilation, other than to > write your code in one C file, so if you get this problem, you just > have to systematically reduce the -G value and remake until it links. > > The bss sections are flagged as having no contents, and it's the > responsibility of the startup code to fill them with zeros. This is > why you can declare something like "char a[1000000];" without getting > a massive object file. > > You can also declare your own sections and place functions and > variables within them using the GNU C extension "__attribute__", but > you need to be canny with your linker script to place these where you > want. The sections named above are just the standard ones you always > get when compiling, and mostly you shouldn't need any others. Our > linker has cool stuff to meddle with section names during linking so > as to make it easy to generate code overlays, but you can probably do > this with the GNU linker too and I seem to remember a previous thread > somewhere talking about a Japanese demo which downloaded overlays from > the host. > > In C++ there are also sections called .ctors and .dtors, which contain > the addresses of routines which create any global class objects you > might have lying around. These are cycled through by the startup and > shutdown code so you generally needn't worry about them. > > And that's what we know about standard COFF sections... > > Gil Jaysmith > SN Systems Software Ltd, makers of Psy-Q... http://www.snsys.com > Disclaimer: What I say when I post here represents me, not my employers. Blimey! thank v. much for all the info. I understand these things a little more clearly now :) Cheers Chris