manning@mmm.UUCP (Arthur T. Manning) (04/06/89)
In the following code, the compiler concatenates the two SEPERATE sections
of assembly together as though they were all inside the if statement's
scope. In the second case (with only a semicolon added) the compiler does
what it is expected to do. Apparently "}" is not enough for the compiler
to know that the if{} has ended and to put the rest of the assembly code
outside the scope.
Would you believe we found this bug in an interrupt service routine?
We would never have found it without our VMETRO vme bus debugger.
if(foo) {
#asm
move.l a1,a2
#endasm
} /* end of if's scope, right? */
/* Wrong! The compiler doesn't think so, and puts these together. */
#asm
move.l a2,a3
#endasm
if(foo) {
#asm
move.l a1,a2
#endasm
}
; /* REALLY the end of if's scope */
/* the compiler knows now that the semicolon is there... */
#asm
move.l a2,a3
#endasm
--
Arthur T. Manning Phone: 612-733-4401
3M Center 518-1 FAX: 612-736-3122
St. Paul MN 55144-1000 U.S.A. Email: manning@mmm.uucpkim@mcrware.UUCP (Kim Kempf) (04/06/89)
In article <1248@mmm.UUCP> manning@mmm.UUCP (Arthur T. Manning) writes: >In the following code, the compiler concatenates the two SEPERATE sections >of assembly together as though they were all inside the if statement's >scope. In the second case (with only a semicolon added) the compiler does >what it is expected to do. Apparently "}" is not enough for the compiler >to know that the if{} has ended and to put the rest of the assembly code >outside the scope. > >Would you believe we found this bug in an interrupt service routine? > >We would never have found it without our VMETRO vme bus debugger. >Arthur T. Manning Phone: 612-733-4401 >3M Center 518-1 FAX: 612-736-3122 >St. Paul MN 55144-1000 U.S.A. Email: manning@mmm.uucp Here we go again.... The comments made here are absolutely untrue. This exact situation is described in T.F.M on page 3-3 paragraph 5 on that page headed "Interfacing to Assembly Language". The quality OS-9 C compiler and OS-9 itself is superb as can be attested to by a vast list of Microware customers. The list of unsatisfied customers is trivial and a few of those haunt USENET. ---------------- Kim Kempf, Microware Systems Corporation {sun,uunet}!mcrware!kim
blarson@skat.usc.edu (Bob Larson) (04/07/89)
In article <1003@mcrware.UUCP> kim@mcrware.UUCP (Kim Kempf) writes: >In article <1248@mmm.UUCP> manning@mmm.UUCP (Arthur T. Manning) writes: >>We would never have found it without our VMETRO vme bus debugger. The bug would have been easily discovered on inspection of the compiler output with the -a and -c options. Not inspecting the -a -c compiler output when using #asm, especially in device drivers, is asking for trouble. >The quality OS-9 C >compiler and OS-9 itself is superb as can be attested to by a vast list >of Microware customers. This is a bit much comming from a microware employee that works on said C compiler. I've certainly found my share of bugs in the os9/68k C compiler, most, but not all, of which are fixed in the latest release. > The list of unsatisfied customers is trivial >and a few of those haunt USENET. Few os9/68k users haunt USENET. I don't think lack of bad comments here can be counted as much. One outstanding bug I know of is variables named PC, SP, a0, d7, cc, etc. The assembler won't let variables be named the same as registers. (In my opinion, the proper fix would be to rename the registers as far as the assembler is concerned to something that isn't a valid C identifier. There would have to be an option for the old names to be used by old code.) Microware has been aware of this problem for several releases, but doesn't seem to be in a rush to fix it. Bob Larson Arpa: Blarson@Ecla.Usc.Edu blarson@skat.usc.edu Uucp: {sdcrdcf,cit-vax}!oberon!skat!blarson Prime mailing list: info-prime-request%ais1@ecla.usc.edu oberon!ais1!info-prime-request
manning@mmm.UUCP (Arthur T. Manning) (04/07/89)
In article <1248@mmm.UUCP> kim@mcrware.UUCP (Kim Kempf) writes: >In article <1248@mmm.UUCP> manning@mmm.UUCP (Arthur T. Manning) writes: >>In the following code, the compiler concatenates the two SEPERATE sections >>of assembly together as though they were all inside the if statement's >>scope. In the second case (with only a semicolon added) the compiler does >>what it is expected to do. Apparently "}" is not enough for the compiler >>to know that the if{} has ended and to put the rest of the assembly code >>outside the scope. >> > >Here we go again.... The comments made here are absolutely untrue. What? Are you saying that the bug (or idiosyncracy) does not exist? I assure you, it is really there in the "superb" 3.0 compiler. Am I wrong to expect the compiler to work with inline assembly? >This exact situation is described in T.F.M on page 3-3 paragraph 5 on >that page headed "Interfacing to Assembly Language". The manual reference suggests not to use #asm-#endasm on the same page, but to use seperate modules instead. Nowhere do I see the "exact" situation described. > The quality OS-9 C compiler and OS-9 itself is superb as can be attested >to by a vast list of Microware customers. Am I supposed to feel some sort of peer pressure? Should I feel guilty about complaining? >The list of unsatisfied customers is trivial and a few of those haunt >USENET. Oh, so I've suddenly become a ghost by reporting a bug. Call me the "Micro-wraith" if you like. > >---------------- >Kim Kempf, Microware Systems Corporation {sun,uunet}!mcrware!kim Does this person really represent Microware? These are irresponsible remarks to and about a customer - whether unsatisfied or not (I never said I was unsatisfied). Not only did this "representative" not address the bug, they called me a trivial liar. If Microware refuses to acknowledge admittedly minor bugs, what do they do about other problems? I anxiously await a response from someone else at Microware.-- Arthur T. Manning Phone: 612-733-4401 3M Center 518-1 FAX: 612-736-3122 St. Paul MN 55144-1000 U.S.A. Email: manning@mmm.uucp