m68k MacOS target support?

[Mark Mitchell]

>>>>> "lars" == lars brinkhoff <lars@nocrew.org> writes:

    lars> That's very interesting, because I'd like to know if the GCC
    lars> maintainers are interested in the changes I would have to
    lars> make to GCC for it to support the different PDP-10 pointer
    lars> formats.

I can only speak for me; I only get one vote on the SC, just like
everybody else.  And I've been in the minority more than once before!
So, you shouldn't take what I say as necessarily reprentative.

    lars> It's my intention that the changes should be as
    lars> non-intrusive as possible and make GCC easier to port to
    lars> other architectures with unsusual pointer formats.  

That sounds helpful.  Those kind of generic changes are probably
welcome -- especially if they don't add much maintenance overhead, and
if there are other architectures that have similarly unusual pointer
formats.  (I don't know whether there are such beasts or not,
honestly).

    lars> interested in this, I'd rather just make the changes
    lars> necessary for PDP-10 without considering other
    lars> architectures.

Yes, I can see why you could use some guidance from us.  Probably we
should ask other members of the SC to chime in with their opinions.

    lars> I certainly don't expect the maintainers to actively
    lars> maintain the PDP-10 back end, or even care much if it
    lars> breaks.

:-)

What's funny about these kinds of things is how hard it is to undo
anything.  Whenever I propose getting rid of a "feature" in GCC, I
find that people now rely on that feature, or that at least many
people are afraid people rely on that feature.  Support for a platform
is a feature.  Once support is in GCC, it will probably be somewhat
difficult to remove that support.

If it were up to me, I would ask the same questions any commercial
enterprise would ask before including a port to the PDP-10, or any
other architecture.  How large is the likely userbase?  What are the
likely costs?  What are the long-term maintenance costs?  Does this
change fit with the overall product strategy?  I think that as
maintainers we have too great a tendency to say "well, that patch
doesn't break anything, let's put it in" without asking those other
questions, and especially without weighing the long-term costs as
heavily as we should.  That's just my take, of course; I'm sure others
would disagree.

The beauty of free software, of course, is that even if the answers to
those questions were negative, you would still have the freedom to do
what you want to do, and to make your work available to others.

That wasn't a very helpful answer, was it?  I hope that others will
comment on your questions.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com