andrew@alberta.UUCP (Andrew Folkins) (02/04/88)
I don't know about you, but if I compile & run this it's a guaranteed visit
from the guru.
A while back it was mentioned that there were some patches available for
4.0. Any chance of seeing some of them here?
#include <stdio.h>
#include <string.h>
struct testrec
{
char string1[16];
};
struct testrec trec = { "Test1" };
void main()
{
if (strlen(trec.string1) > 0)
printf("length = %d\n", strlen(trec.string1));
}
--
Andrew Folkins ...ihnp4!alberta!andrew
The University of Alberta, Edmonton, Alberta, Canada
Remember, when all else is said and done, at least *we* have someplace to
park our keyboards.scott@applix.UUCP (Scott Evernden) (02/08/88)
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: 0010 206C 0006-01.2 MOVEA.L 01.00000006(A4),A0 0014 4A18 TST.B (A0)+ 0016 66FC BNE 00000014 0018 5388 SUBQ.L #1,A0 001A 91EC 0006-01.2 SUBA.L 01.00000006(A4),A0 001E 4A88 TST.L A0 ...oops 0020 6F04 BLE 00000026 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. 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. 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. 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. 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
kenchiu@phoenix.Princeton.EDU (Kenneth Chiu) (02/09/88)
In article <648@applix.UUCP> scott@applix.UUCP (Scott Evernden) writes: >Also, am I the only one who finds that Lattice consistently generates >programs sensitive to phantom ^C aborts? No, I've noticed that too. Like in arc. Has anyone noticed that the search command is prone to phantom ^Ds? It'll abandon a file as soon as it starts up. Is this just me?
kim@amdahl.uts.amdahl.com (Kim DeVaughn) (02/09/88)
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 ...) Since John Tobes is on the net (I think), perhaps he could post a list of the known bugs and/or fixes here ...? I logged on to the Lattice support BBS over the weekend, and didn't see any patch files, etc. for v4.0. Thanks! /kim -- UUCP: kim@amdahl.amdahl.com or: {sun,decwrl,hplabs,pyramid,ihnp4,uunet,oliveb,cbosgd,ames}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 CIS: 76535,25
jonesjg@xyzzy.UUCP (Greg Jones) (02/09/88)
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. > >#include <stdio.h> >#include <string.h> > >struct testrec > { > char string1[16]; > }; > >struct testrec trec = { "Test1" }; > >void main() >{ > if (strlen(trec.string1) > 0) > printf("length = %d\n", strlen(trec.string1)); >} >Andrew Folkins ...ihnp4!alberta!andrew I ran into this last week and spent some time debugging it and have determined both the problem and a work around. I hope to file a STR this week sometime. The problem is in the statement if(strlen(anystring) >0) I used the omd to disassemble the code to discover an illegal instruction TST.L A2. This instruction is being used to check to see if strlen returns 0. The problem is the addressing mode (address register direct ?) is not allowed with the TST instruction. (note: all other modes are allowed). Well the workaround is easy ... 1) remember rev 4.00 has strlen as a builtin. So the workaround is to bypass the builtin version till Lattice fixes the bug by ... #ifdef strlen #undef strlen #endif Of course you could change the definition in the string.h include file. This would be a better solution, but the compressed include files complicates the process. Hope this helps ... -- Greg Jones Data General, RTP, NC jonesjg@dg-rtp.dg.com ...!seismo!mcnc!rti!dg-rtp!jonesjg
dillon@cory.Berkeley.EDU (Matt Dillon) (02/10/88)
[This is Bryce Nesbitt, posting by remote-control] In article <648@applix.UUCP> scott@applix.UUCP (Scott Evernden) writes: >Also, am I the only one who finds that Lattice consistently generates >programs sensitive to phantom ^C aborts? No, no,no! It's not a bug in Lattice, it's a bug in the CLI. I'm surprised nobody mentioned this. If you type CTRL-C, wait two hours, then start up a program, the first thing it gets is the CTRL-C signal. -Bryce
hobie@sq.uucp (Hobie Orris) (02/12/88)
I had "phantom ^C aborts" when using diskwipe the first several times.
That's the only example I know of, though.
Hobie Orris |"Good book says you gotta be nice
guest of SoftQuad Inc., Toronto, Ont. | Or they're gonna put you on ice.
{ihnp4 | decvax | ? }!utzoo!sq!hobie | Good book says you gotta behave
| Or they'll send you to an early grave.
| What does it say in the bad book?"
| - Deja Voodoocmcmanis%pepper@Sun.COM (Chuck McManis) (02/14/88)
In article <648@applix.UUCP> scott@applix.UUCP (Scott Evernden) writes: >The problem is more simply demonstrated: > char *foo = "test"; Wonder what it does if you use : char foo[] = "test"; It has always bothered me that foo[] and *foo were not very orthogonal under Lattice, don't know how Manx deals with 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. I have not seen this at all, maybe something is stomping on your signal data? --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
sbower@lehi3b15.CSEE.Lehigh.EDU (Steve Bower) (02/17/88)
In article <648@applix.UUCP> scott@applix.UUCP (Scott Evernden) writes:
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
I have encountered that problem several times, and it seems to be
linked with MicroEMACS -- when you exit with ^X^C, it leaves the ^C
signal lying around, so the next program you run picks it up and acts
as if you had given IT a ^C. Fix? I dunno. I think if you hit a
couple of <CR>s in the CLI before you run your next program that'll
take care of it, but I'm at work now and can't verify that. Perhaps a
newer version of MicroEMACS would take care of it?
Steve.toebes@sas.UUCP (John Toebes) (02/17/88)
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-----*/ /*------------------------------------------------------------------------*/
FATQW@USU.BITNET (02/20/88)
This is what I'm quite sure is the case - don't trust me though!
The CLI doesn't clear the CTRL-C sigbit before it starts a program. If it
did, the problem would be solved.
The normal BCPL AmigaDOS commands which honor CTRL-C probably have some kind
of startup code which automatically clears the CTRL-C sigbit before going on.
The Lattice startup scripts don't do this. I don't know about Manx. So
you can get CTRL-C's that were pressed before the program was started.
Three solutions I can think of.
Change the CLI (in the next KS/WB release) to clear CTRL-C before starting
programs.
Edit the startup code you use to clear the CTRL-C bit before starting the
main program.
Put something like this at the beginning of main():
SetSignal(0,SIGBREAKF_CTRL_C);
Yes, I know the RKM states this as dangerous, but I really don't think it
would be dangerous to use in this way, or other `controlled' ways.
(you define `controlled'.)
Bryan
Bryan Ford //// A computer does what \\\\
Snail: 1790 East 1400 North //// you tell it to do, not \\\\
Logan, UT 84321 \\\XX/// what you want it to do. \\\XX///
Email: FATQW@USU.BITNET \XXXX/ Murphy's Law Calendar 1986 \XXXX/peter@nuchat.UUCP (Peter da Silva) (02/21/88)
In article <41879@sun.uucp>, cmcmanis%pepper@Sun.COM (Chuck McManis) writes: > > I mean, I execute a Lattice program, and the "User Abort" requester > > appears. > I have not seen this at all, maybe something is stomping on your signal > data? I have seen "ARC" do this with no provocation. If ARC's written in Lattice that would explain it. -- -- a clone of Peter (have you hugged your wolf today) da Silva `-_-' -- normally ...!hoptoad!academ!uhnix1!sugar!peter U -- Disclaimer: These aren't mere opinions... these are *values*.
nor1675@dsacg2.UUCP (Michael Figg) (03/03/88)
In article <664@nuchat.UUCP>, peter@nuchat.UUCP (Peter da Silva) writes: > In article <41879@sun.uucp>, cmcmanis%pepper@Sun.COM (Chuck McManis) writes: > > > I mean, I execute a Lattice program, and the "User Abort" requester > > > appears. > > > I have not seen this at all, maybe something is stomping on your signal > > data? > > I have seen "ARC" do this with no provocation. If ARC's written in Lattice > that would explain it. I have been hit with this requester a couple of times when I start a compile with 4.0. It goes away after hitting continue and doesn't seem to effect anything but is somewhat irritating. Does anybody know what is causing this. It happened last time during a full moon. hmmmm. Other than that problem 4.0 is a joy to use after living with 3.03 for a year. thanks. -- "Don't quote me on this!" Michael Figg DLA Systems Automation Center Columbus, Oh. (614)-238-9036
farinas@geocub.UUCP (Luis Farinas) (03/16/88)
I think somebody has yet given the answer. When you hit ^C, AmigaDos will remember it and the first program which will test this signal will find it set, even if you did it an hour ago. Jean-Marc Alliot