Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site cbdkc1.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!lll-crg!dual!qantel!ihnp4!cbosgd!cbdkc1!gwe
From: gwe@cbdkc1.UUCP ( George Erhart  )
Newsgroups: net.micro.mac
Subject: MegaMax C & assembler (problem)
Message-ID: <1089@cbdkc1.UUCP>
Date: Mon, 12-Aug-85 09:12:37 EDT
Article-I.D.: cbdkc1.1089
Posted: Mon Aug 12 09:12:37 1985
Date-Received: Sun, 18-Aug-85 21:32:05 EDT
Reply-To: gwe@cbdkc1.UUCP ( George Erhart  )
Organization: AT&T Bell Laboratories, Columbus
Lines: 51

Here is some food for thought for those of you thinking about buying
MegaMac C, or those of you wanting to port code between Mac C compilers:

I was playing with the MacinTalk Aztec C interface this weekend, I was trying
to port it to MegaMax C, when I noticed several problems. First, MegaMax C
will not take the following *legal* assembler statement:

	move.l	(SP)+,(SP) 

		or

	move.l (USP)+,(USP)

These two statements are simply moving the long word on the stack up one
"notch" on the stack. In this case, it was moving the return address for
a subroutine. I consulted a manual on Motorola 68000, and discovered that
the A7 register is another name for the SP in supervisor mode or USP
in user mode. So, I tried:

	move.l (A7)+,(A7)

This permutation had no problem. The MegaMax manual includes a brief
BNF for the assembler portion which shows only the A0-7 registers having
the auto-increment and auto-decrement modes. (Rather silly I think, since
it would be nice to use the stack operation addressing modes on the stack
pointer using the proper name!)

The second item was that hex constants had to be in the form of 

	0xFFFF	- where FFFF is the hex number

	not:

	$FFFF

as the Motorola manual suggests. This time, the BNF in the MegaMax manual
does not point out this inconsistancy. (They do claim to follow the Motorola
standard!)

Finally, I was very frustrated to discover the VAST number of differences in
the header files between MegaMax and Aztec C. This amounted to large scale
changes to get things to compile. In some cases, I had to dig through IM to
discover what the the structures were really suppose to look like. From
what I could see, there are some holes in the MegaMax C header files. Some
of the items in the device parameters structure had names like "filler3"?

It appears that low level code, such as the MacinTalk interface will not be
very portable. (Or perhaps portable at all?)  I finally got it to compile,
but it does not work yet. (I will post when I get it working!)

George Erhart