Re: m68k MacOS target support?

Re: m68k MacOS target support?

[Michael Sokolov]

Stan Shebs <shebs@apple.com> wrote:

> I did three MacOS ports of GCC in all.

OK, so if I understood you correctly, you've made two m68k MacOS-targeting
compilers, one based on gcc-1.37 and the other on gcc-2.3.3, and both were only
hosted on MPW (no cross-compilation to m68k MacOS from UNIX) using the MPW
assembler and linker, right? You've never ported your own m68k MacOS assembler
or linker, right?

But what did you use for the C library? And what header files? Apple's own? Did
you make gcc grok the awful syntax they use (pascal qualifier on declarations,
the "= {word, word, ...}" thingy for inlining, etc), or did you patch them into
a saner syntax?

> All three of these versions used to be at Cygnus' ftp site, presumably
> they're still there [...]

OK, I've found your two m68k ports in ftp.cygnus.com:/pub/mac/m68k, but they
are Mac self-extracting archives as far as I could tell. Could you please
provide the sources in .tar.gz format? (After all, the GPL does require the
source to be available in a machine-readable form. For a UNIX program I'd say
this implies a UNIX-readable format. gcc is originally a UNIX program, and
while a fork can be made for a different system, I think the original UNIX-
based developers have a natural right to see the source in a UNIX-readable form
for possible integration into the mainline.)

I don't have any Macs myself and I'm not a Mac user or programmer. In fact, I
myself don't even have any personal instrest in Macs. I do, however, have a
very strong interest in the mainline toolchain m68k port, and I want it to be
able to target as many m68k systems as possible, especially when I can do it
with very little effort (I mean extra effort beyond what I would need for other
projects anyway) and when it's already done by forked versions, even if the
target system is not a personal interest of my own.

> [...] the PalmOS GCC port has little in common with the old Mac ports [...]

A little clarification is in order. If by "the PalmOS GCC port" you mean the
kludge that exists right now, I have nothing to do with that. I have a
completely different standpoint. I am concerned with the mainline toolchain
m68k port overall and things that are synergistically integrated into it. I
have no interest in kludges like the PalmOS GCC in PRC-Tools. I want to
maintain the m68k port in the mainline toolchain (and I mean really maintain
the m68k port, in its original focus on m68k UNIXes and pure embedded systems,
rather than make it MacOS- or PalmOS-centric), and integrate things like MacOS
and PalmOS with as little impact as possible.

> [...] it's not worth spending much time worrying about m68k Mac support in
> current GCC.

I value your opinion, but this decision will be ultimately up to me when I
maintain the m68k port. See above for my stand on this.

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

[Richard Henderson]

On Tue, Sep 12, 2000 at 07:57:48PM -0500, Michael Sokolov wrote:
> OK, I've found your two m68k ports in ftp.cygnus.com:/pub/mac/m68k, but they
> are Mac self-extracting archives as far as I could tell. Could you please
> provide the sources in .tar.gz format?

The "macunpack" program from the "macutils" package distributed by
Red Hat, Debian, and others should unpack things for you.


r~

Re: m68k MacOS target support?

[Geoff Keating]

> Date: Tue, 12 Sep 00 19:54:52 CDT
> From: msokolov@ivan.Harhan.ORG (Michael Sokolov)

> > All three of these versions used to be at Cygnus' ftp site, presumably
> > they're still there [...]
> 
> OK, I've found your two m68k ports in ftp.cygnus.com:/pub/mac/m68k, but they
> are Mac self-extracting archives as far as I could tell. Could you please
> provide the sources in .tar.gz format? (After all, the GPL does require the
> source to be available in a machine-readable form. For a UNIX program I'd say
> this implies a UNIX-readable format. gcc is originally a UNIX program, and
> while a fork can be made for a different system, I think the original UNIX-
> based developers have a natural right to see the source in a UNIX-readable form
> for possible integration into the mainline.)

The GPL only requires source be available when you ship binaries, and
contains this clause:

 However, as a special exception, the source code distributed need not
 include anything that is normally distributed (in either source or
 binary form) with the major components (compiler, kernel, and so on)
 of the operating system on which the executable runs, unless that
 component itself accompanies the executable.

One effect of this clause is that Mac self-extracting archives of
source are perfectly acceptable if distributed with Mac binaries.

Still, I'll look into fixing it next time my mac is sufficiently close
network-wise to the FTP archive.

-- 
- Geoffrey Keating <geoffk@cygnus.com>

Re: m68k MacOS target support?

[Stan Shebs]

