public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: lars brinkhoff <lars@nocrew.org>
To: Mark Mitchell <mark@codesourcery.com>
Cc: meissner@cygnus.com, binutils@sources.redhat.com, gcc@gcc.gnu.org
Subject: Re: m68k MacOS target support?
Date: Tue, 12 Sep 2000 03:26:00 -0000	[thread overview]
Message-ID: <85vgw1oqhv.fsf@junk.nocrew.org> (raw)
In-Reply-To: <20000912001505W.mitchell@codesourcery.com>

Mark Mitchell <mark@codesourcery.com> writes:
> >>>>> "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.

Is there something I can do to get the attention of the SC?  Other
than posting these letters, of course.

>     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).

There are, such as some DSPs, but they seem rare.  In general, I think
all word-addressed machines belong to this group, for example the ADI
210xx SHARC DSP.  The bit-addressed TMS34010 also doesn't fit within
GCC's model of pointers.  Both have much-hacked GCC ports that
hopefully would have benefitted from more generic pointer handling.

> 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 PDP-10 support in GCC would get to the same level as support for
the PDP-11, I'd be quite happy.  And the PDP-11 back end is not looked
after very much, it seems.

> 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?

I'd have to admit the PDP-10 userbase is most likely miniscule.

> What are the likely costs?  What are the long-term maintenance
> costs?

Some research would be needed to answer those questions.  And before
making that research, I'd like to know if there's at least some chance
of the changes being included in GCC.

> 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.

The question is whether to go ahead and make generic changes suitable
for inclusion in GCC, or to just make the minimal changes needed to
support the PDP-10 and maintain that as a separate patch.

  reply	other threads:[~2000-09-12  3:26 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-09-09 12:33 Michael Sokolov
2000-09-11 20:47 ` Stan Shebs
2000-09-11 20:56   ` Michael Meissner
2000-09-11 21:33     ` Mark Mitchell
2000-09-12  0:02       ` lars brinkhoff
2000-09-12  0:15         ` Mark Mitchell
2000-09-12  3:26           ` lars brinkhoff [this message]
2000-09-12  7:23             ` Mark Mitchell
2000-09-12 11:16           ` Joe Buck
2000-09-12 11:22             ` Bernd Schmidt
2000-09-12 20:11               ` Mark Mitchell
2000-09-12 13:59             ` Stan Shebs
2000-09-12 17:55               ` Richard Henderson
2000-09-12 19:12                 ` Stan Shebs
2000-09-12 22:44                 ` "Dead" Ports (was: m68k MacOS target support?) Gerald Pfeifer
2000-09-13  9:26                   ` Jeffrey A Law
2000-09-13  9:33                     ` Bernd Schmidt
2000-09-13 11:40                       ` Stan Shebs
2000-09-13  9:57                     ` Bruce Korb
2000-09-13  3:17                 ` m68k MacOS target support? Joseph S. Myers
2000-09-12 11:48           ` Toon Moene
2000-09-12  7:32         ` Jeffrey A Law
2000-09-12 11:11         ` PDP10 support (was Re: m68k MacOS target support?) Joe Buck
2000-09-13 14:51           ` PDP10 support Gerald Pfeifer
2000-09-14  0:15             ` lars brinkhoff
2000-09-14  7:47               ` Nick Ing-Simmons
2000-09-12  0:03       ` m68k MacOS target support? lars brinkhoff
2000-09-12  9:52   ` David Huggins-Daines
2000-09-12  8:11 Richard Kenner
2000-09-12 17:57 Michael Sokolov
2000-09-12 18:12 ` Richard Henderson
2000-09-12 18:19 ` Geoff Keating
2000-09-12 19:05 ` Stan Shebs
2000-09-12 18:08 Michael Sokolov
2000-09-12 18:18 Michael Sokolov
2000-09-12 18:43 Michael Sokolov
2000-09-12 19:44 ` Stan Shebs
2000-09-13  8:40 ` Joe Buck
2000-09-13  8:49 Michael Sokolov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=85vgw1oqhv.fsf@junk.nocrew.org \
    --to=lars@nocrew.org \
    --cc=binutils@sources.redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=mark@codesourcery.com \
    --cc=meissner@cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).