vantreeck@logic.dec.com (07/21/86)
I've called the Manx Tech support line at least a dozen times last week and always got a busy signal. So I'll post the following to USENET. Maybe Manx will read it here. The following are bugs I found with the 1.06H.1 version of the Manx Aztec C compiler and assembler for the Macintosh. Bug #1: using a displacement on the PC with index addressing mode causes incorrect machine code generation. The Manx assembler treats the displacement field as an address label. During the assembler's second pass it tries to resolve the label's address (which doesn't exist of course) and gives the #@!!, UNDOCUMENTED, "FATAL ERROR - label mismatch @PC=... label=0000". for example "jmp 2(PC, d7.w)" should generate a 02 in the last byte of the instruction, but the listing shows an "xx" which indicates a label there that it is trying to resolve. The following is a work-around. jmp foo(PC, d7.w) foo That generates the correct code! But using an address label for a displacement value... Bad! At least it should be documented. Bug #2: Using a displacement with control addressing mode in the movem instruction generates the correct opcodes but confuses the assembler (and linker). Depending on where the instruction is located the error message will be either: "FATAL ERROR - label mismatch" from the assembler or "FATAL ERROR - Branch out of range" from the linker. For example, movem.l 8(SP),d3-d7/a5-a6 will cause the error messages mentioned above. Obviously there's no "branch out of range" and no label to mismatch in that instruction. The following substitution will eliminate the error messages: move.l SP,a0 adda.w #8,a0 ; add displacement of 8 movem.l (a0),d3-d7/a5-a6 Of course the idea of movem is fewer instruction fetchs and faster execution, and the workaround looses those advantages. Bug #3: According to the Manx documentation the difference of two pointers is a long. But, in the following case where the "data" field is a pointer to a struct, I found that the following: register long result; result = p1->data - p2->data; will always cause a result equal to zero in my procedure! Either this is a bug, or the documentation needs a lot clarification. Also, there were no compiler nor run-time warnings about illegal type conversions. I found that the following modification coerced Manx's Aztec C to give the correct result: register long result; result = (long) p1->data - (long) p2->data; I still haven't figured out why the Manx assembler and compiler will not give any success, informational, nor error messages when I use the 3.1.1 system file (181KB) instead of the 71KB system file that came with distribution disks. All that comes to the screen is a new prompt when I use my system file. Their system file doesn't say which revision it is nor how it's been modified to make it work with their software. It took me quite a while to track down the problem of getting no output to the screen to a difference in system files. Anybody else seen this problem? I've spent too many hours trying to track down the cause of these bugs. It's not my idea of fun. George Van Treeck DECWRL::LOGIC::VANTREECK Digital Equip. Corp.
mark@hyper.UUCP (Mark Mendel) (07/23/86)
> register long result; > result = p1->data - p2->data; (where p1-data is a pointer to a struct) and > register long result; > result = (long) p1->data - (long) p2->data; should not be the same in any C, unless the size of the struct is 1. This is because C scales pointer differences to yield the number of things pointed at between the pointers, not the number of bytes. p1->data - p2->data is equivalent to ((long)p1->data - (long)p2->data) / sizeof(*p1->data). This will be zero if the two structs pointed at overlap. -- ------------------------------------------- Mark G. Mendel, Network Systems Corporation ihnp4!umn-cs!hyper!mark All opinions expressed herein, even the most arbitrary, are defended by my employer with religious fervor.
dlc@lanl.ARPA (Dale Carstensen) (07/27/86)
> I still haven't figured out why the Manx assembler and compiler > will not give any success, informational, nor error messages when > I use the 3.1.1 system file (181KB) instead of the 71KB system > file that came with distribution disks. All that comes to the > screen is a new prompt when I use my system file. Their system > file doesn't say which revision it is nor how it's been modified > to make it work with their software. It took me quite a while to > track down the problem of getting no output to the screen to a > difference in system files. Anybody else seen this problem? Does your 3.1.1 system have the Manx console driver installed? It warns about that in the manual, and in the update documentation, in several places. Just because the 1.06H version has the console driver in mixcroot.o doesn't mean the compiler or assembler were linked with mixcroot.o (I'd bet they weren't, in fact.) I just received my update yesterday and haven't tried it, but a new feature that sounds like it could save a lot of compile time is the +H option to pre-compile header files. There is also a symbolic debugger that works on the same Macintosh as the program under test, or through a serial port on a terminal.
stoltz@sun.uucp (Ben Stoltz) (07/28/86)
In article <5776@lanl.ARPA> dlc@lanl.ARPA (Dale Carstensen) writes: >...I just received my update yesterday and haven't tried it, but a new feature >that sounds like it could save a lot of compile time is the +H option to >pre-compile header files. There is also a symbolic debugger that works on >the same Macintosh as the program under test, or through a serial port on a >terminal. The external terminal feature of the debugger does not work for me. A few commands will parse correctly but most won't, almost as if the parity was set incorrectly (which it isn't). I reported the bug on Manx's west coast BBS. According to Jim Goodnow it will be forwarded to the appropriate people. Does anyone know anything about Manx's "Source Level Debugger" (sdb)? I saw a mention of it in Manx's ad in the current MacUser.