papa@pollux.usc.edu (Marco Papa) (10/01/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. * 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] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
riley@batcomputer.tn.cornell.edu (Daniel S. Riley) (10/03/88)
In article <12499@oberon.USC.EDU> papa@pollux.usc.edu (Marco Papa) writes: >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 don't work for Lattice, SAS or the Software Distillery, but I will offer some advice. The default for the both the compiler AND THE LIBRARIES is base-relative addressing. For a program with a lot of data, you should be compiling with the -b0 flag to lc (or lc1) to disable base-relative addressing. You probably should not be using the blink "SMALLDATA" option. If you still have the problem, you should use the library lcnb in the lib directory on disk 4, which is compiled without base-relative addressing (this is documented in the readme file on disk 1--disk 4 was added after the manual was printed). If you don't expect this program to take up much stack, you could also 'finesse' the problem by using the -v flag to lc (or lc2). This disables the stack checking code at each function entry point. (__xcovf is defined by the stack overflow handler, so it's referenced by every module in your program.) However, this is often not a good idea... -dan riley (dsr@lns61.tn.cornell.edu, dsr@crnlns.bitnet) -wilson lab, cornell u.
papa@pollux.usc.edu (Marco Papa) (10/03/88)
In article <6439@batcomputer.tn.cornell.edu> riley@tcgould.tn.cornell.edu (Daniel S. Riley) writes: >In article <12499@oberon.USC.EDU> papa@pollux.usc.edu (Marco Papa) writes: >>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 don't work for Lattice, SAS or the Software Distillery, but I will offer >some advice. Thank you. >The default for the both the compiler AND THE LIBRARIES is base-relative >addressing. For a program with a lot of data, you should be compiling >with the -b0 flag to lc (or lc1) to disable base-relative addressing. You >probably should not be using the blink "SMALLDATA" option. If you still >have the problem, you should use the library lcnb in the lib directory on >disk 4, which is compiled without base-relative addressing (this is >documented in the readme file on disk 1--disk 4 was added after the manual >was printed). As also suggested by Raymond Brand, I used both flags -b0 -r0. This seems to let Blick to finish up linking successfully. According to Raymond and Dave the default is "base-relative" addressing (obtained with -b1 -r1). This experiment seems to confirm this. This is also exactly the opposite as what is documented in the Lattice Manual: 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. The interesting thing is that I got the correct answer and fix from poeple totally disconnected with Lattice, SAS or the Software Distillery (I don't mean to flame you guys, you are out of the Blink loop new, I understand), and instead Lattice Tech support gave me the WRONG answer. Thank you 'net guys. -- 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 (Ronald G Minnich) (10/03/88)
In article <12499@oberon.USC.EDU> papa@pollux.usc.edu (Marco Papa) writes: >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 ah, you need to use the -r0 switch, which is totally and completely documented WRONG in the manual. -r0 will fix ya. Now all you have to do is figure out which library to use. THere are three. No docs. Good luck. Yeah, the amiga C compilers are pretty bad. I have an approach/avoidance to Lattice myself. Every few months i think 'aw, its ok, it wasn't really that bad, think i'll have some fun', and go use Lattice, and end up a few hours later hating it. Latest gripe: I can't get forkv to work for nothing. The writeup in the manual is pure garbage, as is the example (with programs like "this" and "that"). Anybody got forkv working yet? I get nothing but guru's. Or no reaction. But i don't get forkv. Does NULL as the environment parameter really work? When will Lightspeed be on the Amiga (ha, ha)? Is Forth really that good for hacking amigas? I really want something, and C just is not it.... BTW, the APL product from Marks and Spencer is really pretty neat. ^^^^^ or whatever they're called. ron
rminnich@super.ORG (Ronald G Minnich) (10/03/88)
In article <6439@batcomputer.tn.cornell.edu> riley@tcgould.tn.cornell.edu (Daniel S. Riley) writes: >The default for the both the compiler AND THE LIBRARIES is base-relative >addressing. For a program with a lot of data, you should be compiling >with the -b0 flag to lc (or lc1) to disable base-relative addressing. You Yes, but the specific problem was a CODE address, so the -b switch won't help. To fix the code address problem you need to muck with the -r switch and then find a library that matches, which is fun as the names determine it. There just has to have been a better way to do all this ... You can really tell the products that were developed on a machine with a hard disk: running on floppies always seems to be an afterthought. ron
rminnich@super.ORG (Ronald G Minnich) (10/03/88)
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
walker@sas.UUCP (Doug Walker) (10/05/88)
In article <12521@oberon.USC.EDU> papa@pollux.usc.edu (Marco Papa) writes: >The interesting thing is that I got the correct answer and fix from poeple >totally disconnected with Lattice, SAS or the Software Distillery (I don't >mean to flame you guys, you are out of the Blink loop new, I understand), >and instead Lattice Tech support gave me the WRONG answer. The REALLY interesting thing is that the original question and the correct answer both arrived here at SAS Institute on the same day. This might explain why the Institute and the Software Distillery (whose members use the Institute as a news feed) failed to respond. (It also doesn't help that John Toebes is out of town. . .)
papa@pollux.usc.edu (Marco Papa) (10/05/88)
In article <634@sas.UUCP> walker@sas.UUCP (Doug Walker) writes: >The REALLY interesting thing is that the original question and the correct >answer both arrived here at SAS Institute on the same day. This might >explain why the Institute and the Software Distillery (whose members use >the Institute as a news feed) failed to respond. > >(It also doesn't help that John Toebes is out of town. . .) The SAD thing is that even after succesful compilation and linking the program, when run, GURUs right away. And this is a program that uses no Amiga-specific routines, just stdio.h and ANSI C code. It compiles and runs fine on at least 3 UNIX-based systems. Since there are no debuggers provided with Lattice (and I cannot use MANX's SDB), the only thing I can use is MANX's db (gulp!). Would anybody at Lattice/SAS Institute be interested in getting the source code of this and take a look at it? I also tried the suggestions about getting it to run with MANX C and fix the PC-relative bug. The only thing I can say is that the PC-relative bug is generated with "large" switch statements. Unfortunately in my case, I cannot simply substitute an 'x' with a 'y' and get it to work: I don't have such cases in my switch statements. Too bad that MANX has decided to just work on 4.0 and leave 3.6 users waiting for the new version (when? 1989?) without fixing the bugs in 3.6. -- 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] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=