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>