Michael Sokolov wrote:
> 
> Stan Shebs <shebs@apple.com> wrote:
> 
> > I did three MacOS ports of GCC in all.
> 
> OK, so if I understood you correctly, you've made two m68k MacOS-targeting
> compilers, one based on gcc-1.37 and the other on gcc-2.3.3, and both were only
> hosted on MPW (no cross-compilation to m68k MacOS from UNIX) using the MPW
> assembler and linker, right? You've never ported your own m68k MacOS assembler
> or linker, right?

That's right, I used Apple's compiler for stage 1 bootstrap.

> But what did you use for the C library? And what header files? Apple's own? Did
> you make gcc grok the awful syntax they use (pascal qualifier on declarations,
> the "= {word, word, ...}" thingy for inlining, etc), or did you patch them into
> a saner syntax?

The compiler was a total MPW compiler, used Apple headers and libraries,
and implemented every single one of those awful extensions.  Did you know
that you could declare a global variable "pascal", with the sole effect of
translating the variable's name into all uppercase?  That was easy, compared
to the per-function decision about the stack push order necessary to implement
pascal functions!  To make it fit into the MPW environment perfectly, I wrote
a script that emulated the argument handling of the MPW C compiler.

> > All three of these versions used to be at Cygnus' ftp site, presumably
> > they're still there [...]
> 
> OK, I've found your two m68k ports in ftp.cygnus.com:/pub/mac/m68k, but they
> are Mac self-extracting archives as far as I could tell. Could you please
> provide the sources in .tar.gz format? (After all, the GPL does require the
> source to be available in a machine-readable form. For a UNIX program I'd say
> this implies a UNIX-readable format. gcc is originally a UNIX program, and
> while a fork can be made for a different system, I think the original UNIX-
> based developers have a natural right to see the source in a UNIX-readable form
> for possible integration into the mainline.)

There are plenty of Mac unpacking programs available in source form for
Unix, but if I get a moment, I'll see if I can do a repack (seeing as how
I'm typing this on a beta OS X machine that has both Mac and Unix tools! :-) ).

> I don't have any Macs myself and I'm not a Mac user or programmer. In fact, I
> myself don't even have any personal instrest in Macs. I do, however, have a
> very strong interest in the mainline toolchain m68k port, and I want it to be
> able to target as many m68k systems as possible, especially when I can do it
> with very little effort (I mean extra effort beyond what I would need for other
> projects anyway) and when it's already done by forked versions, even if the
> target system is not a personal interest of my own.

That's cool with me if you really want to do the work, and I'll
happily pass along everything I know.  There's hack value in having GCC
work for retro targets, a la arcade emulators, and we mustn't always
be so serious that we forget to be, paraphrasing RMS, "happy hackers".

Stan

Re: m68k MacOS target support?

[Michael Sokolov]

Joe Buck <jbuck@racerx.synopsys.com> wrote:

> The MAINTAINERS file in the GCC distribution lists who the maintainers
> are for various aspects of GCC, and your name does not appear.

I've said clearly I think that I'm *running* for the m68k maintainer. I say "as
the m68k maintainer I will..." the same way Bush and Gore say "as the President
of the U.S. I will..." :-)

> Jeff
> Law is listed as maintainer for the m68k port [...]

With a question mark. When I asked him what he meant by that, he said that he
would be willing to pass the maintainership to someone who would actually be
working on that port.

Since the beginning of year 2000 I have been the only one making any
enhancements to the m68k port in the Cygnus tree. So far all my enhancements
have been in Binutils modules, but I'll get into the gcc module soon too.

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

[Joe Buck]

Michael Sokolov writes:

> I can't say anything for sure until I get the sources for Stan Shebs'
> two ports and get answers to the questions about the C library and the
> headers, but it looks like as the m68k port maintainer I'll be able to
> create a UNIX-hosted MacOS-targeting port with very little additional
> work ...

I am confused by this message.

The MAINTAINERS file in the GCC distribution lists who the maintainers
are for various aspects of GCC, and your name does not appear.  Jeff
Law is listed as maintainer for the m68k port, and if he has resigned
in favor of you, I missed the announcement.

What, exactly, are you saying here?  Are you volunteering for something?

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?

[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]

