m68k MacOS target support?

m68k MacOS target support?

[Michael Sokolov]

Hi there,

As I'm doing some major work on the m68k target in the Cygnus toolchain and
going to maintain it (it's currently unmaintained), I wanted to survey the
state of target support for one rather major m68k system: MacOS. I don't see
any in the mainline public tree. In ftp.cygnus.com:/pub/mac I see an old (1996)
port of the toolchain to MPW. It mentions an m68k MacOS compiler, but doesn't
contain one. I have also heard from multiple sources that Stan Shebs of Apple
has developed and might still be maintaining an m68k MacOS compiler.

Stan, are you reading this? Would you please fill me in on the state of various
port(s) for the m68k MacOS target? Is there or has there ever been more than
one? Is yours related to the one in ftp.cygnus.com:/pub/mac or not? What is the
current status of the various port(s) (maintained, unmaintained, etc)? Where
can I find the sources? Are you or is anyone else planning on integrating any
m68k MacOS target support into the mainline Cygnus toolchain? TIA for filling
me in on this.

(And yes, I'm fully aware of m68k MacOS' peculiarities with respect to
executable code living in code resources instead of COFF/ELF executables, A5-
based data access, segmentation, etc. One reason I'm so interested in this is
that I'm integrating into the mainline Cygnus toolchain target support for
PalmOS, another m68k system with some very similar characteristics.)

--
Michael Sokolov		Harhan Engineering Laboratory
Public Service Agent	International Free Computing Task Force
			International Engineering and Science Task Force
			615 N GOOD LATIMER EXPY STE #4
			DALLAS TX 75204-5852 USA

Phone: +1-214-824-7693 (Harhan Eng Lab office)
E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP) (UUCP coming soon)

Re: m68k MacOS target support?

[Stan Shebs]

Michael Sokolov wrote:
> 
> As I'm doing some major work on the m68k target in the Cygnus toolchain and
> going to maintain it (it's currently unmaintained), I wanted to survey the
> state of target support for one rather major m68k system: MacOS. I don't see
> any in the mainline public tree. In ftp.cygnus.com:/pub/mac I see an old (1996)
> port of the toolchain to MPW. It mentions an m68k MacOS compiler, but doesn't
> contain one. I have also heard from multiple sources that Stan Shebs of Apple
> has developed and might still be maintaining an m68k MacOS compiler.

Yes; no. :-)

> Stan, are you reading this? Would you please fill me in on the state of various
> port(s) for the m68k MacOS target? Is there or has there ever been more than
> one? Is yours related to the one in ftp.cygnus.com:/pub/mac or not? What is the
> current status of the various port(s) (maintained, unmaintained, etc)? Where
> can I find the sources? Are you or is anyone else planning on integrating any
> m68k MacOS target support into the mainline Cygnus toolchain? TIA for filling
> me in on this.

Ah, brings back memories.  I'll answer publicly, just to put some of
the history on the record and maybe dispel a few myths.

I did three MacOS ports of GCC in all.  The first was in 1989, to
1.37, and was originally intended as a control case to compare with a
port of GCC to an experimental target (that project died quietly
later).  When, as part of benchmarking, we found that GCC was
producing code 10-20% better than Apple's own compiler, mgmt got real
interested and had me proceed to turn it into a complete port,
bootstrapping and all.  This ran under MPW, which is Apple's vaguely
Unix-like development environment for the Mac, and its output went
into the MPW assembler.

Being new to GNU, and not really thinking ahead, I hacked the wazoo
out of the 1.37 sources.  The assembler provided handling for the Mac
ABI, such as A5-relative references, essentially filling in the "(a5)"
for what looked like global variables and functions, and since GCC's
PIC was in a primitive state, I relied on the assembler.  The
assembler, however, also had a notion of modules that tied into jump
tables and the Mac's code segment architecture (remember that the Mac
OS had been mostly written in m68k assembly only a few years earlier),
and it actually required imports and exports of each symbol from each
function and initialized block of data!  So I had to make some really
horrendous hacks to final.c and varasm.c in order to get all this to
work.  I was pretty much on my own too, because at the time the FSF
was participating in the LPF boycott against Apple (ironic that Apple
now has a corporate commitment to GCC as its main compiler for OS X...).
I did talk to John Gilmore at one point about having Cygnus do some
of the work - interestingly, it would have been just a few months
after Cygnus was founded - but I didn't have any money to pay for it,
so that didn't go anywhere.

