Re: news from the west

[William "Chops" Westfield <BillW@SU-SCORE.ARPA>]

Sigh.  I guess since my message was forwarded to the list, I ought to give
a more technical description of what's been done...  Here is my understanding:

First of all, most of the changes have nothing to do with the version
that GUMBY installed at CSLI.  The only thing in common with that new
version is the "self-updating marks".  I am not sure exactly what self
updating marks are - The code has comments like "see end of TECORD.INFO",
and when I look there, I see nothing about self-updating marks.  I am
trying to track this down now...

The "current" version of EMACS is 163.  Unfortunately, there are several
versions of 163 around - some have separate TECTRM.MID files, and some
don't.  The v163 at SRI contains the original TEXTI code, but didn't have
its version bumped.  Although those modifications were announced over a year
ago, they didn't make it back into "standard" sources - largely because it
doesn't work unless you turn the new code on.

Meanwhile, at Stanford (I think) Ethan Bradford added the self-updating
mark code, and OZ has also made changes.  For better or worse, we are
calling the EMACS with S-U Marks but no TEXTI support version 164.

Version 165 comes about when Ethan merges his changes with the
new code on OZ, and then I add TEXTI support and the other
modifications mentioned in Cent's message.  Maybe it should
be called v166 after the efficiency improvements are in?

Here is a more technical description of the efficiency hacks:

	The TEXTI mods.  When at the end of a line (plus other conditions)
	use TEXTI to read and echo all the way up to a break character.
	TOPS20 has been modified not to echo the break character, and
	to solve other misfeatures that prevented this from being done
	in the past.  Both REL5 and REL6 have been thus patched.  DEC
	has said they will try to get this change into 6.1.  This is
	apparently a really big win if you use DECNet, because the echoing
	in texti is done on the local host.

	Rewrite ALL of the terminal drivers to buffer their output
	until the final return, at which point do the -N form of
	SOUT (instead of psout), which I have already optimized in
	the monitor.  No longer does code look like:
	  MOVEI A,33; PBOUT; MOVEI A,"H; PBOUT
	Instead it is effectively HRROI B,[$H], MOVNI 3,2; SOUT
	Recall the BLAST monitor patch approximately double the
	speed of this form of SOUT for short strings over normal
	PSOUT.  I don't have the heart to compare it to a succession
	of PBOUTS...

	use INSERT MODE terminal MUCH better.  Only go in and out of
	insert mode when absolutely necessary.  Right now, if you
	type ^U 4 A at the beginning of a line, EMACS will do:
	 INS-ON SPACE BACKSPACE INS-OFF "A"   four times! (and INS-ON
	can be a 4 character sequence on an ANSI terminal.) The new
	code does INS-ON "A" "A" "A" "A"  and doesn't turn off
	insert mode at all until characters are output that shouldn't
	be inserted.  The way that this is set up it is relatively
	easy to deal with terminals that can insert arbitrary large
	strings without padding, but normally the users typing speed
	is plenty of "padding".

That's been done.  This is what's still in progress:

	use CRLF, CR, LF for cursor positioning where possible.

And I'm sort of considering (in order of practicality):

	define an IDEAL terminal type.  This would be able to do all
	of the emacs functions in a maximum of two bytes. (on a 25x
	80 display.  Bigger terminals are not "ideal").

	make the IDEAL terminal type do the equivalent of TEXTI
	locally.  This would enable EMACS to use SINs for TTY
	input most of the time. (even better than TEXTI)
	Is this similar to MITs VTS or LEP stuff?  I dunno.

   The above are applicable because many of the "terminals" being
   connected to things these days are actually microcomputers, running
   terminal emulators.  Many of the terminal emulators can be modified.
   Perhaps the ethertip can emulate the IDEAL terminal and translate
   as appropriate for individual terminals.  SUNs can clearly do this.

	Do TEXTI locally in ethertip/sun via an extension to TELNET
	protocol (is there already a set break mask option?  I wish
	all of the TELNET options would be collected into one RFC!)
	6.1 (decnet phase 4) has a facility for doing TEXTI remotely,
	but I suspect that getting it to work over TCP/PUP.etc would
	be pretty hairy.

Most of these changes are at the system level - ie they will not
result in a highly visible improvement (like much faster screen
updating) to users, but should lessen the impact of emacs on the
system.  (they also assume the TTY IO is one of the most expensive
thing that emacs does, which isn't always or necessarily true.
For example, Kirk has suggested that one of the UNIX emacs's like
ELLE be brought up under the assumption that it is more efficient
by not having (interpreted) TECO as an intermediate level).


If anyone has any other suggestions, id be happy to take them
into consideration.


--------------------------------------------------

Now then, perhaps there are sites that find all this interesting,
and would like to get their hands on the code to see if they can
notice any performance differences (By the way, id really like to
hear from anyone who figures out a good way to MEASURE whether this
all helps or not.  Mere CPU time used by EMACS wont be all that
useful, since a lot of what is saved is things like context switching,
which doesn't show up in users runtimes).

The TEXTI code was done at SRI.  You can find a description and
source level patches in SRI-KL:<EMACS>TEXTI.MEM  It may be possible
to convert the source patches to object patches, but I don't know
of anyone who has done so.  Those of you running variations of
Stanford's monitors already have the patches.  Kirk Lougheed at
Stanford cleaned up the coding style and included everything in
STANSW's, and also made it work for version 6, when TTY buffers
are in extended sections.  The modules affected are TTYSRV, COMND,
and FILMSC (I think).

The most recent TECO, TECTRM, EMACS, and so on are at SCORE, in
PS:<EMACS165>.  Help yourself, and send bug reports back to me.

Bill Westfield

PS: I make no claims that any of this is READY for distribution yet.
    Only the impatient or the desperate should take the SCORE stuff
    now.  The changes in SRI-KL:<EMACS> have been running for a while
    and should be pretty stable though...