fillg1@uni-paderborn.de (Michael Illgner) (01/17/91)
Hi folks, Is there any possibility to compile a single function with code size greater than 32k using the SAS-C compiler ? Don't flame me for trying such strange things, the C source was generated by f2c, a common FORTRAN to C converter, and I >don't< want to understand and rewrite the original FORTRAN program. The compiler options -b? and -r? don't seem to work in this case. Any ideas or suggestions ? Michael Michael Illgner fillg1@uni-paderborn.de Tel. Theodorstrasse 27 Warburgerstr. 100 Buero 05251/60-2331 4790 Paderborn Theoretische Physik Privat 05251/26488 Germany Buero : N3.323 -- Michael Illgner fillg1@uni-paderborn.de Tel. Theodorstrasse 27 Warburgerstr. 100 Buero 05251/60-2331 4790 Paderborn Theoretische Physik Privat 05251/26488 Germany Buero : N3.323
fillg1@uni-paderborn.de (Michael Illgner) (01/21/91)
lkoop@pnet01.cts.com (Lamonte Koop) writes: >fillg1@uni-paderborn.de (Michael Illgner) writes: >> >>Hi folks, >> >>Is there any possibility to compile a single function with code size >>greater than 32k using the SAS-C compiler ? >> >>Don't flame me for trying such strange things, the C source was generated >>by f2c, a common FORTRAN to C converter, and I >don't< want to understand >>and rewrite the original FORTRAN program. >> >>The compiler options -b? and -r? don't seem to work in this case. >>Any ideas or suggestions ? >The -b switch is definitely not going to work. That switches on base relative >data addressing. Using -r with no options defaults to 16-bit PC relative >target function addressing. Try the following options: -b0 -r0 >The zero after the option in each case implies 32-bit absolute addressing for >both data and function calls. ^^^^^^^^^^^^^^^ That is >not< the problem. I need 32-bit absolute addressing inside a function, eg. for loops and not for function calls. I believe that SAS does not support this. Michael Illgner fillg1@uni-paderborn.de Tel. Theodorstrasse 27 Warburgerstr. 100 Buero 05251/60-2331 4790 Paderborn Theoretische Physik Privat 05251/26488 Germany Buero : N3.323 -- Michael Illgner fillg1@uni-paderborn.de Tel. Theodorstrasse 27 Warburgerstr. 100 Buero 05251/60-2331 4790 Paderborn Theoretische Physik Privat 05251/26488 Germany Buero : N3.323
fillg1@uni-paderborn.de (Michael Illgner) (01/25/91)
ben@epmooch.UUCP (Rev. Ben A. Mesander) writes: >>>The -b switch is definitely not going to work. That switches on base relative >>>data addressing. Using -r with no options defaults to 16-bit PC relative >>>target function addressing. Try the following options: -b0 -r0 >>>The zero after the option in each case implies 32-bit absolute addressing for >>>both data and function calls. >> ^^^^^^^^^^^^^^^ >>That is >not< the problem. I need 32-bit absolute addressing inside a >>function, eg. for loops and not for function calls. I believe that >>SAS does not support this. >I had this problem with Lattice C 5.05 when I compiled GNU Chess, but SAS/C >advertises that they *can* handle loops and switches larger than 32K, and >indeed GNU Chess now compiles fine (well, there are a lot of other changes >to make due to SAS's bugs in handling short in ANSI prototypes (maybe fixed >in 5.10A now)). So I'm puzzled as to what the problem you are having is, >could you post the exact error message? I don't remember the exact message, but it was something like : Codesize greater 32k. Branches may be incorrect. Split some subroutines into seperate files. Unlike the usual error messages from the compiler, there was neither an error number nor a line number in the message. I have tried the new -ba switch for automatic converting to far, but no success. The codesize was about 80k in a single function. -- Michael Illgner fillg1@uni-paderborn.de Tel. Theodorstrasse 27 Warburgerstr. 100 Buero 05251/60-2331 4790 Paderborn Theoretische Physik Privat 05251/26488 Germany Buero : N3.323
ben@epmooch.UUCP (Rev. Ben A. Mesander) (01/25/91)
>In article <1991Jan25.121424.4165@uni-paderborn.de> fillg1@uni-paderborn.de (Michael Illgner) writes: >ben@epmooch.UUCP (Rev. Ben A. Mesander) writes: >>>>The -b switch is definitely not going to work. That switches on base relative >>>>data addressing. Using -r with no options defaults to 16-bit PC relative >>>>target function addressing. Try the following options: -b0 -r0 >>>>The zero after the option in each case implies 32-bit absolute addressing for >>>>both data and function calls. >>> ^^^^^^^^^^^^^^^ >>>That is >not< the problem. I need 32-bit absolute addressing inside a >>>function, eg. for loops and not for function calls. I believe that >>>SAS does not support this. > >>I had this problem with Lattice C 5.05 when I compiled GNU Chess, but SAS/C >>advertises that they *can* handle loops and switches larger than 32K, and >>indeed GNU Chess now compiles fine (well, there are a lot of other changes >>to make due to SAS's bugs in handling short in ANSI prototypes (maybe fixed >>in 5.10A now)). So I'm puzzled as to what the problem you are having is, >>could you post the exact error message? > >I don't remember the exact message, but it was something like : >Codesize greater 32k. Branches may be incorrect. >Split some subroutines into seperate files. > >Unlike the usual error messages from the compiler, there was neither >an error number nor a line number in the message. >I have tried the new -ba switch for automatic converting to far, >but no success. > >The codesize was about 80k in a single function. That sounds like the same error message I would get from Lattice 5.05 when trying to compile GNU Chess. I didn't have the problem with SAS/C 5.10 or 5.10A. I guess call the SAS Institute. I tried writing them with my bug list, but I got no response other than a free 5.10A upgrade (which fixed problems I didn't know existed). I really appreciate the free upgrade, but I wish that they had also included replies to the questions I asked. I have heard that the telephone support is really good. The other option is to ftp a copy of GCC for the Amiga, if you have 2.5 Mb or more of memory, and compile your code with that. You'll need some of the pieces of the SAS distribution to get it to work (i.e. BLINK). -- | 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 |