eric%hector.uucp@UDEL.EDU (10/04/88)
Received: from CUNYVM by CUNYVM.BITNET (Mailer X2.00) with BSMTP id 4617; Fri, 30 Sep 88 19:34:27 EDT Received: from UDEL.EDU by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with TCP; Fri, 30 Sep 88 19:34:24 EDT Received: from Louie.UDEL.EDU by Louie.UDEL.EDU id aa12352; 30 Sep 88 15:01 EDT Received: from USENET by Louie.UDEL.EDU id aa12192; 30 Sep 88 14:53 EDT From: Eric Lavitsky <eric@hector.uucp> Subject: Re: Manx bug Message-ID: <10671@ulysses.homer.nj.att.com> Date: 30 Sep 88 17:31:06 GMT Organization: AT&T Bell Laboratories To: amiga-relay@UDEL.EDU Sender: amiga-relay-request@UDEL.EDU In article <12451@oberon.USC.EDU> papa@pollux.usc.edu (Marco Papa) writes: >In article <220@snll-arpagw.UUCP> paolucci@snll-arpagw.UUCP (Sam Paolucci) writes: >>As anybody seen anything like this before, or have any suggestions for >>getting around this Manx problem? > >program, though there is no reason the assembler should barf on it. Since >the MANX tech support has been dismal lately (Jim hasn't logged in on >BIX for months, and one can never get through the BBS or the tech support >number), I'll probably just send the sources (it's a PD program) to MANX >and hope they do something about it. By the way, this is all with MANX latest >release, 3.60b (after munging to work with REZ). Not to deny or concur with Marco's assesment of Manx's tech support as of late, I just wanted to point out that Jim himself has been hard at work on the 4.0 release of the compiler and SDB which he has promised to show at the October JAUG meeting. I believe he will have something to preview at AmiExpo as well. I'm sure that has something to do with the fact that he hasn't been logged in to BIX etc. His goal I'm sure is to solve these problems you are experiencing with the 4.0 release as well as provide numerous new features (and bugs too I'm sure - 1/2 :-) ) - should be a real win. >-- Marco Papa 'Doc' Eric Lavitsky, The Man of Many Hats ARPA: eric@topaz.rutgers.edu or eric@ulysses.att.com UUCP: {att,ucbvax}!ulysses!eric or {wherever!}rutgers!topaz!eric SNAIL: 34 Maplehurst Ln, Piscataway, NJ 08854 "To err is human; To really f*ck up requires the root password."
paolucci%snll-arpagw.uucp@UDEL.EDU (10/04/88)
Received: from CUNYVM by CUNYVM.BITNET (Mailer X2.00) with BSMTP id 4836; Sun, 02 Oct 88 00:31:21 EDT Received: from UDEL.EDU by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with TCP; Sun, 02 Oct 88 00:31:18 EDT Received: by Louie.UDEL.EDU id aa00856; 1 Oct 88 11:37 EDT Received: from Louie.UDEL.EDU by Louie.UDEL.EDU id aa00592; 1 Oct 88 11:17 EDT Received: by Louie.UDEL.EDU id af00435; 1 Oct 88 11:13 EDT Received: from USENET by Louie.UDEL.EDU id aa29857; 1 Oct 88 10:34 EDT From: Sam Paolucci <paolucci@snll-arpagw.uucp> Subject: Re: Manx bug Message-ID: <221@snll-arpagw.UUCP> Date: 1 Oct 88 04:18:47 GMT Organization: Sandia National Labs, Livermore To: amiga-relay@UDEL.EDU Sender: amiga-relay-request@UDEL.EDU In article <12451@oberon.USC.EDU> papa@pollux.usc.edu (Marco Papa) writes: +In article <220@snll-arpagw.UUCP> paolucci@snll-arpagw.UUCP (Sam Paolucci) writes: +>I was compiling a sizable code and I got the following error from the +>assembler (it got through the compiler fine :-)): +> +> "Line 802 #Pc relative out of range, -130." +> +>As anybody seen anything like this before, or have any suggestions for +>getting around this Manx problem? + +Yep, I've seen it a LOT with VERY LARGE C sources. The compiler generates +the code with no errors reported, and then the assembler gives the above +message. It usually goes into a loop in which all labels after the first +one flagged will all give the "pc out of range" message. This is either +a bug in the compiler (which generates bad code), or the assembler +(which cannot process a large source). By the way, in my case the +.asm file output by the compiler was 600K (sources!). So it wasn't a small +program, though there is no reason the assembler should barf on it. Since +the MANX tech support has been dismal lately (Jim hasn't logged in on ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +BIX for months, and one can never get through the BBS or the tech support +number), I'll probably just send the sources (it's a PD program) to MANX +and hope they do something about it. By the way, this is all with MANX latest +release, 3.60b (after munging to work with REZ). + +-- Marco Papa 'Doc' Talking about tech support, after MANY attempts I finally get through their tech support number to report several bugs and the person on the other end HANGS UP on me while I'm trying to explain to him the first bug. And THAT is what I pay for the commercial license? Jim where are you? If Manx doesn't shape up they are going to start losing customers. Personally I'm going to write them a stern letter. -- -+= SAM =+- "the best things in life are free" ARPA: paolucci@snll-arpagw.llnl.gov
eric%hector.uucp%UDEL.EDU@cunyvm.cuny.edu (10/04/88)
Received: from CUNYVM by CUNYVM.BITNET (Mailer X2.00) with BSMTP id 5508; Mon, 03 Oct 88 21:10:41 EDT Received: from UDEL.EDU by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with TCP; Mon, 03 Oct 88 21:10:38 EDT Received: from Louie.UDEL.EDU by Louie.UDEL.EDU id ag10567; 3 Oct 88 18:08 EDT Received: from USENET by Louie.UDEL.EDU id aa10215; 3 Oct 88 17:58 EDT From: eric%hector.uucp@UDEL.EDU Subject: Re: Manx bug Message-ID: <4385@louie.udel.EDU> Date: 3 Oct 88 21:56:44 GMT To: amiga-relay@UDEL.EDU Sender: amiga-relay-request@UDEL.EDU Received: from CUNYVM by CUNYVM.BITNET (Mailer X2.00) with BSMTP id 4617; Fri, 30 Sep 88 19:34:27 EDT Received: from UDEL.EDU by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with TCP; Fri, 30 Sep 88 19:34:24 EDT Received: from Louie.UDEL.EDU by Louie.UDEL.EDU id aa12352; 30 Sep 88 15:01 EDT Received: from USENET by Louie.UDEL.EDU id aa12192; 30 Sep 88 14:53 EDT From: Eric Lavitsky <eric@hector.uucp> Subject: Re: Manx bug Message-ID: <10671@ulysses.homer.nj.att.com> Date: 30 Sep 88 17:31:06 GMT Organization: AT&T Bell Laboratories To: amiga-relay@UDEL.EDU Sender: amiga-relay-request@UDEL.EDU In article <12451@oberon.USC.EDU> papa@pollux.usc.edu (Marco Papa) writes: >In article <220@snll-arpagw.UUCP> paolucci@snll-arpagw.UUCP (Sam Paolucci) writes: >>As anybody seen anything like this before, or have any suggestions for >>getting around this Manx problem? > >program, though there is no reason the assembler should barf on it. Since >the MANX tech support has been dismal lately (Jim hasn't logged in on >BIX for months, and one can never get through the BBS or the tech support >number), I'll probably just send the sources (it's a PD program) to MANX >and hope they do something about it. By the way, this is all with MANX latest >release, 3.60b (after munging to work with REZ). Not to deny or concur with Marco's assesment of Manx's tech support as of late, I just wanted to point out that Jim himself has been hard at work on the 4.0 release of the compiler and SDB which he has promised to show at the October JAUG meeting. I believe he will have something to preview at AmiExpo as well. I'm sure that has something to do with the fact that he hasn't been logged in to BIX etc. His goal I'm sure is to solve these problems you are experiencing with the 4.0 release as well as provide numerous new features (and bugs too I'm sure - 1/2 :-) ) - should be a real win. >-- Marco Papa 'Doc' Eric Lavitsky, The Man of Many Hats ARPA: eric@topaz.rutgers.edu or eric@ulysses.att.com UUCP: {att,ucbvax}!ulysses!eric or {wherever!}rutgers!topaz!eric SNAIL: 34 Maplehurst Ln, Piscataway, NJ 08854 "To err is human; To really f*ck up requires the root password."
sekoppenhoef@lotus.uwaterloo.ca (07/06/90)
I have found a case where the MANX C compiler (any version) generates bad code.
I discovered this while porting GNU awk 2.11 from MSDOS to the AMIGA (it works
now).
They do some error checking?? using a macro in similar form to:
#define MAC(a,b) { \
/* some processing */ \
if (b) { \
fprintf (stderr, b); \
} \
}
In some(all) cases, b is of the form "error message here" ie it is used
in calls such as MAC(code, "can't open file")
For the resulting code
if ("can't open file")
...
MANX generates a tst.l #.12 (12 arbitrary) which is an instruction
that the assembler doesn't recognize (Opcode operands did not match,
src=0, dest=400) ie the immediate mode of this operand is not recognized.
Is this construct legal in C (I believe there is nothing wrong with it)?
Could somebody pass this onto the people at MANX so that they may correct it?
Also, SDB 5.0b does NOT like long source files. I had to debug the source
file that was generated by bison (~3000 lines) and when SDB was displaying
the file it looks as though it did the following:
open source file
read in n lines of text
display source line
close file
open source file
read in n+1 lines of text
display source line
close file
... for each line of text in the source window.
This is not acceptable!!! When debugging around line 2700, it took about
10 seconds to refresh the window, and this had to be done every time the
source window scrolled.
It was also slower than 5.0a on skipping over library routines such as
open(), tmpnam(). (These took approx 15 seconds one time)
Enough of these gripes. Hopefully MANX will see it in there infinite wisdom
to at least fix the way SDB displays the source code.
-- Scotte
(sekoppenhoef@lotus.waterloo.edu) A friend's account