papa%pollux.usc.edu@UDEL.EDU (10/04/88)
Received: from CUNYVM by CUNYVM.BITNET (Mailer X2.00) with BSMTP id 3933; Sat, 01 Oct 88 23:11:44 EDT Received: from UDEL.EDU by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with TCP; Sat, 01 Oct 88 23:11:41 EDT Received: from Louie.UDEL.EDU by Louie.UDEL.EDU id aa00572; 1 Oct 88 19:13 EDT Received: from USENET by Louie.UDEL.EDU id aa06520; 1 Oct 88 18:39 EDT From: Marco Papa <papa@pollux.usc.edu> Subject: lattice/MANX bug when compiling large programs Message-ID: <12499@oberon.USC.EDU> Date: 1 Oct 88 09:06:08 GMT Organization: Felsina Software, Los Angeles, CA To: amiga-relay@UDEL.EDU Sender: amiga-relay-request@UDEL.EDU I am trying to compile a VERY large C program and so far I haven't been successful with either MANX 3.60 or Lattice 4.00. ** start of flame MANX dies with the "infamous" PC-relative bug mentioned recently on the net. I haven't ben able to reach MANX Tech Support ANYWHERE. Jim is "working on 4.0", they say. Lattice 4.00 compiles the program OK, but then dies right away in Blink. Blink returns "error 502: Distance for reloc16 > 32768" with symbol __xcovf or something like that. I am just using the "default" library lc which should be able to address the entire memory. I called Lattice Tech Support and the "idiot" there told me that I should use the "-ml switch to use the large memory model". I explained that I thought he might mistakenly confuse the Amiga C with PC-DOS C, but he said no. Well, lo and behold I was right and the lattice technical idiot was wrong. -ml is a switch of Lattice C for PC DOS and does not exist in the Amiga version. Posting a question on BIX produced nothing. Is there anybody here on the net from SAS Institure, Lattice, or the Software Distillery that can tell me how to get around this bug? Sincerely I prefer NO support (like MANX) to BAD support (like Lattice people that cannot even read their own manuals). In general, it seems that C compilers on the Amiga have a long way to go to become of the same quality of say C compilers under UNIX. ** end of flame Have a good weekend. -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
rminnich%super.org@cunyvm.cuny.edu (10/04/88)
Received: from CUNYVM by CUNYVM.BITNET (Mailer X2.00) with BSMTP id 7549; Tue, 04 Oct 88 02:32:03 EDT Received: from UDEL.EDU by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with TCP; Tue, 04 Oct 88 02:31:58 EDT Received: from Louie.UDEL.EDU by Louie.UDEL.EDU id aa15008; 3 Oct 88 20:49 EDT Received: from USENET by Louie.UDEL.EDU id aa14760; 3 Oct 88 20:38 EDT From: Ronald G Minnich <rminnich@super.org> Subject: Re: lattice/MANX bug when compiling large programs Message-ID: <808@super.ORG> Date: 3 Oct 88 15:52:26 GMT Organization: Supercomputing Research Center, Lanham, MD To: amiga-relay@UDEL.EDU Sender: amiga-relay-request@UDEL.EDU In article <12521@oberon.USC.EDU> papa@pollux.usc.edu (Marco Papa) writes: >p. C-9: "the default is to use 32-bit absolute addressing, which allows >data hunks of virtually unlimited size..." Also the fact that both -b and -r >allow a numweric operand is not documented anywhere. Oh yeah, neat isn't it. My theory is that they wanted to do well on the benchmarks and so changed the sense of the flags at the last minute. Or something. Sure ticked me off when i found this one. YOu have to look at man pages for lc1 and lc2 to know what is really happening. ron
ins_adjb@jhunix.HCF.JHU.EDU (Daniel Jay Barrett) (10/04/88)
In article <4424@louie.udel.EDU> papa%pollux.usc.edu@UDEL.EDU writes: >** start of flame > >MANX dies with the "infamous" PC-relative bug mentioned recently on the net. >I haven't ben able to reach MANX Tech Support ANYWHERE. Jim is "working on >4.0", they say. Calm down. I reported this bug to Manx practically the day V3.6 came out, complete with a minimal code example. (Change one character constant, and the program assembles!) One month later, I received a letter that the bug has been fixed. (Yes, I agree that a bugfix would have been nice.) In my program, the bug was induced by a large switch statement. If you have such a beast, try elminating case options, or changing the name of case options, and the bug may disappear. Seriously. My program had: switch (ch) { ... case 'x':... and the program wouldn't assemble. However, switch (ch) { ... case 'y':... assembled perfectly. -- Dan Barrett ins_adjb@jhunix.UUCP UUCP barrett@cs.jhu.edu (128.220.13.4) ARPA Dept. of Computer Science, Johns Hopkins University, Baltimore, MD 21218
dca@kesmai.COM (David C. Albrecht) (10/06/88)
> I am trying to compile a VERY large C program and so far I haven't been > successful with either MANX 3.60 or Lattice 4.00. > > MANX dies with the "infamous" PC-relative bug mentioned recently on the net. > I haven't ben able to reach MANX Tech Support ANYWHERE. Jim is "working on > 4.0", they say. > > Lattice 4.00 compiles the program OK, but then dies right away in Blink. > Blink returns "error 502: Distance for reloc16 > 32768" with symbol __xcovf or > something like that. I am just using the "default" library lc which should > be able to address the entire memory. > How modularized is this program? I have noticed that the subroutine linkages in Lattice are actually BSRs to a series of JMPS (one for each of the subroutines you access external to your module). If a single compiland is too large then the BSR to the jump table could fail so you might run into trouble even though the entire program size can be quite large. You might be able to fix your problem with some judicious splitting of the source into separate compilands. Just a thought. u s e n e t f o o d David Albrecht
papa@pollux.usc.edu (Marco Papa) (10/07/88)
In article <188@kesmai.COM> dca@kesmai.COM (David C. Albrecht) writes: I (Marco Papa) say: || I am trying to compile a VERY large C program and so far I haven't been || successful with either MANX 3.60 or Lattice 4.00. || || MANX dies with the "infamous" PC-relative bug mentioned recently on the net. || I haven't ben able to reach MANX Tech Support ANYWHERE. Jim is "working on || 4.0", they say. || || Lattice 4.00 compiles the program OK, but then dies right away in Blink. || Blink returns "error 502: Distance for reloc16 | 32768" with symbol __xcovf or || something like that. I am just using the "default" library lc which should || be able to address the entire memory. || |How modularized is this program? I have noticed that the subroutine |linkages in Lattice are actually BSRs to a series of JMPS (one for |each of the subroutines you access external to your module). If a |single compiland is too large then the BSR to the jump table could |fail so you might run into trouble even though the entire program size |can be quite large. You might be able to fix your problem with some |judicious splitting of the source into separate compilands. Just a thought. The program is *ONE* module, 256K worth of source code. 4 UNIX compilers have no problem with it. I have no more compilation problems with Lattice after using the -r0 -b0 switches, EXCEPT that Lattice generates BAD code (BBS.S with odd address). The point I am trying to make is that neither of the two C compilers on the Amiga come even close to the ones on UNIX. I don't want to start "kludgin the code", just because the compiler is BROKEN. I'll just go back to UNIX. -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
dca@kesmai.COM (David C. Albrecht) (10/08/88)
In article <12624@oberon.USC.EDU>, papa@pollux.usc.edu (Marco Papa) writes: > In article <188@kesmai.COM> dca@kesmai.COM (David C. Albrecht) writes: > I (Marco Papa) say: > || I am trying to compile a VERY large C program and so far I haven't been > || successful with either MANX 3.60 or Lattice 4.00. > |How modularized is this program? I have noticed that the subroutine > |linkages in Lattice are actually BSRs to a series of JMPS (one for > |each of the subroutines you access external to your module). If a > |single compiland is too large then the BSR to the jump table could > |fail so you might run into trouble even though the entire program size > |can be quite large. You might be able to fix your problem with some > |judicious splitting of the source into separate compilands. Just a thought. > > The program is *ONE* module, 256K worth of source code. 4 UNIX compilers > have no problem with it. I have no more compilation problems with Lattice > after using the -r0 -b0 switches, EXCEPT that Lattice generates BAD code > (BBS.S with odd address). The point I am trying to make is that neither > of the two C compilers on the Amiga come even close to the ones on UNIX. > I don't want to start "kludgin the code", just because the compiler is > BROKEN. I'll just go back to UNIX. > I was out to lunch anyway. The instructions were JSRs not BSRs. I'm kind of surprised that you are surprised. Due to the 'come from below' philosophy of compilers on micros they very frequently choke and die on large programs. I have found that compilers that people are so enamored of because they compile so fast often choke and die and the kind of programs I need to compile. More often than not compilers seem to be designed for modest amounts of code. Unix system compilers have been designed from the start for serious projects, not for speed or ability to run in a small environment and thus tend to be much more tolerant. I consider myself lucky if the compiler can handle binding several reasonable size modules into one very large one. I can understand your desire to not mess with the code but I wouldn't consider breaking a 256K, single module source file, into multiple modules exactly kludging. I'll spare everyone the commentaries about software engineering. David Albrecht
chima@dasys1.UUCP (Chima Ngene) (10/10/88)
> I am trying to compile a VERY large C program and so far I haven't been > successful with either MANX 3.60 or Lattice 4.00. > > MANX dies with the "infamous" PC-relative bug mentioned recently on the net. > I haven't ben able to reach MANX Tech Support ANYWHERE. Jim is "working on > 4.0", they say. > > Lattice 4.00 compiles the program OK, but then dies right away in Blink. > Blink returns "error 502: Distance for reloc16 > 32768" with symbol __xcovf > or something like that. I am just using the "default" library lc which > should be able to address the entire memory. > As for the Lattice 4.00 compiler, it uses the pc_relative addressing as the default. So this means that if any function tries to branch off to a distance greater than 32768 {bytes} it couldn't. (This should explain the problem in your linking. What you should do when compiling is: lc -r0 name.c Now I could be wrong, if I am, let me know. -- /// Amiga Power User - Mr. Chima Ngene (chima@dasys1) /// /// {UNIX, & DOS, ETC} Programmer..... (Take Your Pick) /// \\\/// .....!cmcl2!phri!dasys1!chima \\\/// \\// {amiga@dhw68k.cts.com} {amiga@killer} \\//