macrakis@harvard.UUCP (Stavros Macrakis) (01/03/86)
--text follows this line-- Shaddock of rti-sel reports: > [I] but have decided that several unfortunate design decisions were > made... [in Gnu Emacs] As a (rather devoted) user of Gnumacs who has had nothing to do with its development, a few comments on his critique. > ... alloca will not work on machines without stack and frame pointers. > ... According to some people very familiar with Gould machines, > implementing a full alloca would be very, very hard, 1. I believe my previous news note shows that installing a portable variant of Alloca in Gnumacs is rather easy. It does require about 40 minor edits to Gnumacs itself (Mark/Release), and a half-page (or so) long alloca package. If you install the edits so that they preserve the status quo on machines that can support the usual kind of alloca, then everyone will benefit. `Implementing full alloca' is not the issue: the issue is getting a variant of alloca that will work. > GNU Emacs uses setjmp/longjmp... it would have been more portable > (and more correct in a pure theoretical sense) to return error > codes, etc. instead of just jumping to some other place ... 2. Is setjmp/longjmp also hard to implement on the Gould machines? Or is this just a stylistic question? Returning error codes everywhere can become extremely burdensome, especially for functions (as opposed to procedures). Since C provides no mechanism itself (like Ada exceptions or Lisp Errset/Catch), I can't see much alternative to the admittedly ugly setjmp. As for the `pure theoretical sense', I don't follow you. Are you saying that it would be difficult to write an axiomatic semantics for setjmp? Yes, certainly. But then, what part of C could you write a clean axiomatic semantics for? > Implementation of Lisp_Objects: Why wasn't a simple structure, such > as ... used instead this rather gross way of hacking on an int? 3. Gnu Emacs version 17 (at least) uses a union type. Not all C's support unions, so there is a conditional for a non-union implementation. > Unexec // Use of unexec is a gross hack merely for a little efficiency. 4. First of all, I don't see why you call it a `gross hack'; it simply creates a loadable image from a running image. Secondly, I think you will find it is not a question of `a little efficiency'. It is, indeed, a very clean way of initialization (since you have the full power of your programming language at initialization time). What do you propose as an alternative? Spending a few minutes each time you load a Gnu Emacs to re-initialize? This would be something like a compiler re-running its lexer and parser generators (Lex and Yacc) every time it compiled a program. Gnu Emacs has very large static data structures (namely the loaded routines) and would incur a heavy runtime penalty (not to mention a huge swapping penalty) without something like unexec. The wonder is not that Gnu Emacs uses unexec, but that unexec is not a standard Unix utility. I agree entirely with Shaddock that portability is important to Gnu Emacs, but he has not convinced me that Gnu Emacs is not portable. It is a very large systems program and there are bound to be things that will take some time to put right. None of the matters he brings up appear to require large investments of effort. It seems to me it is worth one man-week of effort from the Gould community to get a Gnu Emacs that will run on their machines. -s
tihor@acf4.UUCP (Stephen Tihor) (01/03/86)
If the program was designed with the intention for dumping the program state and later reloading it it is possible to write a faily portable but program specific code to permit the "initalized state" of the system structures to be saved and reloaded. Such coding should increase the set of possible hosts significant without requiring nonportable hcks to make initialization work well.
crl@newton.ARPA (Charles R. LaBrec) (01/06/86)
The big advantage of using unexec over a dump/reload of memory is that unexec puts some of the initialized areas into text space, thus making about 200 KB of memory sharable among all the users of GNU emacs. Charles LaBrec crl @ newton.PURDUE.EDU -- Charles LaBrec crl @ newton.PURDUE.EDU
fnf@well.UUCP (Fred Fish) (01/07/86)
In article <145@newton.ARPA> crl@newton.UUCP (LaBrec) writes: >The big advantage of using unexec over a dump/reload of memory is that >unexec puts some of the initialized areas into text space, thus making >about 200 KB of memory sharable among all the users of GNU emacs. This is only true for systems where data starts immediately after text. In a very large number of cases, MMU braindamage dictates that there be a significant gap in the address space, between end of text and start of data. GNU emacs basically shoves things into text space by extending it to overlap part of the data space. If you have a 4Mb "hole" between text and data, you end up with a VERY large shared text program! -Fred -- =============================================================================== Fred Fish (415) 644-1230 ext 242 ucbvax!unisoft!fnf well!fnf ===============================================================================
crl@newton.ARPA (Charles R. LaBrec) (01/10/86)
In article <438@well.UUCP> fnf@well.UUCP (Fred Fish) writes: > ... GNU emacs basically shoves things into text space by >extending it to overlap part of the data space. If you have a 4Mb >"hole" between text and data, you end up with a VERY large shared >text program! And if your system is demand-paged (what system that GNU EMACS runs on isn't?), then the hole is never paged in, so, no lossage to the system. Charles LaBrec crl @ newton.PURDUE.EDU -- Charles LaBrec crl @ newton.PURDUE.EDU
fnf@unisoft.UUCP (Fred Fish) (01/16/86)
In article <415@newton.ARPA> crl@newton.UUCP (LaBrec) writes: >In article <438@well.UUCP> fnf@well.UUCP (Fred Fish) writes: >> ... GNU emacs basically shoves things into text space by >>extending it to overlap part of the data space. If you have a 4Mb >>"hole" between text and data, you end up with a VERY large shared >>text program! > >And if your system is demand-paged (what system that GNU EMACS runs on >isn't?), then the hole is never paged in, so, no lossage to the system. My original posting still stands. Since I see no "smiley-face" on yours, I have to assume that you are not aware that there are other systems in the real world that are not demand-paged. GNU emacs runs quite nicely on UniSoft's SVR2 (swapping) port for the 68000 and 68010. There is nothing in GNU emacs that requires it to be running on a demand-paged system (though it certainly helps). -Fred