asgard@cpro.UUCP (J.R. Stoner) (08/28/87)
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? [Some non-germane comments removed] > 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. 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. 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. 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. 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. -- "To prevent having to tell fools to RTFM don't let on you WTFM to begin with." J.R. Stoner asgard@cpro.UUCP asgard@wotan.UUCP P.S. I help CompuPro make computers. They do not help me make my opinions.
rlk@think.COM (Robert Krawitz) (08/28/87)
#include <stddisclaimer.h> 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 <dyer@athena.mit.edu>. 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
nwd@j.cc.purdue.edu.UUCP (08/30/87)
In article <7919@think.UUCP> rlk@THINK.COM writes: [Long quote about the FSF.....] >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. > This is mainly to clear up a point. MicroEMACS 3.9 has (and has had for a few versions) an extensive programming language which will allow most any task to be accomplished. As far as GNU Emacs and the FSF is concerned, these people have done a marvelous job of bringing a useful, versitile product to a lot of people. Those like myself, making new programs, have only done this by building on their experience. I think we should be thankful for this and not complain if they can't give us our every wish. Daniel Lawrence (317) 742-5153 UUCP: ihnp4!pur-ee!j.cc.purdue.edu!nwd ARPA: nwd@j.cc.purdue.edu FIDO: 201/2 The Programmer's Room (317) 742-5533
Karl.Kleinpaste@cbstr1.UUCP (08/31/87)
rlk@think.COM writes: =In article <352@cpro.UUCP> asgard@cpro.UUCP (J.R. Stoner) writes: =]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... Karl would say that Mr Stoner is patently out to lunch, because he hasn't noticed what's actually in those m-*.h files. A 3B{2,5,15,20} is remarkably unlike either a 68k or VAX processor. This is not to mention the fact that there is support for, e.g., the NatSemi processors with the presence of m-sequent.h, and Big Bluish things with m-amdahl.h. Before long, the Cray diffs will get back to the FSF for inclusion in a future release. Feh! on claims of 68k-and-VAX- only. The span of architectures supported is really very wide. The fact that the low end of the span is one level above the 286 is not the FSF's fault; it's Intel's, IBM's, and Microsoft's. By the way: I am leaving AT&T Bell Labs, starting work tomorrow (1 Sep) with Ohio State University's Computer Science Department. Karl karl@ohio-state.arpa (if Tut's x25 connection is alive) ...cbosgd!osu-cis!karl (3B2 UUCP gateway)
aaa@mtuni.UUCP (08/31/87)
For the record: *]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've had no trouble at all porting to the 3B2, the VAX, and to the UNIX PC. As far as doing "a good job porting emacs" to the 3B2--it is not much harder than typing "make" (a little, but not much). -- Aaron, mtuni!aaa, 201-957-2751
templon@silver.bacs.indiana.edu (jeffrey templon) (03/23/89)
If I want to donate some code to the FSF, where do I send it to? Jeff