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.