[net.micro.mac] MegaMax C & assembler

gwe@cbdkc1.UUCP ( George Erhart ) (08/12/85)

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

rick@ut-ngp.UTEXAS (Rick Watson) (08/14/85)

I have a working version of the MacinTalk interface for MegaMax C
that I got by disassembling the interface that runs under the
Workshop.  Can anyone comment on the legality of posting of such
code, since it is 95% Apple code (Larry?).  Note that I am not going to
post MacinTalk, just the interface.

Rick Watson
University of Texas Computation Center
Austin, TX
rick@ut-ngp.arpa
...ut-sally!ut-ngp!rick

brad@gcc-bill.ARPA (Brad Parker) (08/15/85)

In article <2242@ut-ngp.UTEXAS> rick@ut-ngp.UTEXAS (Rick Watson) writes:
>
>I have a working version of the MacinTalk interface for MegaMax C
>that I got by disassembling the interface that runs under the
>Workshop.  Can anyone comment on the legality of posting of such
>code, since it is 95% Apple code...

Speaking of which, what ever happened to the "object file/object library"
which Apple was supposed to provide to all of the compiler developers?
This was suppose to give us a standard object format so we wouldn't have to
waste our time dissassembling and reassembling module interfaces (like
AppleTalk and MacInTalk).

I heard this touted by Tech Support (which is at the beach till monday!)
many months ago and since then I've heard nothing.

(mild flame - you should hear me when I really get worked up ;-)

-- 

J Bradford Parker
uucp: seismo!harvard!gcc-bill!brad

"She said you know how to spell AUDACIOUSLY? I could tell I was in love...
You want to go to heaven? or would you rather not be saved?" - Lloyd Coal

gwe@cbdkc1.UUCP ( George Erhart ) (08/22/85)

In article <2242@ut-ngp.UTEXAS> rick@ut-ngp.UTEXAS (Rick Watson) writes:
>I have a working version of the MacinTalk interface for MegaMax C
>that I got by disassembling the interface that runs under the
>Workshop.  Can anyone comment on the legality of posting of such
>code, since it is 95% Apple code (Larry?).  Note that I am not going to
>post MacinTalk, just the interface.

Please post at least the .o and .h file for this interface!!! An Aztec C
version was already posted. Since I did not see any complaints from Apple,
I will assume that they did not object. (Besides, they can't expect everyone
to develop software with only one version of PASCAL or the assembler!)

Thanks,

George Erhart