wunder@wdl1.UUCP (04/07/85)
As for trying to get GNU Emacs up on the Sun, this is how far we've gotten: regex.c: line 937: change "register char c" to "char c" line 1019: change "register char c" to "char c" For some reson the Sun compiler is overwhelmed by the presence of this particular register variable in a couple of expressions. regex.c comilpes fine with those two changes. unexec.c: This is very VAX specific. It is only called from one place (the dump-emacs command), and could be removed entirely, but dump-emacs seems to be used to build the final emacs binary. Anyone care to rewrite unexec.c? w underwood wunder@ford-wdl1
steveh@hammer.UUCP (Stephen Hemminger) (04/10/85)
I am in the process of porting it to the Tektronix NS32000 workstations.
Here are some observations:
unexec.c
Got this to work by rewriting the read_u code, see below.
Same type of code should work on a 68000
crt0.c
Needed different code, just wrote a six line assembly routine.
null pointers.
Display code derefence's null pointers a lot, thinking
of either making a new crt0.o with a page of null's at
the front (ugly), or trap it some way.
/* ****************************************************************
* read_u
*
* Get the u structure (from memory.)
*/
#if !defined(ns16000)
static
read_u()
{
u = *(struct user *)UADDR; /* Simple, when it's in core... */
return 0;
}
#else
/* on Tektronix NS32000 workstations */
static
read_u()
{
register int kmem;
struct nlist nl[2];
/* nlist is a union in a.out.h so can't initialize directly */
nl[0].n_un.n_name = "_u";
nl[1].n_un.n_name = 0;
if(knlist("/dev/cvt",nl) != 0) { /* knlist is a funky nlist() */
PERROR("reading namelist");
return -1;
}
if( (kmem = open("/dev/kmem", 0)) < 0) {
PERROR("can't open kmem");
return -1;
}
lseek(kmem, (long) nl[0].n_value, 0);
read(kmem, (char *) &u, sizeof u);
close(kmem);
return 0;
}
#endifdrs@bnl.UUCP (David R. Stampf) (08/02/85)
I've been able to port gnuemacs onto a sun (version 16.??) and while it seems to run ok, it seems to manage the screen poorly. The documentation that comes with emacs warns of this and suggests that the termcap entry should be changed, but doesn't suggest how. Any ideas? <dave.
rusty@sdcarl.UUCP (rusty c. wright) (08/08/85)
In article <140@bnl.UUCP> drs@bnl.UUCP (David R. Stampf) writes: > > I've been able to port gnuemacs onto a sun (version 16.??) and while >it seems to run ok, it seems to manage the screen poorly. The documentation >that comes with emacs warns of this and suggests that the termcap entry >should be changed, but doesn't suggest how. > > Any ideas? > > <dave. Yes, i have a suggestion that is just as useful as the information you provided about the troubles that you are having: try making your termcap file be more intelligent about handling your terminals. -- rusty c. wright {ucbvax,ihnp4,akgua,hplabs,sdcsvax}!sdcarl!rusty
jeff@fluke.UUCP (Jeff Stearns) (08/23/85)
In article <140@bnl.UUCP> drs@bnl.UUCP (David R. Stampf) writes: > > I've been able to port gnuemacs onto a sun (version 16.??) and while >it seems to run ok, it seems to manage the screen poorly. The documentation >that comes with emacs warns of this and suggests that the termcap entry >should be changed, but doesn't suggest how. > > Any ideas? > > <dave. I had the same feelings about Gosling's emacs; it would manage the screen *correctly* but in some very sub-optimal ways. The details have faded from memory, but the basic idea is simple - it would perform a screen update over n lines (or characters) by issuing n escape sequences. This kills Sun workstations because the scrolling is done in software and it takes a lotta CPU cycles to scroll the screen or shift some characters horizontally. This isn't peciliar to emacs at all. The same thing happens in vi, but it's less frequent because the vi working style generally avoids large changes to the screen. You *can* see it; type 34^Y and watch 5 seconds elapse. I think that part of the problem lies with the way that termcap capabilities are expressed. Some capabilities aren't parameterized, so the editor can't express the big picture (delete 10 lines) but must rather issue a series of micro-operations to accomplish the same thing (delete line; delete line; delete line; ...). This is what bogs down a Sun. Since Gosling's emacs knows what the "big picture" is, and computes screen updates in terms of rectangular screen regions anyway, why not let it express itself directly via bitblt operations? I did this several years ago by writing a set of terminal driver routines to allow emacs to update the screen directly via rasterops. This actually *simplified* the emacs terminal driver, since it no longer had to map bitblt operations into escape sequences. Shortly thereafter, I received an equivalent set of routines from Michael Caplinger at Rice University; I'd say his did a better job of handling the display. I suspect that Unipress now distributes a rewrite of this code with their emacs. The code is surprisingly easy to write if you're familiar with the Sun window package, and it might make an interesting exercise to see how well the idea applies to gnuemacs. -- Jeff Stearns (206) 356-5064 John Fluke Mfg. Co. P.O. Box C9090 Everett WA 98043 {uw-beaver,decvax!microsof,ucbvax!lbl-csam,allegra,ssc-vax}!fluke!jeff