Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 04 Jan 2003 21:23:06 -0800
From:      Terry Lambert <tlambert2@mindspring.com>
To:        Brett Glass <brett@lariat.org>
Cc:        "Gary W. Swearingen" <swear@attbi.com>, Mike Jeays <mj001@rogers.com>, chat@FreeBSD.ORG
Subject:   Re: On GCC
Message-ID:  <3E17C13A.B1B010CB@mindspring.com>
References:  <3E120659.3D60EB30@mindspring.com> <200212312041.gBVKfr183480@hokkshideh2.jetcafe.org> <3E120659.3D60EB30@mindspring.com> <4.3.2.7.2.20030104112015.026a5530@localhost> <4.3.2.7.2.20030104131212.03837e10@localhost> <rcptrcppvl.trc@localhost.localdomain> <4.3.2.7.2.20030104193746.0285b9c0@localhost>

next in thread | previous in thread | raw e-mail | index | archive | help
Brett Glass wrote:
> At 02:53 PM 1/4/2003, Terry Lambert wrote:
> >If you want to actually *do* something to defend your agenda,
> >rather than complaining, you should select one of the BSD's,
> >and then work on the BSD and the TenDRA compiler, until the
> >TenDRA compiler can compile it.
> 
> Why TenDRA in particular?

Because it has the top 3 criteria necessary for a successful Open
Source project, because it's a compiler, it means your license
criteria, and it can be bent to the task.


> TenDRA was a research tool designed to help researchers STUDY
> compiler design; its most important feature is a robust intermediate
> representation of code which is passed from front end to back end.
> That intermediate representation is powerful, but generating it and
> then generating code from it is slow and a bit awkward.

On the other hand, it deals with the ANDF issue automatically,
and the seperation makes it more or less ideal for supporting
targetting other CPU types easily.

The important thing here is to have something that's functional
for all consumers who would normally consume GCC.

If you can name another compiler that meets your license criteria,
and is comparably ready to challenge GCC on the "it works" axis,
then name it, and you can use it instead.


> The other problem, from my standpoint, is that it's C. I try
> to avoid C whenever possible; about the only time I hack on
> it is when a client insists and/or if I'm working on one of
> the BSD kernels. If I'm in userland, I pick a different language.

Well, there's no escaping that.  8-).


> >NetBSD probably has the best seperation of code to make this
> >possible; OpenBSD has the most sympathetic ear, with regard to
> >license arguments, and FreeBSD is the best bet, if you want to
> >ensure a populist adoption.
> 
> I think that NetBSD would be sympathetic, too, since to be the
> portability champ means being portable among compilers, not just
> among OSes. Debugging by porting (which NetBSD strongly believes
> in) is a useful technique, but if you're using the same compiler
> on all platforms you're bound to miss bugs that the compiler
> hides.

Sympathy is less of an issue than coverage.  NetBSD has very many
platforms, compared to OpenBSD.  The number of OpenBSD platforms
is stretching it, relative to the back ends already available for
TenDRA.  On a coverage axis, OpenBSD and FreeBSD are almost
comparable -- they are very close relative to, say, NetBSD or Linux.

On another axis, that of compiler dependency, OpenBSD is least
dependent, NetBSD is more dependent, and FreeBSD is most dependent,
when it comes to use of compiler features.  Specifically, use of
inline assembly language, and mixing of platform dependent and
independent code, rather than seperation of such code into a modular
hierarchy.  FreeBSD is particularly bad, since it's portability is
very recent, relative to the other two.


> >For my money, if it were my axe that I was grinding, I would
> >probably pursue OpenBSD: it'd be more work than NetBSD, but a
> >lot less work than FreeBSD, and you are most likely to find
> >fanatics with strong opinions in the OpenBSD camp, NetBSD camp,
> >and FreeBSD camp (in order of decreasing fanatacism).
> 
> The OpenBSD camp (or at least Theo) hasn't been receptive when
> I've suggested "un-GNUing" their toolchain in the past.


I expect they want what everyone wants: you to present them with
a compiler that can compile their code base.  You've so far been
unable to do that, and that's not convincing to them, so they
(rightly) hold you at arms length (at least).

This is a third axis: amount of modification that has to go into
the host OS vs. the compiler code, to accomodate a tools change;
again, I'd rate it (easiest to hardest): NetBSD, OpenBSD, FreeBSD.

FreeBSD is going to be a hard sell, no matter how you look at it.


> >Let me know when you pick a platform, and start work, and have
> >some dedicated net-connected resources, and at least one other
> >person besides yourself working on it, and I'll be willing to
> >help you turn it into a going project.
> 
> Very tempting. We'll see. I'll be meeting with some key NetBSD
> developers during the next few weeks....

I've participated in the genesis of 7 Open Source projects, 5 of
which are what I'd call "successful", 6 of which are still what
I'd call "active".  Mnimally, I know what it takes to make one
work, and, most important to me, how to sit on the minimal effort
curve ;-) to get them to "going concern".

I'll tell you right now, the number one criteria for such a project
is "working code".

-- Terry

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E17C13A.B1B010CB>