Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!think!rlk From: rlk@think.COM (Robert Krawitz) Newsgroups: comp.emacs Subject: Re: Free Software Foundation (was: Re: Mach, the new standard?) Message-ID: <7919@think.UUCP> Date: Fri, 28-Aug-87 13:44:20 EDT Article-I.D.: think.7919 Posted: Fri Aug 28 13:44:20 1987 Date-Received: Sun, 30-Aug-87 01:43:13 EDT Sender: news@think.UUCP Reply-To: rlk@THINK.COM Organization: Thinking Machines Corporation, Cambridge, MA Lines: 142 warning: long #include Apologies to people who object to the fact that this has little to do with emacs. But I really hate to see the FSF get slammed like this. In article <352@cpro.UUCP> asgard@cpro.UUCP (J.R. Stoner) writes: ]in article <738@hplabsz.HPL.HP.COM>, kempf@hplabsz.HPL.HP.COM (Jim Kempf) says: ]> In article <83@splut.UUCP>, jay@splut.UUCP (Jay Maynard) writes: ]>> I'll support the Free Software Foundation when they give up their processor ]>> bigotry and decide to support the machine architecture that I use (PC/AT). ]>> Until then, why should I waste my money? 1) Good question. Why should you? You can get Microemacs and MicroGnuEmacs from the net, either of which will run quite nicely on an AT. These don't have the programming power that GNU Emacs has, but for editing text I'm told that they are quite good. A lot of GNU utilities will run on 286 class machines; I know that one company sells Bison for $25. The kernel won't, though. 2) If there's sufficient demand, and enough 286 hackers around, that just might get done. If Stallman refuses to distribute 286 code that someone gives to him that runs GNU or Emacs, then you might have a point. But no one's done that yet. Then again, the 286 users might become 386 users. See below. ]> Additionally, Stallman prefers using machines with larger address spaces ]> because they're easier to program. This is understandable, since it allows ]> him to concentrate his time on things other than trying to reduce the size ]> of things to fit in 640K. ] ]> I, too, would like to see FSF's software on the PC/AT and PC/XT, but ]> I think its unreasonable to expect FSF to do it. ]> Jim Kempf kempf@hplabs.hp.com ] ]Who said anything about 640K? As it happens the only reason you think there is ]such a limitation is the messyDOS foulup and attendant marketing BS. But the segment size on a 286 is 64K. It's possible to use multiple segments, but it is rather painful and slow. And the Free Software Foundation would rather get GNU to run than worry about all the hair needed to make it run on painful architectures. They don't promise a system that anyone can run on any machine. They want to come out with a system that can run on a certain class of machine. People who port it to other architectures will no doubt find that the FSF will gladly accept their contribution, as long as it is in line with their goal (the GNU project). ]I run UNIX on my AT and 2+ Mb of RAM. It would sure be nice to see some of ]this stuff even compile properly with the ATT compiler, let alone run without ]segment faults due to sloppy coding practices. I have seen it in major soft- ]ware and not just Joe Hacker programs. VN for instance, and ELM are major ]problems due to VAX hacker bigots who think they are the only things going ]around. All it takes is to write your code properly in the first place and ]the processor does not get in the way. Some people did not follow that simple ]principle. That is why it took *forever* to get a compress program that allows ]16-bit residency when the OS requires data items to fit in 64K. What do you mean "write your code properly in the first place"? If I have a data item that's 1 meg in size, that's perfectly legal. If your machine can't handle it, tough. But it IS spec code. If it isn't, I'd like to know. By "spec" I mean that ANSI C spec, for example. Not the literature for the Frobozz C compiler. I have little sympathy for people who rely on byte ordering when they don't have to, or for people who dereference null pointers, if they should know better. But some things really do need to worry about byte ordering if they are to run efficiently. What you do in that case is provide some sort of conditional. Maybe not spec, but unfortunately some things need to be done this way. A "VAX hacker bigot" is one who assumes that memory location 0 can be safely dereferenced and that little endian byte ordering prevails. I find it hard to understand how the processor does not get in the way when you want to run a multi-megabyte application on top of a multi-megabyte system on a small machine. Quite specifically, the processor gets in the way. And why should we stop at AT's? Why not insist that GNU run on a Z-80 box, or an Apple II? After all, there are a lot of those 8 bit machines in regular service. You pointed out that compress had difficulties because the operating system restricted data items to 64K. Why should IBM compatibility, which is what this essentially boils down to, be the criterion for good code? In this case it sounds like IBM and Microsoft made the mistake, and working around it was difficult. ]You do not have to have every processor in the world to write careful code. ]All you need do is select people who are willing to test your code on their ]machine who are knowledgable about real-world system limitations. Then get ]the beta reports BEFORE inflicting bad code on those of us who depend on the ]safe functioning of programs for our livelyhood. But the Free Software Foundation never tried to claim that any of their software would run on a small machine. The "real world system limitation" is that something as big as GNU will not run on a small machine. ]The FSF/GNU people pretend their programs install with the proper m-machine.h ]files. This does not appear to be true. After looking at 18.47 for too long ]I gave up trying to second-guess bad code and removed it. The only cpu types ]supported were 68000 and VAX. I wonder what Karl Kleinpaste would have to say to that? I don't use 3B's, but he's evidently done a good job porting emacs to that architecture. As for machine support, a quick ls -l m-*|wc shows that approximately 36 machines are supported right now, and I can think of other architectures whose m- files haven't made it back in yet. Only one of these is a VAX, and there are lots of non-68K architectures in there. I'm actually quite impressed by how portable emacs is, given how big and complex it is. It really isn't easy to write a system like emacs, which is roughly as big as the 4.3BSD kernel, to run reasonably easily on any architecture. Really, if you want big-time penetration in the ]existing user community (a lot of us 286/UNIX users and growing) you at least ]could put some effort to limit the memory use patterns of your code, at least ]if you are interested in not appearing to be too big for we rabble. True, often the code has to be modified slightly. And there are some known machine dependencies in the code. But these are generally well documented and it's possible to work around them. There aren't many big surprises left; most of the code has been cleaned up pretty well. I don't think the FSF is interested in big time penetration in the existing user community per se. They want to develop a freely available system that can be built upon. They have chosen, as is their prerogative, to support 32 bit architectures because they are much easier to program. BTW, if you want GNU emacs for a 386 based architecture, you might try contacting Steve Dyer . He recently brought up emacs on a 386 box running Xenix. I was very impressed by its performance. And while it's unlikely that anyone's going to port emacs or GNU to the 286, the same cannot be said for the 386. But in a few years, when GNU might actually be usable as an operating system, 386 boxes will be as cheap as 286 boxes are today. I also know that Paul Rubin, who does a lot of work for the FSF, likes the 386. Robert^Z