Thanks everyone for the help on this.
Producing the MAP file allowed me to find the static variable that was
using the 32K (2 serial buffers at 16K a pop).
Although segmenting the project wasn't really required in the end, it
has still given me some experience in the matter, which will be valuable
in times to come.
Thanks again.
Jason
> -----Original Message-----
> From: Scott Johnson (WA) [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, December 21, 1999 1:48 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: Data Segment > 32K?
>
> > From: Jason Garrett [mailto:[EMAIL PROTECTED]]
> > I have a Codewarrior project which produces the following error:
> > __RuntimeModule__: Near data segment is bigger than 64K
>
> I found that error message isn't always accurate. It means you are
> overflowing some size limit within the data segment, but not
> necessarily the
> overall size limit of 64K. It seems (from my quickie testing) that
> there
> are a couple sub areas in the data segment that each cannot exceed
> 32K.
> This may be your problem.
>
> > I have 2 segments
> > Segment 1: Code 29K, Data 19K
> > Segment 2: Code 8K, Data 32K
>
> You have 2 code segments but there is only one data segment no matter
> what,
> which is the combination of all global data from all code files. Note
> those
> data size numbers reported in the IDE segments window are not really
> accurate anyway. Those numbers include all global data objects
> defined,
> even those which will be omitted by the linker because they aren't
> really
> referenced anywhere. And the linker will often include extra data
> objects
> behind your back, such as jump tables for multi segment apps, C++
> vtables,
> C++ exception stuff, etc. So the only way to inspect all this
> accurately is
> with the linker map file. (Of course that requires your app to
> successfully
> build in the first place!)
>
> > Can someone point me in the right direction to any notes on Code
> size
> > and segmenting projects.
>
> Do you have a previous revision that did build ok (before making the
> most
> recent change that broke it) and if so, can you report what the map
> file
> says.
>
> Or to think about what's really going on in your program: just what is
> all
> this big global/static data? You may be able to find workarounds such
> as
> allocating uninitialized data space from the heap, and putting
> read-only
> static data into custom resources instead, or switching to algorithms
> that
> use less space, whatever.
>
> -slj-
>
>
>
