knurlin@trwspf.TRW.COM (Scott Karlin) (02/04/88)
A few weeks ago, I posted a question about using
the Cause() function to generate an interrupt.
For those of you who might be interested there
were two problems: (1) NT_SOFTINT should be changed
to NT_INTERRUPT and (2) the compiler was too smart
for my own good (the compiler saw that abort was
always 0 so it didn't bother to test it each time
through the loop). Here is the corrected code:
#include <exec/types.h>
#include <exec/interrupts.h>
#include <stdio.h>
int abort;
/* Compile with Lattice 4.0 using -y -v options */
void main()
{
struct Interrupt interrupt;
int aborttest(); /* new */
void InterruptCode();
abort = 0;
interrupt.is_Node.ln_Type = NT_INTERRUPT; /* was NT_SOFTINT */
interrupt.is_Node.ln_Pri = 0;
interrupt.is_Node.ln_Name = "test";
interrupt.is_Code = InterruptCode;
Cause(&interrupt);
while(aborttest() == 0) /* aborttest() was abort */
{
printf(".");
Delay(50);
}
printf("abort = 1\n");
return;
}
int aborttest() /* new subroutine */
{
return(abort);
}
void InterruptCode()
{
abort = 1;
return;
}
--
-- Scott Karlin
TRW, Bldg O2-1761, One Space Park, Redondo Beach, CA 90278
USENET: knurlin@trwspf.trw.com Phone: (213) 535-3785
{sdcrdcf, scgvaxd, ucbvax}!trwrb!trwspf!knurlinewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (02/06/88)
In article <699@trwspf.TRW.COM> knurlin@trwspf.UUCP (Scott Karlin) writes: >(2) the compiler was too smart <-- [ you call this smart? ] >for my own good (the compiler saw that abort was >always 0 so it didn't bother to test it each time >through the loop). > > >#include <exec/types.h> >#include <exec/interrupts.h> >#include <stdio.h> > >int abort; > >/* Compile with Lattice 4.0 using -y -v options */ > ActivateFlame (PLAYFUL_MODE); My opinion of the Lattice compiler falls by the microsecond, John Toebes' extreme talent notwithstanding. If Lattice was really concerned about making good compilers, this "optimization" would not be a default. Look at your Friendly Neighborhood UNIX System sometime, and check the man page for 'cc'. They all seem to have the flag: -O It means to attempt code optimization. It is not the default. If you don't supply the flag, the compiler plays dumb, and compiles the code you wrote. I'm always quietly amused when I hear about dim-witted compilers making a move like this. "Gee! I'm just SOOOO smart! I think I'll optimize this test away, since that's what the programmer must REALLY want. After all, what does THAT programmer know? Gosh, I SOOO proud of myself! I think I'll go off and optimize all his 'printf' statements and substitute the print functions that he really MEANT to call behind his back!...." InactiveFlame (); Actually, I suppose this is why dpANS thought up the 'volatile' keyword, which probably should have been used in Scott's program. Does Lattice 4.0 support that one? _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape ihnp4!ptsfa -\ \_ -_ Recumbent Bikes: dual ---> !{well,unicom}!ewhac O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor
toebes@sas.UUCP (John Toebes) (02/17/88)
In article <5162@well.UUCP>, ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: > In article <699@trwspf.TRW.COM> knurlin@trwspf.UUCP (Scott Karlin) writes: > >(2) the compiler was too smart <-- [ you call this smart? ] > >for my own good (the compiler saw that abort was > >always 0 so it didn't bother to test it each time > >through the loop). Actually, I haven't seen the code in question, but the compiler has no code for detecting tests on automatice variables. If it did, it certainly would not be the default. I suspect that what we have here is 'a bug' that needs to be corrected. To my knowledge, it has not been reported to the Lattice tech support (otherwise I would have already fixed it :-). If someone feels inclined to mail it to me I will find out what is going on and make sure it is fixed. > ActivateFlame (PLAYFUL_MODE); > > My opinion of the Lattice compiler falls by the microsecond, John > Toebes' extreme talent notwithstanding. Thanks for the compliment, I am sorry you feel that way, we are working hard to seriously advance the state of compiler technology on the Amiga so that people take this machine seriously. If you will look, each release of the compiler has been a significant improvement over the previous one as we learn more about what people want AND ways to do things legally. To the best of my ability to detmine, all versions of the compiler and code generated by them will work on ALL versions of AmigaDos - including 1.0. > > If Lattice was really concerned about making good compilers, this > "optimization" would not be a default. And it isn't. The compiler should strive to always produce code that works regardless of how convoluted or volatile the expressions that a user might code. However this doesn't mean that someone can't come up with a situation that hasn't been thought of before. Look at how often PCC broke in the early stages because of the type of compiler technology used. It still isn't provably correct (although one would hope that with the volume of code that has gone through it almost everything has been tried) since it is always possible to create a blocked state. > -O > It means to attempt code optimization. It is not the default. If > you don't supply the flag, the compiler plays dumb, and compiles the code > you wrote. Agreed. However one needs to put a limit on where optimizations are started. Is it legit for a compiler to optimize a multiply by 2 into a shift left? (But not to make a divide by 2 into a shift right of course) How about subsuming array indexing? Or even keeping a variable in a register for a short period of time? If the compiler generated code EXACTLY as a user wrote it, we would put compiler writers out of business because everything would be a simple template. :-> Actually we would have to eliminate all variables and only allow ones like D0, A0, D1, A1, ... :-> Seriously, the compiler should optimize code anytime it is SAFE IN ALL situations. Other than that, the user shold be required to specify that he wants a specific optimization to be applied. > I'm always quietly amused when I hear about dim-witted compilers > making a move like this. "Gee! I'm just SOOOO smart! I think I'll > optimize this test away, since that's what the programmer must REALLY want. > After all, what does THAT programmer know? Gosh, I SOOO proud of myself! I > think I'll go off and optimize all his 'printf' statements and substitute > the print functions that he really MEANT to call behind his back!...." Good point. I have always hated that happening to me. That's why I got into compiler development because I feel I have the opportunity to fix the code and make it work the way I want to. What started it for me was when my wife (she wasn't then) wrote a memory test program under PL/I and the compiler optimized out first the 'poke/peek' then the look it was in followed by the entire subroutine containing the loop. > InactiveFlame (); > > Actually, I suppose this is why dpANS thought up the 'volatile' > keyword, which probably should have been used in Scott's program. Does > Lattice 4.0 support that one? > > Leo L. Schwab -- The Guy in The Cape ihnp4!ptsfa -\ Not yet :-), because the code generated always assumes that externals and any aliased variables are volatile. This is changed from the 2.xx versions which had a switch -a which told the compiler that you might be doing something that is aliased. You can rest assured that before any such optimizations are put in we would support the volatile keyword. We resisted doing what a certain compiler vendor on another machine did - putting in the keyword and then ignoring it. You only hurt the user in the long run. I'm not a particular fan of dpANS because it is designed more by compiler writers with less emphasis on the user. The general rule of thump that seems to apply there is "if it doesn't work on EVERY system it won't go into the standard". open(), read(), and write() aren't even in the standard library because they won't work on every system. It is fine for dpANS to require volatile for this program to work, but it is my humble opinion (and not necessarily anyone else's) that this type of program should work by default and the volatile required only if the user invokes a global optimizer with a -O style switch (which is what -O usually does for PCC anyway). I hope I've babbled long enough - what I say is my own and nobody else wants it anyway. Opposing opinions are certainly welcome. /*---------------------All standard Disclaimers apply---------------------*/ /*----Working for but not officially representing SAS or Lattice Inc.-----*/ /*----John A. Toebes, VIII usenet:...!mcnc!rti!sas!toebes-----*/ /*------------------------------------------------------------------------*/