Xref: utzoo comp.sys.mac.programmer:1962 comp.lang.c++:1401
Path: utzoo!attcan!uunet!husc6!rutgers!apple!dan
From: dan@Apple.COM (Dan Allen)
Newsgroups: comp.sys.mac.programmer,comp.lang.c++
Subject: Re: AT&T C++ ports to the Mac?
Keywords: Aztec C
Message-ID: <15235@apple.Apple.COM>
Date: 7 Aug 88 03:08:43 GMT
References: <325@intek01.UUCP> <1479@mcgp1.UUCP>
Reply-To: dan@apple.apple.com.UUCP (Dan Allen)
Organization: Apple Computer Inc, Cupertino, CA
Lines: 30

In article <1479@mcgp1.UUCP> fst@mcgp1.UUCP (Skip Tavakkolian) writes:
>In article <325@intek01.UUCP>, mark@intek01.UUCP (Mark McWiggins) writes:
>> We're about to adopt C++ as our standard language, and probably get the
>> AT&T source, since we target several environments.  Has anyone ported
>> the translator to the Mac?  I know it's a big program and thus would
>> probably choke MPW or Lightspeed because of their 32K global data limit.
>[ deleted ]
>> -- 
>> Mark McWiggins			UUCP:		uunet!intek01!mark
>
>The problem, as I understand it, is to find a C compiler and assembler that
>would be able to digest the output of the C++ (at&t's cfront).  It generates
>some very long names that are required to be distinguishable beyond 30 or so
>chars even by the assembler.

Although this is a problem for many assemblers, it does NOT happen to be
the MPW assembler problem.  All of the MPW language translators (C,
Pascal, Assembly) can deal with at least 64 character names without any
problem.  The 32K global limit is an architectural limitation of the
Motorola 68000 (not 68020, however) and the way it interacts with the
conventions set up for the Macintosh OS.  (Address register addressing
is limited to a 16-bit offset for the 68000, and that is how global data
is addressed in the Mac OS; it is a signed offset, so you have 32K of
register A5 relative space.) This is not a real limitation, however,
because using the heap and dynamic calls like malloc, you can address up
to available RAM (8 MB for Mac II running Mac OS).

Dan Allen
Software Explorer
Apple Computer