Eventually this port made it out to ftp sites (after some internal
debate settled by executive decision), and it enjoyed a small amount
of popularity both at Apple and externally.

A couple years later, Jeff Holcomb (who's now at RH), Brent Pease, and
I worked on moving all the patches to 2.3.3.  As you might imagine,
the many gratuitous changes made this was a nasty job, and the result
never seemed quite as solid as the original port.  During 1993, it was
actually in the running to be the compiler for building what became
MacOS 7.5, but that idea died due to internecine politics and I went
to Cygnus to continue with my GNU enthusiasm fulltime.  1993 was also
when I presented the "talking compiler" at MacHack, basically just MPW
GCC modified to play pre-recorded sounds by looking up identifiers
and/or error messages in a user-specified table.  It was great fun to
have it say "Oooh pizza" for any function with "pizza" in its name, or
to sing "You are an idiot" for syntax errors...

Anyway, among my other activities at Cygnus (such as GDB maintenance),
in late 1993 I started a new port that was to be "done right".  This
was initially for MPW-hosted cross-compilation - at that time Cygnus
would do almost anything for money :-) - and later, ca 1995, for
PowerMac native (this was the contract that also gave us the
(in?)famous Haifa scheduler).  This port strategy started out with
hacked clones of the Unix makefiles, but evolved into a complicated
script-and-sed-based mechanism to edit Unix makefiles; thus the mpw-*
files you see scattered around GNU sources today.  These ports
concentrated almost all of the MPW and Mac knowledge into separate
files, partly to simplify maintenance and partly to accommodate the
FSF boycott, which didn't end until 1995 or 1996.  The native Powermac
port eventually was finished in late 1996, and put up for ftp - just a
few weeks before Apple announced it was dropping MPW!  :-(  (They
revived it later though.)  I never did an m68k version of this port,
although I did sketch out a not-using-MPW plan at one point, nor did
the GCC changes get merged into egcs, because I had lost interest by
then and nobody else took it up - between the overwhelming popularity
of Metrowerks and Apple's declining market share, MPW GCC users became
almost nonexistent.

All three of these versions used to be at Cygnus' ftp site, presumably
they're still there, and you can get the talking compiler on MacHack's
CD (www.machack.com).  Alas, none of them is of much use for porting
current GCC to m68k MacOS, since they assume MPW, and now-unsupported
versions at that.  Most of the changes are highly MPW-specific anyway,
with the exception of Pascal string (\p) and four-char-constants ('oapp')
support in the frontend.

So given that m68k Macs are slowly fading into the sunset, and that
the PalmOS GCC port has little in common with the old Mac ports, I'd say
it's not worth spending much time worrying about m68k Mac support in
current GCC.

Stan

Re: m68k MacOS target support?

[Michael Meissner]

On Mon, Sep 11, 2000 at 08:47:09PM -0700, Stan Shebs wrote:
> So given that m68k Macs are slowly fading into the sunset, and that
> the PalmOS GCC port has little in common with the old Mac ports, I'd say
> it's not worth spending much time worrying about m68k Mac support in
> current GCC.

You never know.  There is after all, somebody porting GCC to the Dec-10
architecture, something like 10-15 years after DEC stopped making them (I don't
recall when the plug was pulled).  I seem to recall discussion about the VAX
and GCC working on pristine BSD 4.3 in the last 2 months.  Unfortunately, the
AS400 effort seems to be running into a wall.

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482

Re: m68k MacOS target support?

[Mark Mitchell]

>>>>> "Michael" == Michael Meissner <meissner@cygnus.com> writes:

    Michael> You never know.  There is after all, somebody porting GCC
    Michael> to the Dec-10 architecture, something like 10-15 years
    Michael> after DEC stopped making them (I don't recall when the
    Michael> plug was pulled).  I seem to recall discussion about the
    Michael> VAX and GCC working on pristine BSD 4.3 in the last 2
    Michael> months.  Unfortunately, the AS400 effort seems to be
    Michael> running into a wall.

For the record, I don't think that we (as mainline GCC developers)
should worry about these kinds of platforms, and I think Stan's
comments show a very mature mode of thinking towards 68K Macs.  There
is a large burden in dragging around old ports, trying to make sure
Makefiles work there, and so forth.  If someone else wants to keep GCC
working on a Dec-10, or a PDP-11, or an SV3 system, or whatever that's
just great -- but I don't think we should worry about those systems
when maintaining GCC.

My two cents,

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

Re: m68k MacOS target support?

[lars brinkhoff]

Mark Mitchell <mark@codesourcery.com> writes:
> >>>>> "Michael" == Michael Meissner <meissner@cygnus.com> writes:
>     Michael> You never know.  There is after all, somebody porting GCC
>     Michael> to the Dec-10 architecture, something like 10-15 years
>     Michael> after DEC stopped making them (I don't recall when the
>     Michael> plug was pulled).  I seem to recall discussion about the
>     Michael> VAX and GCC working on pristine BSD 4.3 in the last 2
>     Michael> months.  Unfortunately, the AS400 effort seems to be
>     Michael> running into a wall.
> 
> For the record, I don't think that we (as mainline GCC developers)
> should worry about these kinds of platforms, and I think Stan's
> comments show a very mature mode of thinking towards 68K Macs.  There
> is a large burden in dragging around old ports, trying to make sure
> Makefiles work there, and so forth.  If someone else wants to keep GCC
> working on a Dec-10, or a PDP-11, or an SV3 system, or whatever that's
> just great -- but I don't think we should worry about those systems
> when maintaining GCC.

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

It's my intention that the changes should be as non-intrusive as
possible and make GCC easier to port to other architectures with
unsusual pointer formats.  My employer may be willing to sponsor this
if it's an improvement of GCC.  But if the GCC maintainers are not
interested in this, I'd rather just make the changes necessary for
PDP-10 without considering other architectures.

The same goes for binutils and GDB, by the way.

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

Re: 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

Re: m68k MacOS target support?

[lars brinkhoff]

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.

Re: m68k MacOS target support?

[Mark Mitchell]

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

    >> 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> Is there something I can do to get the attention of the SC?
    lars> Other than posting these letters, of course.

:-)  I suspect that most of the SC reads this list.  From the web
site:

  At the moment the steering committee has 14 members. The best place
  to reach them is the gcc mailinglist.

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

