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