Path: utzoo!utgpu!water!watmath!clyde!bellcore!decvax!ucbvax!pasteur!ames!ll-xn!mit-eddie!husc6!cmcl2!brl-adm!umd5!uvaarpa!mcnc!rti!sas!toebes
From: toebes@sas.UUCP (John Toebes)
Newsgroups: comp.sys.amiga
Subject: Re: A bug in Lattice 4.0
Message-ID: <336@sas.UUCP>
Date: 17 Feb 88 12:54:19 GMT
References: <1070@pembina.UUCP> <648@applix.UUCP>
Organization: SAS Institute Inc.,Cary NC,25712
Lines: 69

In article <648@applix.UUCP>, scott@applix.UUCP (Scott Evernden) writes:
> In article <1070@pembina.UUCP> andrew@alberta.UUCP (Andrew Folkins) writes:
> >I don't know about you, but if I compile & run this it's a guaranteed visit
> >from the guru.
> >  (... a program which doesn't work under Lattice 4.0 ...)
> The problem is more simply demonstrated:
>     #include <string.h>
>     char *foo = "test";
>     if (strlen(foo) > 0)
> OMD reveals:
> 001E 4A88                       TST.L     A0                   ...oops
:-) You mean TST doesn't work on address registers? :-)
> 
> The in-line strlen() does its work in A registers, but the compiler
> performs the >0 test via a TST.L Ax, which is an illegal instruction.
> Sounds like you might want to remove the <strings.h> include.
Good detective work.  What is happening is that one spot in the compiler
never expected a data item to appear in an address register and generates
the illegal instruction.  It has been corrected in the patch (RSN) but
we are still beta testing the patch before it goes out - we want to
make sure that it fixes everything known.  Also because it is a patch
we are being extra careful.  When it is available I will see about
getting it to comp.amiga.sources/binaries (unless someone beats me to it)
> 
> Lattice 4.0 has some other peculiarities.  I've seen the compiler
> generate some useless sequences, like reloading a register with the
> same value twice, or loading a register and then never using it.
This was noted in the beta testing process but because of where in the
compiler it is generated, it was felt safer to leave this in than to risk
potential bad code side effects from a last minute optimization.  I don't
mind taking flack for code that can be improved (actually I kind of like it
because it shows that there's still work for me that I enjoy doing) but
don't like it when a compiler problem shows in someone's code.
> Version 4.0 does, however, do a nice job with array indexing, particularly
> constructs like:
> 
>     array[n] = array[n+1];
> 
> handy for those who write such code.
Actually it isn't as smart as I wanted and have done much to improve it since
then.  Who knows, maybe one day even I will think the code it generates
is good enough (nah, couldn't happen - I count cycles on everything - but
you never know)
>  It also is much smarter than Manx
> in the area of small constant multiplies.  Something like a = 3*b is
> handled much more intelligently by Lattice.
Thank you.  I worked hard on this one.  Ideas for other optimizations are
always welcome.  The smaller the program that you have that illustrates
what you don't like in the code the better chance it has of getting
fixed.  (Remember that I have to wade through this stuff)
> Also, am I the only one who finds that Lattice consistently generates
> programs sensitive to phantom ^C aborts?  I mean, I execute a Lattice
> program, and the "User Abort" requester appears.  This problem has ALWAYS
> existed in ALL Lattice versions, and is also evident in some Lattice
> products, like Lattice Make Utility, for example.
> -scott
Actually what you are seeing is a failure of task cleanup of signals.  This
occurs most frequently for me with the Amiga search command.  You tend not
to see it with Manx programs because they don't do ^C checking by default.
I have tried several things to reduce how frequently they comde up and have
worked with Bill Hawes on his new Shell (excellent by the way) about the
problem to help it occur less frequently.  BTW - simply resetting the flag
in the startup code is not a good idea because it wouldn't allow you to hit
^C while the program is loading and have it abort immediately.

/*---------------------All standard Disclaimers apply---------------------*/
/*----Working for but not officially representing SAS or Lattice Inc.-----*/
/*----John A. Toebes, VIII             usenet:...!mcnc!rti!sas!toebes-----*/
/*------------------------------------------------------------------------*/