Re: m68k MacOS target support?

[Joe Buck]

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

Mark writes:
> 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.

The approach gcc has taken to this problem in the past (whether we want
to admit it or not) is to just let the uninteresting ports slowly degrade
due to bit rot.  This has the disadvantage that it can make gcc look bad,
but if a committed user comes along at some point there is hope that the
broken port can be fixed.  Given this it is probably better to leave the
ports in, with warnings about which ones have been tested and which ones
are likely to have problems.

A partially broken port doesn't have a negative impact on users of other
ports.  Features accessible from the front end, on the other hand, have
a bigger impact, as they can slow down all future compiler development.
Everyone working on optimizations or trying to track moving language
standards has to waste time figuring out how to do the special case
code for handling the case where the "feature" is used.

Re: m68k MacOS target support?

[Bernd Schmidt]

On Tue, 12 Sep 2000, Joe Buck wrote:
> 
> A partially broken port doesn't have a negative impact on users of other
> ports.

However, it does have an impact on developers.  For example, I want to
eliminate STRICT_LOW_PART from the compiler.  To do this, I'll need to
fix all existing ports.  Likewise for any other global change that affects
every port.  It would be nice if we could come up with a list of ports
which are expected to work and must be maintained, and which ones can
be left to bitrot.


Bernd

Re: m68k MacOS target support?

[Mark Mitchell]

>>>>> "Bernd" == Bernd Schmidt <bernds@redhat.co.uk> writes:

    Bernd> On Tue, 12 Sep 2000, Joe Buck wrote:
    >>  A partially broken port doesn't have a negative impact on
    >> users of other ports.

    Bernd> However, it does have an impact on developers.  For
    Bernd> example, I want to eliminate STRICT_LOW_PART from the
    Bernd> compiler.  To do this, I'll need to fix all existing ports.
    Bernd> Likewise for any other global change that affects every
    Bernd> port. 

Yes -- and that was my point.  I think everybody's right: Joe is
correct that language extensions have more pervasive impact that old
ports, and Bernd is right that even with back-ends there is a cost.
I, too, have had to make more than one pass over every single machine
description, and it is a pain -- especially since I know that some of
the back-ends do not really work.

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

Re: m68k MacOS target support?

