🚀 go-pugleaf

    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.