Michael Sokolov wrote:
> 
> I can't say anything for sure until I get the sources for Stan Shebs' two ports
> and get answers to the questions about the C library and the headers, but it
> looks like as the m68k port maintainer I'll be able to create a UNIX-hosted
> MacOS-targeting port with very little additional work beyond what I would have
> to do anyway for other projects that interest me, and thus it would be
> imprudent for me as the m68k port maintainer not to do so. This port would be
> very good from the GNU viewpoint (full proper current GCC and Binutils), but
> would do very little from the Mac viewpoint other than letting you call MacOS
> APIs yourself with no involvement from the compiler. I would use Cygnus Newlib,
> and all of its free-standing embedded functionality would be fully working,
> which is great, but not being a Mac programmer and having no interest in the
> actual Mac business, I'm the wrong guy to ask for things like implementing
> UNIX-like open, read, write, console I/O, etc. on top of MacOS or for hosting
> on MacOS.

I'm afraid it won't be quite that simple.  You still have to conform to the
Mac ABI, which has a very particular format for function calls, variable
refs, and so forth.  Also, much of the functionality, such as opening a
window, is only available through traps which have to be passed arguments
in particular registers (which seemed like a great idea for personal computers
ca 1980 when all this was first designed...).  Since there's no console
equivalent on Macs, you can only do stdio by providing your own console
library, similar to MPW's SIOW or MW's Sioux libraries, which are proprietary,
there may be a free one out there by now.

> I wonder, how would this compare to what most proprietary Mac compilers offer
> in terms of the C library? (I'm not a Mac person and have never used any, so I
> don't know.) Do they offer free-standing functions that are better or worse
> than Cygnus Newlib? Do they offer open, read, write, etc. on top of the MacOS
> filesystem?

The MacOS these days includes literally about 9,000 functions in its API.
There are many flavors of open, read, write, etc from which to choose!
The API headers include all the weird extensions though, so even building
the little Unix boot programs sucks you into supporting the extensions.

If you want to discuss the details further, they get pretty arcane, so I'd
suggest continuing in private email.

Stan

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

Re: m68k MacOS target support?

[Michael Sokolov]

David Huggins-Daines <dhd@linuxcare.com> wrote:

> I do find it sad that we require a highly non-free
> compiler [...]
>
> [...] And the
> gratis MPW compilers really suck compared to GCC (no inline assembly,
> etc, so on).

I can't say anything for sure until I get the sources for Stan Shebs' two ports
and get answers to the questions about the C library and the headers, but it
looks like as the m68k port maintainer I'll be able to create a UNIX-hosted
MacOS-targeting port with very little additional work beyond what I would have
to do anyway for other projects that interest me, and thus it would be
imprudent for me as the m68k port maintainer not to do so. This port would be
very good from the GNU viewpoint (full proper current GCC and Binutils), but
would do very little from the Mac viewpoint other than letting you call MacOS
APIs yourself with no involvement from the compiler. I would use Cygnus Newlib,
and all of its free-standing embedded functionality would be fully working,
which is great, but not being a Mac programmer and having no interest in the
actual Mac business, I'm the wrong guy to ask for things like implementing
UNIX-like open, read, write, console I/O, etc. on top of MacOS or for hosting
on MacOS.

I wonder, how would this compare to what most proprietary Mac compilers offer
in terms of the C library? (I'm not a Mac person and have never used any, so I
don't know.) Do they offer free-standing functions that are better or worse
than Cygnus Newlib? Do they offer open, read, write, etc. on top of the MacOS
filesystem?

In any case this would be a start that other interested people can build upon,
while being self-contained and complete enough to be checked into the mainline
source (in the m68k-specific subdirectories, so that the m68k port maintainer's
authority is enough without bugging the higher-up maintainers).

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

[Michael Sokolov]

Richard Henderson <rth@cygnus.com> wrote:

> The "macunpack" program from the "macutils" package distributed by
> Red Hat, Debian, and others should unpack things for you.

The terms "package", "Red Hat", and "Debian" assume Linux I suppose. Is there
anything for UNIX, in source form?

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

[Michael Sokolov]

Michael Meissner <meissner@cygnus.com> wrote:

> I seem to recall discussion about the VAX
> and GCC working on pristine BSD 4.3 in the last 2 months.

That is correct, VAXen are my *only* computers, and they all run 4.3BSD. So far
the only version of GCC I've got working here is gcc-2.95.3 (the current state
of the -rgcc-2_95-branch in CVS) targeting m68k-coff. A native build didn't
work. It seems to me that there are some problems in the vax port and I would
be better off fixing them in 2.96 than in 2.95.3, so I didn't pursue that
further. I haven't got around to playing with the current 2.96 yet, neither
native nor cross.

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

[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]

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?

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

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

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

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

Re: m68k MacOS target support?

[Richard Kenner]

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

I suspect my feeling is the same as yours.  I don't *necessarily* see
these as useful for other architectures, but fell that 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.

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

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?

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

    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]

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

[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]

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

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

[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

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)