[Stan Shebs]

Joe Buck wrote:
> 
> >     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.
> 
> Mark writes:
> > 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.
> 
> The approach gcc has taken to this problem in the past (whether we want
> to admit it or not) is to just let the uninteresting ports slowly degrade
> due to bit rot.  This has the disadvantage that it can make gcc look bad,
> but if a committed user comes along at some point there is hope that the
> broken port can be fixed.  Given this it is probably better to leave the
> ports in, with warnings about which ones have been tested and which ones
> are likely to have problems.

For GDB we had the problem that many of GDB's porting constructs had
been deprecated or retired, the only references left were in obsolete
ports, and new developers were being misled by their existence - in a
couple cases spending extra work trying to update ports that had no
chance of working.  Worse, with GDB it's possible to have native
ports whose code literally cannot be compiled anywhere else.  So I
discussed this with RMS and came up with a obsoletion scheme, where
old code is prominently marked as obsolete (by commenting out every
line), announced as such in a release, and if nobody has come forward
to revive it by the time of the next release, it gets completely removed.

So far only a handful of targets have been proved obsolete and gotten
this treatment - Gould and Pyramid (pre-Mips) are the most notable.

Stan

Re: m68k MacOS target support?

[Richard Henderson]

On Tue, Sep 12, 2000 at 01:59:02PM -0700, Stan Shebs wrote:
> So I discussed this with RMS and came up with a obsoletion scheme, where
> old code is prominently marked as obsolete (by commenting out every
> line), announced as such in a release, and if nobody has come forward
> to revive it by the time of the next release, it gets completely removed.

Personally, I think we ought to immediately nuke all the ports that
were never updated from gcc 1.x, and that have been commented out in
the configure file since gcc 2.0.

Namely: fx80, ns32k-ns-genix, pyramid, tahoe, gmicro.

There are plenty of others that are also obsolete, but those named
have had many multiples of years completely and obviously not compiled.


r~

Re: m68k MacOS target support?

[Stan Shebs]

Richard Henderson wrote:
> 
> On Tue, Sep 12, 2000 at 01:59:02PM -0700, Stan Shebs wrote:
> > So I discussed this with RMS and came up with a obsoletion scheme, where
> > old code is prominently marked as obsolete (by commenting out every
> > line), announced as such in a release, and if nobody has come forward
> > to revive it by the time of the next release, it gets completely removed.
> 
> Personally, I think we ought to immediately nuke all the ports that
> were never updated from gcc 1.x, and that have been commented out in
> the configure file since gcc 2.0.
> 
> Namely: fx80, ns32k-ns-genix, pyramid, tahoe, gmicro.

Of these, I only researched the Pyramid thoroughly enough to determine
that the platform was really and truly dead.  I've been somewhat
conservative, because sometimes we actually hear from someone actively
using a supposedly-vanished type of system.

> There are plenty of others that are also obsolete, but those named
> have had many multiples of years completely and obviously not compiled.

Yeah, they're pretty much just taking up disk space then.

Stan

"Dead" Ports (was: m68k MacOS target support?)

[Gerald Pfeifer]

On Tue, 12 Sep 2000, Richard Henderson wrote:
> Personally, I think we ought to immediately nuke all the ports that
> were never updated from gcc 1.x, and that have been commented out in
> the configure file since gcc 2.0.
> 
> Namely: fx80, ns32k-ns-genix, pyramid, tahoe, gmicro.
> 
> There are plenty of others that are also obsolete, but those named
> have had many multiples of years completely and obviously not compiled.

I second this.

How about announcing this plan to gcc-announce and, unless there are
significant and founded objections, nuke the part after, say, 3 weeks?

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: "Dead" Ports (was: m68k MacOS target support?)

[Jeffrey A Law]

  In message <Pine.BSF.4.21.0009130740070.67582-100000@taygeta.dbai.tuwien.ac.a
t>you write:
  > On Tue, 12 Sep 2000, Richard Henderson wrote:
  > > Personally, I think we ought to immediately nuke all the ports that
  > > were never updated from gcc 1.x, and that have been commented out in
  > > the configure file since gcc 2.0.
  > > 
  > > Namely: fx80, ns32k-ns-genix, pyramid, tahoe, gmicro.
  > > 
  > > There are plenty of others that are also obsolete, but those named
  > > have had many multiples of years completely and obviously not compiled.
  > 
  > I second this.
  > 
  > How about announcing this plan to gcc-announce and, unless there are
  > significant and founded objections, nuke the part after, say, 3 weeks?
