Re: GCC for Mac OS X (fwd)

[Theodore C. Belding]

The main hurdle for running ObjC Swarm applications on non-Unix platforms
has always been the dependence on gcc's version of ObjC (since there's no
standard for ObjC). The Swarm team will hopefully correct me if I'm wrong
but I think there's two implications. First, the fact that gcc is being
ported to MacOS X, along with the fact that MacOS X will be "FreeBSD with
a Mac GUI", means that eventually you will be able to run ObjC Swarm
applications natively under MacOS X (FreeBSD is a free version of Unix,
analogous to Linux, so almost everything you can do on Linux should also
be possible on FreeBSD/MacOS X). Second, there would perhaps be a
possibility of making a real "MacSwarm" variant, with native MacOS
menus, etc. 

At one point Apple was pushing ObjC as the canonical programming language
for MacOS X (because they bought NeXT). I think they've backed down from
that, but MacOS X *may* still have very good ObjC support (perhaps even
better than Unix), for all of you ObjC fans. I haven't kept up with all of
Apple's announcements about MacOS X, though, so I might be wrong on this
point.
-Ted

--
Ted Belding                              address@hidden 
University of Michigan Center for the Study of Complex Systems
Homepage: http://www-personal.umich.edu/~streak/
PGP key:  http://www-personal.umich.edu/~streak/pgp-key.html

On Sat, 12 Feb 2000, Darren Schreiber wrote:

> Thanks for that forward Ted.  As one of the Mac Fans here I'm particularly
> interested in this kind of info.
> 
> Of course, I'm still not sure I understand the all the implications.  If
> GCC for MacOS X becomes fully compliant with the standard, does that mean
> that Swarm would easily (or reasonably easily) compile for it?
> 
> Thanks in advance...
> 
>       Darren
> 
> 
> >---------- Forwarded message ----------
> >Date: Fri, 11 Feb 2000 15:34:31 -0800
> From: Stan Shebs <address@hidden>
> >To: address@hidden
> >Subject: GCC for Mac OS X
> >
> >Hi all, some of you may know me from GDB, and a few with long memories
> >may remember that I did a couple Mac ports of GNU a while back (those
> >silly mpw-* files scattered everywhere are my fault).
> >
> >I've just started working for Apple's Mac OS X tools team.  This may come
> >as a surprise, but Mac OS X is basically FreeBSD 3.2 with a GUI.  Not only
> >that, but in a few months it will be shipping on every new Mac - so yes
> >indeed, your grandmother will be running Unix!
> >
> >Anyway, my tasks here are twofold: 1) to reduce the divergence between
> >Apple's GCC and FSF GCC, and 2) to help improve the compiler in various
> >ways.  Apple has a half-dozen engineers working on GCC that have been
> >quietly following along with the development trunk, but the set of
> >patches is still pretty large.  I'll be looking at the local patches,
> >and sending in those that seem worthwhile for the mainstream.  (Apple
> >has a blanket assignment for GDB already, but I think we still need to
> >do one for GCC.)
> >
> >At the same time, now that GCC is being used heavily by Apple's OS
> >developers, as well as by 3rd parties busily porting to Mac OS X,
> >a number of issues have cropped up.  While the team here is obligated
> >to resolve them one way or another, ideally we'd like to do things in
> >a way that will be of interest to the whole GCC community, and so I
> >plan to be sending a lot of mail to this list (get your killfiles set
> >up now :-) ), asking for ideas and suggestions.
> >
> >So far I'm aware of about four major areas that need attention:
> >
> >1. C++ support.  Apparently there have been a number of reports of
> >C++ constructs allowed by other Mac compilers, but that fail with GCC.
> >Some cases are just user error, others are compiler limitations.
> >I'll report on these as specific cases come up.
> >
> >2. Objective C.  ObjC has not seen a lot of evolution lately, but
> >it's still in use.
> >
> >3. PowerPC code quality.  Apple has more than a few bit-twiddling
> >graphics engineers who pore over inner loops and such.  They need
> >the compiler to generate faster code.  Exception handling and
> >AltiVec support are two specific areas; for instance, Apple is
> >using a big hairy patch from Motorola for AltiVec code gen, but
> >from what I've seen of the patch so far, it seems problematic
> >for mainstream GCC.
> >
> >4. Compiler turnaround.  Mac developers are used to the fast
> >compile times offered by Metrowerks, and are dismayed by GCC's
> >slowness.  Do we need precompiled headers?  Should file system
> >probes be cached?  There are a lot of theories going around, but
> >facts are in short supply.  But however it's accomplished, the
> >compiler needs to go faster.
> >
> >I'm sure more issues will arise in the future, but these are
> >the current biggies for which I'll be asking for guidance.
> >Thanks for your attention, and looking forward to working with
> >everybody on improving GCC!
> >
> >Stan Shebs
> >address@hidden
> >
> >
> >                  ==================================
> >   Swarm-Support is for discussion of the technical details of the day
> >   to day usage of Swarm.  For list administration needs (esp.
> >   [un]subscribing), please send a message to <address@hidden>
> >   with "help" in the body of the message.
> 
> 
> _____________________________________________
> 
>                Darren Schreiber
>                 Attorney at Law
>                Graduate Student
>            Political Science, UCLA
>               address@hidden
>         http://www.bol.ucla.edu/~dschreib
> 
>                   ==================================
>    Swarm-Support is for discussion of the technical details of the day
>    to day usage of Swarm.  For list administration needs (esp.
>    [un]subscribing), please send a message to <address@hidden>
>    with "help" in the body of the message.
> 


                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.