ben@epmooch.UUCP (Rev. Ben A. Mesander) (10/06/90)
I've been porting GNU Chess to the Amiga with Lattice 5.05. I've come across a compiler message something along the lines of: "Object size larger than 32768 bytes, some branches may be incorrect. Please place subroutines in separate modules". (That's not it, exactly... but from memory) This error message is not in the compiler manual. I'm compiling the source code with the -r0 and -b0 options, which allow full 32-bit addressing for code and data, so I would not expect any 32K size limit. The resulting code _seems_ to work O.K. Why does this happen? I'd rather not go around re-arranging all the code in a GNU distribution. Is this fixed in SAS/C 5.10? -- | ben@epmooch.UUCP (Ben Mesander) | "Cash is more important than | | ben%servalan.UUCP@uokmax.ecn.uoknor.edu | your mother." - Al Shugart, | | !chinet!uokmax!servalan!epmooch!ben | CEO, Seagate Technologies |
ben@epmooch.UUCP (Rev. Ben A. Mesander) (10/07/90)
>In article <14941@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes: >In article <ben.2904@epmooch.UUCP> ben@epmooch.UUCP (Rev. Ben A. Mesander) writes: >>I've been porting GNU Chess to the Amiga with Lattice 5.05. I've come >>across a compiler message something along the lines of: >>"Object size larger than 32768 bytes, some branches may be incorrect. >>Please place subroutines in separate modules". >>(That's not it, exactly... but from memory) >> >>This error message is not in the compiler manual. I'm compiling the source >>code with the -r0 and -b0 options, which allow full 32-bit addressing for >>code and data, so I would not expect any 32K size limit. > > Try linking with lcnb.lib instead of lc.lib. (Ditto for lcmnb.lib >instead of lcm.lib.) These are the -b0 versions of the libraries. > I *am* linking with lcnb.lib. This message is coming from LC1, not the linker, anyway. It turns out the message goes away if I turn off all the debugging options. I'm not sure if it got better because of the code size reduction, or if there is some problem with -b0 code generation and the debugging options. It's making my Intuition interface for GNU Chess hard to debug - lots of printf()'s... >-- >Randell Jesup, Keeper of AmigaDos, Commodore Engineering. >{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup >Common phrase heard at Amiga Devcon '89: "It's in there!" -- | ben@epmooch.UUCP (Ben Mesander) | "Cash is more important than | | ben%servalan.UUCP@uokmax.ecn.uoknor.edu | your mother." - Al Shugart, | | !chinet!uokmax!servalan!epmooch!ben | CEO, Seagate Technologies |
jesup@cbmvax.commodore.com (Randell Jesup) (10/08/90)
In article <ben.2904@epmooch.UUCP> ben@epmooch.UUCP (Rev. Ben A. Mesander) writes: >I've been porting GNU Chess to the Amiga with Lattice 5.05. I've come >across a compiler message something along the lines of: >"Object size larger than 32768 bytes, some branches may be incorrect. >Please place subroutines in separate modules". >(That's not it, exactly... but from memory) > >This error message is not in the compiler manual. I'm compiling the source >code with the -r0 and -b0 options, which allow full 32-bit addressing for >code and data, so I would not expect any 32K size limit. Try linking with lcnb.lib instead of lc.lib. (Ditto for lcmnb.lib instead of lcm.lib.) These are the -b0 versions of the libraries. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"
rooijen@rulcvx.LeidenUniv.nl (A.J. van Rooijen) (10/08/90)
In article <ben.2904@epmooch.UUCP> ben@epmooch.UUCP (Rev. Ben A. Mesander) writes: >I've been porting GNU Chess to the Amiga with Lattice 5.05. I've come Where can this GNU Chess be found? I am very interested in chess programs. At the moment I am writing one myself. Many thanks, Erwin van Breemen Leiden.
jmeissen@oregon.oacis.org ( Staff OACIS) (10/09/90)
In article <ben.2904@epmooch.UUCP> ben@epmooch.UUCP (Rev. Ben A. Mesander) writes: >I've been porting GNU Chess to the Amiga with Lattice 5.05. I've come >across a compiler message something along the lines of: >"Object size larger than 32768 bytes, some branches may be incorrect. >Please place subroutines in separate modules". >(That's not it, exactly... but from memory) > >This error message is not in the compiler manual. I'm compiling the source >code with the -r0 and -b0 options, which allow full 32-bit addressing for >code and data, so I would not expect any 32K size limit. > >The resulting code _seems_ to work O.K. > >Why does this happen? I'd rather not go around re-arranging all the code >in a GNU distribution. Is this fixed in SAS/C 5.10? That (and prior) version of Lattice (SAS) C uses pc-relative branches for function calls to functions within the same source module. This efectively limits the size of a particular source module's code hunk to 32K. If you are lucky, all of your calls will be within range, and it will work. I don't think I would trust it, however, since the compiler generates the branch offsets, not the linker, and the compiler is complaining. In general, any source file large enough to generate that warning is too big! The suggestion (splitting it up into smaller files) is good advice. Of course, it's not your fault that the GNU developers like to create unmaintainable source. There were/are other 32K-type limits. A switch statement block could not exceed 32K, I think, and there was also some limitation about the size of a single function. Most, if not all, of these limitations are resolved in the current release (v5.10). Your options appear to be either split up the file, or update your compiler. -- John Meissen .............................. Oregon Advanced Computing Institute jmeissen@oacis.org (Internet) | "That's the remarkable thing about life; ..!sequent!oacis!jmeissen (UUCP) | things are never so bad that they can't jmeissen (BIX) | get worse." - Calvin & Hobbes