Let's add the spur chip to the list above and make the announcement/request.

Other opinions?

jeff

Re: "Dead" Ports (was: m68k MacOS target support?)

[Bernd Schmidt]

On Wed, 13 Sep 2000, Jeffrey A Law wrote:
> 
> Other opinions?

I'm not necessarily requesting we add these to the "nuke immediately" list,
but does anyone know whether romp/a29k/we32k/clipper/elxsi are likely to be
in use?  It also seems like these haven't been changed in any serious way
for a long time either.


Bernd

Re: "Dead" Ports (was: m68k MacOS target support?)

[Stan Shebs]

Bernd Schmidt wrote:
> 
> On Wed, 13 Sep 2000, Jeffrey A Law wrote:
> >
> > Other opinions?
> 
> I'm not necessarily requesting we add these to the "nuke immediately" list,
> but does anyone know whether romp/a29k/we32k/clipper/elxsi are likely to be
> in use?  It also seems like these haven't been changed in any serious way
> for a long time either.

Kenner's examples show why it's important to do research on a target
and to move slowly on evaporating configurations.  If a GCC config ever
worked at one time, it's quite likely it still has users, unless
all copies of the hardware have disappeared.  I researched a couple
obscure configs for GDB (such as CX/UX), thinking they were dead, and
turned up whole web sites, including release notes for modified versions
of GNU tools, etc.  By contrast, I was able to prove the Gould's demise
by finding a site that was an epitaph for the last one - and the site
described how that machine had been kept alive for several years by
cannibalizing the second-to-last Gould.

Stan

Re: "Dead" Ports (was: m68k MacOS target support?)

[Bruce Korb]

Jeffrey A Law wrote:
> Other opinions?

How about other cruft?  The include fixes are also
monotonically increasing in size, too.  Surely
*some* of the fixes are obsolete.  :-)
It would be trivial to hack up a version that would
report the fixes that made a difference somewhere.
What would be hard is deciding how to ensure the
hacked version was exercised on the relevant, active
platforms.  Probably not today....

 - Bruce

Re: m68k MacOS target support?

[Joseph S. Myers]

On Tue, 12 Sep 2000, Richard Henderson wrote:

> Personally, I think we ought to immediately nuke all the ports that
> were never updated from gcc 1.x, and that have been commented out in
> the configure file since gcc 2.0.
> 
> Namely: fx80, ns32k-ns-genix, pyramid, tahoe, gmicro.

The spur port seems to be in the same state (but missing altogether from
configure).  As far as I can tell the last change to that port that wasn't
part of some general change applied across multiple ports to which it was
applicable was in 1989:

Tue Apr  4 12:22:06 1989  Richard Stallman  (rms at sugar-bombs.ai.mit.edu)

        * spur.md (movqi, loadhi, extend*, zero_extendhisi):
        Make subregs with C code, not RTL patterns, so we can
        avoid generating subreg of subreg.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: m68k MacOS target support?

[Toon Moene]

Mark Mitchell wrote:

> if there are other architectures that have similarly unusual pointer
> formats.  (I don't know whether there are such beasts or not,
> honestly).

It looks suspiciously like the Cray (Parallel Vector, i.e. Cray Classic)
character pointer format.

The word (64 bits) address is in the lower 32 bits of the pointer and
the bit offset within the word is in the upper 6 bits of the pointer.

[ With this information at hand, estimate the number of instructions
necessary to encode the loop body in:

f(char *s, char *t)
{
	while (*s++ = *t++)
		;
}

given only word sized loads, stores and shifts. Use of a slide rule is
permitted. ]

HTH,

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

Re: m68k MacOS target support?

[Jeffrey A Law]

  In message < 857l8ip00i.fsf@junk.nocrew.org >you write:
  > That's very interesting, because I'd like to know if the GCC
  > maintainers are interested in the changes I would have to make to GCC
  > for it to support the different PDP-10 pointer formats.
We're primarily interested in those changes which apply to other more
modern architectures.  For example, changes which improve GCC's handling
of multiple pointer formats are of interest to us as there are modern
targets which would benefit from that infrastructure.

jeff

PDP10 support (was Re: m68k MacOS target support?)

[Joe Buck]

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

If it only benefits the PDP-10, it's not that interesting.  However,
there's a large group of word-oriented architectures out there (DSPs).
Since these do little if any character processing, the 32-bit byte
approach isn't too bad, but some DSP users might be interested in
being able to use 8 and 16 bit quantities (half and quarter words).
For that reason, your work may be interesting.

I'm also a believer in strong typing and while I can't currently
demonstrate it, I have a vague feeling that the quality of the back end
may be improved and possibly more opportunities for improvement exposed if
careful attention is paid to what is an address and what is an integer, as
this work will require.

> It's my intention that the changes should be as non-intrusive as
> possible and make GCC easier to port to other architectures with
> unsusual pointer formats.  My employer may be willing to sponsor this
> if it's an improvement of GCC.  But if the GCC maintainers are not
> interested in this, I'd rather just make the changes necessary for
> PDP-10 without considering other architectures.

We'd have to see if DSP folks are interested.

Re: PDP10 support

[Gerald Pfeifer]

[ removed binutils from distribution ]

On 12 Sep 2000, lars brinkhoff wrote:
> Is there something I can do to get the attention of the SC?  Other
> than posting these letters, of course.

As you noticed, most of us are reading this list on a daily base ;-),
so this is the preferred medium for general discussion as it also adds
the vast knowledge of lots of other contributors and users.

Should you (or someone else) want to raise a private issue with the SC
or ask the SC for a decision if discussions on the lists have not led
to a clear conclusion, you can always contact a SC member of your
choice who will then forward that request.


However, note that the SC should not (and will not) interfere with day
to day work -- for that we have lots of highly qualified maintainers
and critical users. :-)


On Tue, 12 Sep 2000, Joe Buck wrote:
> If it only benefits the PDP-10, it's not that interesting.  However,
> there's a large group of word-oriented architectures out there (DSPs).
> Since these do little if any character processing, the 32-bit byte
> approach isn't too bad, but some DSP users might be interested in
> being able to use 8 and 16 bit quantities (half and quarter words).
> For that reason, your work may be interesting.

Seconded.

FWIW, that makes three global write commiters/four SC members that view
your proposal as useful in principle, if I've counted correctly. ;-)

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: PDP10 support

[lars brinkhoff]

Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> writes:
> FWIW, that makes three global write commiters/four SC members that view
> your proposal as useful in principle, if I've counted correctly. ;-)

These are the positive comments I've found, with Mark Mitchell being
the most sceptical, and almost everyone pointing out that PDP-10
support is quite useless in itself.

It would also be interesting to hear from the DSP folks.

Michael Meissner <meissner@cygnus.com> writes:
> On Wed, Sep 06, 2000 at 11:18:00AM +0200, lars brinkhoff wrote:
> > Isn't it about time gcc was enhanced to support "weird" pointers?
> Sure I do.

Mark Mitchell:
> 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.

kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:
> [...] adding support for this, if done cleanly, is likely to
> be a worthwhile addition to GCC since it may produce a level of
> abstraction in the handling of pointers that might make *other*
> things easlier down the road.

Jeffrey A Law <law@cygnus.com> writes:
> [...] changes which improve GCC's handling of multiple pointer
> formats are of interest to us as there are modern targets which
> would benefit from that infrastructure.

Joe Buck <jbuck@racerx.synopsys.com> writes:
> [...] there's a large group of word-oriented architectures out there
> (DSPs).  [...]  For that reason, your work may be interesting.
> [...] I have a vague feeling that the quality of the back end may be
> improved and possibly more opportunities for improvement exposed if
> careful attention is paid to what is an address and what is an
> integer, as this work will require.

Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> writes:
> On Tue, 12 Sep 2000, Joe Buck wrote:
> > [...] For that reason, your work may be interesting.
> Seconded.

Re: PDP10 support

[Nick Ing-Simmons]

Lars Brinkhoff <lars@nocrew.org> writes:
>
>It would also be interesting to hear from the DSP folks.

Okay here is a _personal_ view as someone that has tried to ports 
to various TI DSPs:

Weird addresses would have been useful for one of the ports
(actually thing was more of a micro-controller than a DSP).

Older C2X DSPs, and modern C5X which are backward compatible are 
16-bit words only. As such addressing bytes was just not possible - 
packing bytes means reading 16 bits and/shift/or and write 16 bits.

C3X/C4X are basically 32-bit with "some" support for messing with bytes
they also have non-IEEE 40-bit float.

C6X is byte addressed. 
C8X is byte addressed.

Most of the problems with DSPs were not the format of the addressing,
but:

 -  opcode squeezing which meant that which set of index registers
    you could use depended on choice of base registers etc.
    Reload has no support for such stuff, so you end up using a 
    subset of registers.
 -  Register allocation - GCC likes to keep a pseudo in one hard register,
    but if you multiply it and then use as an index it has to move.
    So you need to split into multiple pseudos then stop GCC collapsing
    them back into one.
 -  the lack of hardware interlocks (exposed pipeline) meaning need 
    to insert NOPs for loads and other multi-cycle ops - as well as branches. 
 -  VLIW scheduling. (Super scalar without harware interlocks.)
    Also register allocation which depends on which "unit" operation
    is scheduled for.  
 -  Fussy details like HI*HI => SI multiply is highly optimal 
    so shift schemes need to be disabled - except when used 
    for address generation.
 -  Figuring out what RTL "combine" would come up with for 
    expressions that mapped on to DSPish things like MPY+ADD+SHIFT 
    so that insn patterns that matched could be written



-- 
Nick Ing-Simmons <nik@tiuk.ti.com>
Via, but not speaking for: Texas Instruments Ltd.

Re: m68k MacOS target support?

[lars brinkhoff]

[resend, sorry]

Mark Mitchell <mark@codesourcery.com> writes:
> >>>>> "Michael" == Michael Meissner <meissner@cygnus.com> writes:
>     Michael> You never know.  There is after all, somebody porting GCC
>     Michael> to the Dec-10 architecture, something like 10-15 years
>     Michael> after DEC stopped making them (I don't recall when the
>     Michael> plug was pulled).  I seem to recall discussion about the
>     Michael> VAX and GCC working on pristine BSD 4.3 in the last 2
>     Michael> months.  Unfortunately, the AS400 effort seems to be
>     Michael> running into a wall.
> 
> For the record, I don't think that we (as mainline GCC developers)
> should worry about these kinds of platforms, and I think Stan's
> comments show a very mature mode of thinking towards 68K Macs.  There
> is a large burden in dragging around old ports, trying to make sure
> Makefiles work there, and so forth.  If someone else wants to keep GCC
> working on a Dec-10, or a PDP-11, or an SV3 system, or whatever that's
> just great -- but I don't think we should worry about those systems
> when maintaining GCC.

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

It's my intention that the changes should be as non-intrusive as
possible and make GCC easier to port to other architectures with
unsusual pointer formats.  My employer may be willing to sponsor this
if it's an improvement of GCC.  But if the GCC maintainers are not
interested in this, I'd rather just make the changes necessary for
PDP-10 without considering other architectures.

The same goes for binutils and GDB, by the way.

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

Re: m68k MacOS target support?

[David Huggins-Daines]

Stan Shebs <shebs@apple.com> writes:

> All three of these versions used to be at Cygnus' ftp site, presumably
> they're still there, and you can get the talking compiler on MacHack's
> CD (www.machack.com).  Alas, none of them is of much use for porting
> current GCC to m68k MacOS, since they assume MPW, and now-unsupported
> versions at that.  Most of the changes are highly MPW-specific anyway,
> with the exception of Pascal string (\p) and four-char-constants ('oapp')
> support in the frontend.

Hey, MPW runs great on my Quadras!

Seriously, an m68k port that targeted CFM68k binaries only would
probably be reasonable to support *iff* there were also a maintained
port to MacOS/powerpc.

Seeing as MacOS itself is going to start fading into the sunset
shortly, I guess this isn't likely.

> So given that m68k Macs are slowly fading into the sunset, and that
> the PalmOS GCC port has little in common with the old Mac ports, I'd say
> it's not worth spending much time worrying about m68k Mac support in
> current GCC.

Probably not.  I do find it sad that we require a highly non-free
compiler to build the bootloaders and other MacOS support utilities
for installing and running free operating systems (NetBSD, GNU/Linux,
mkLinux) on older Macintoshes (both m68k and powerpc based).  And the
gratis MPW compilers really suck compared to GCC (no inline assembly,
etc, so on).

Oh well, so it goes.

-- 
dhd@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Support for the revolution.