HDTenEightyP/NetNews huggingface dataset:
From: ejg@ednor.bbc.com (Ed Gaudet)
Subject: Re: VAX/TPU editor for UNIX
Keywords: VAX
Organization: Boston Business Computing, Ltd.
Date: Thu, 9 Apr 1992 14:16:39 GMT

In article <tgcpmv.702722791@rwa.urc.tue.nl> tgcpmv@urc.tue.nl writes:
>Hello,
>
>We have a DEC/ULTRIX system, with editors like vi, emacs, jove and joe.
>However, there still are a lot of users who are real VAX/VMS freaks, an they
>keep asking me for an editor like the VAX TPU or EDT editor. 
>
>Can anyone tell me where to get (the source of) such an editor?
>
>--
>Martien Verbruggen (tgtcmv@chem.tue.nl)
>Eindhoven University of Technology
>The Netherlands.
>--
>Nostalgia isn't what it used to be.


Boston Business Computing offers a suite of VMS tools for Ultrix and
other popular UNIX platforms (SGI, IBM, SUN, Sequent, etc.).  Among
these are VAX EDT/TPU, VMS BACKUP, VMS MAIL, and VMS DCL emulation 
software.

Products are sold through worldwide distribution.  In the Netherlands call

	Peter van Doesselaar
	Interparts
	31 2521 19169

	Paul Grootaers
	A en A
	31 3523 2629

Regards,

Ed
***************************

Edward J. Gaudet, CBC			"The Road of Excess Leads
Boston Business Computing		 to the Palace of Wisdom."
Three Dundee Park				
Andover, MA  01810				- W. Blake
508-470-0444, ext. 303
***************************
From: S.Courtenage@cs.ucl.ac.uk (Si Courtenage)
Newsgroups: comp.editors
Subject: Jove editor for PC?
Date: 16 Apr 92 11:55:56 GMT


Does anyone know where I can get (via FTP) a Jove executable
for a 80286 IBM-comp PC?

Thanks

Simon Courtenage
University College London
From: colin@array.UUCP (Colin Plumb)
Newsgroups: comp.editors
Subject: Re: Editor theory?
Date: 7 Apr 92 07:22:43 GMT
Organization: Array Systems Computing, Inc., Toronto, Ontario, CANADA

For the answers to all (okay, most) of these issues, find and read:

The Craft of Text Editing: Emacs for the Modern World
Craig A. Finseth
1991 Springer-Verlag
ISBN 0-387-97616-7 (also 3-540-97616-7)
QA76.76.T49F56 1991

And a few Library of Congress bits that look useful but I don't understand:

p.  cm.
Included bibliographical references and index
1. Text editors (Computer programs)  2. GNU Emacs (Computer program)  I. Title
652.5'512-dc20		91-16289

Anyway, he explains buffer gaps, space-at-end, linked lists of lines,
and paged variants of all the above.  Nifty ideas on managing redisplay,
and basically lots of collected wisdom on writing a text editor.

At the end of chapter 6, he challenges readers to come up with an
algorithm that's better than the buffer gap.  My humble suggestion
is thrown out here for public criticism:

Keep a reasonably balanced (avoid empty pages) tree of pages of
bytes.  Use some B-tree-like split/merge operations; I haven't decided
on the optimal scheme.  This is basically the paging.  If it's kept in
a tree, then each internal node can keep a count of the number of bytes
to the left of it, and you can find the nth byte in log(N) time, just
as you can insert bytes at position n.

Each page stores the data contiguously at the beginning, with extra space
at the end, EXCEPT:

There is a current location ("point" in emacs terminology), which defines
a current page.  Keep this page as a buffer gap.  The most frequent operations
(in particular, insert and delete character) can be optimized to work with 
the gap, but rarer operations can collapse the gap, reducing the tree to
a collection of contiguous pages, easily manipulated.  Also, within one
page, updating the tree's characters-to-the-left counts can be delayed
until the gap is collapsed, either because the page is full and needs to
be split, or a global operation needs to be done.

Because the pages are reasonably small (1K?), the gap motion is not a great
deal of work, nor is collapsing it for the benefit of gap-ignorant functions
(e.g. global search and replace).  However, you still gain the advantages
of the buffer gap for incremental character insertion and deletion.

Hey, it's just an idea...
-- 
	-Colin
Xref: sparky comp.editors:1371 comp.terminals:648
From: kodavar@eemips.tamu.edu (Ravi Kodavarti)
Newsgroups: comp.editors,comp.terminals
Subject: GMACS
Date: 10 Apr 92 20:07:15 GMT
Followup-To: comp.editors
Organization: Texas A&M University

I beleive there is an emacs for PC's - called gmacs . 
Does anyone know if I can copy thisfrom a ftp site ? 
Please send me a private reply. I dont  read this ng often
Thank You
Ravi
From: tgcpmv@rwa.urc.tue.nl (Martien Verbruggen)
Newsgroups: comp.editors
Subject: VAX/TPU editor for UNIX
Keywords: VAX
Date: 8 Apr 92 08:46:31 GMT
Reply-To: tgcpmv@urc.tue.nl

Hello,

We have a DEC/ULTRIX system, with editors like vi, emacs, jove and joe.
However, there still are a lot of users who are real VAX/VMS freaks, an they
keep asking me for an editor like the VAX TPU or EDT editor. Well, I'm not a
fan of the V(omit) M(aking) S(ystem), but I have to keep my users happy.

Can anyone tell me where to get (the source of) such an editor?

--
Martien Verbruggen (tgtcmv@chem.tue.nl)
Eindhoven University of Technology
The Netherlands.
--
Nostalgia isn't what it used to be.
From: pgf@cayman.COM (Paul Fox)
Newsgroups: comp.editors
Subject: Re: "c," in vi
Date: 8 Apr 92 13:14:28 GMT
Organization: Cayman Systems Inc., Cambridge Ma

mike@abekrd.co.uk (Mike Quinn) writes:
: In <1992Apr2.233745.18452@quantime.co.uk> roger@quantime.co.uk (Roger Phillips) writes:
: 
: >Suppose the cursor is at the beginning of this line:
: >	Once upon a time.
: >You type "ct Twice^[", to change the first word to "Twice":
: >	Twice upon a time.
: >Then you move to the end of the line and start typing "c,"...
: >Instantly, the line has changed to:
: >	Twice upon a Twice.
: 
: A quick glance at my "Quick Reference for vi" from those nice Hewlett-Packard
: people reveals the following:
: 
:  , (comma)	Repeat, in reverse direction, last f F t or T search command.
: 
: so c, is asking vi to change the word in front of the cursor using the
: previous change.
           ^^^^^^
It's clearly a bug -- it should repeat the previous motion, _not_ the
previous change.  Think what would happen if the 'w' motion worked like
that:

	    v
	    Once upon a time.
cwTwice^[
                v
	    Twice upon a time.
www
                         v
	    Twice upon a time.
cw
                         v
	    Twice upon a Twice.

Not what you expected.  It's behaving as if you typed '.'.


paul fox, pgf@cayman.com
-- 
		paul fox, pgf@cayman.com, (617)494-1999
		Cayman Systems, 26 Landsdowne St., Cambridge, MA 02139
Xref: sparky comp.arch:5046 comp.ai:2006
From: smith@sctc.com (Rick Smith)
Newsgroups: comp.arch,comp.ai
Subject: Re: Voice Recog. on Desktop
Date: 15 Apr 92 15:05:19 GMT
Article-I.D.: sctc.1992Apr15.150519.5356
Organization: SCTC

> eugene@wilbur.nas.nasa.gov (Eugene N. Miya) writes:

>>I have yet to find a machine which can get pass the first test:
>>	How to recognize speech.     [1]
>>	How to wreck a nice beach.   [2]

And markg@pdx077 (Mark Gonzales) replies:

>This is a rather unfair test, most humans would have trouble
>distinguishing [1] from [2], especially without any conversational
>context.

Not so. Even the best speech recognition systems today
can't distinguish between the two when spoken at a normal
rate of speech, even when seen _in_ context.

Various people addressed this problem in the ARPA speech project
in the '70s but I don't believe that practical real time
implementations of their techniques exist yet.

My original post (in comp.arch, for those that remember) stated the
opinion that general purpose speech recognition isn't going to
be a turnkey application any time soon. Miya's example illustrates
it perfectly. Speech recognition is too knowledge intensive and
it rapidly becomes dependent on techniques that won't be able to
to solve the problem in real time. I can believe that we could build
a less than real time system that handles a restricted realm of
discourse, as illustrated by the work for (D)ARPA back in the '70s.

Speech recognition can and will be used in applications with
severely restricted discourse, like single-word commands over
phone lines to answering machines, telemarketers, and such.
That's really different from a general purpose dictation system.

Rick.
smith@sctc.com           arden hills, minnesota
Newsgroups: comp.arch
From: solman@athena.mit.edu (Jason W Solinsky)
Subject: Re: Generic Top Secret Microprocessor Development Plan
Organization: Massachusetts Institute of Technology
Date: Mon, 13 Apr 1992 08:40:43 GMT

In article <DOCONNOR.92Apr12223346@pima.inews.intel.com>, doconnor@pima.inews.intel.com (Dennis O'Connor) writes:
|> 
|> dow@idtg.UUCP (Keith Dow) writes:
|> ] >1994 Scratch heads over lack of toaster-based applications, and the fact
|> ] >	that the unit cost is still too high to compete, which makes it
|> ] >	hard to convince people to base toasters on a $1800 chip
|> ]
|> ] The 64-bit microprocessors can be down-sized easily.  Typically two
|> ] years after a microprocessor has been introduced, the package costs
|> ] more than the die. 
|> 
|> Especially if the package has 800 pins, with a diamond substrate and 
|> freon channels to duct away the 200 watts of power the chip dissipates ! :-)
|> 
|> Seriously: Yes, large-pin-count high-speed hi-power packages cost big bucks.
|> 
|> But getting into the "toaster" market requires you to package into a small,
|> cheap, plastic package with maybe 84 pins and maybe the abilty to dissipate
|> 2 watt. I don't think anyone's new top-end workstation/mini/PC processor die
|> will cost less than THAT package two years after introduction.

I'm not sure there is going to be much money in the intelligent toaster market.

Jason W. Solinsky -- CEO of TTC, Thinking Toasters Corp. :-)
From: solman@athena.mit.edu (Jason W Solinsky)
Newsgroups: comp.arch
Subject: Re: Cray Soap Opera WAS: Re: GaAs Alpha implementation
Keywords: Alpha, Gallium Arsenide
Date: 8 Apr 92 04:21:30 GMT
Organization: Massachusetts Institute of Technology

In article <1992Apr06.174145.10353@skynet.uucp>, ice@skynet.uucp (Ice) writes:
|> [Times change so quickly. I was in grade ten, talking about the Cray 2 in
|> front of my data processing class, and discussing about massive parallelism
|> in the Non-Von by David Shaw of Columbia University. Cray 2 was the hottest
|> thing back then; all of 1 billion MFLOPS at peak. Unimaginable to someone
                             ^^^^^^^^^^^^^^
|> reared on Commodore PET 4032s]...

That's pretty good. I wonder why the MITSF switched to an XMP if they had a
machine doing 1000 TFLOPS? :-)

Jason W. Solinsky
From: ts@cup.portal.com (Tim W Smith)
Newsgroups: comp.arch
Subject: Re: And now for something completely different...
Date: Fri, 10 Apr 92 14:49:48 PDT
Organization: The Portal System (TM)

> > Also, if you do the multiply in hardware would it not sometimes be easier
> > to shift once and subtract rather than shift and add. Example: to multiply
> > by 7: shift left 3 and subtract once. Is it ever worth it to handle these
> > special cases? (I mean in hardware, not software. I don't wish to make
> > this a compiler issue.)
> 
> You have a non-trivial problem here in detecting when the special cases
> occur.  I often think that it would be worth detecting multiplication by -1

For multiplies by constants, you could let the compiler detect the special
case and have some mechanism for letting the processor know this.  For
example, you could have a "constant multiply" instruction that takes
a pair of bit masks.  The first tells it on what shifts to add, and the second
tells it on what shifts to subtract.

This might be useful for C array-of-structure index calculations, where
funny constants often show up.

							Tim Smith
From: sog@craycos.com (Steve Gombosi)
Newsgroups: comp.arch
Subject: Re: Cray Soap Opera WAS: Re: GaAs Alpha implementation
Keywords: Alpha, Gallium Arsenide
Date: 8 Apr 92 14:31:14 GMT
Article-I.D.: craycos.1992Apr8.143114.1926
Organization: Cray Computer Corporation

In article <1992Apr8.042130.23242@athena.mit.edu> solman@athena.mit.edu (Jason W Solinsky) writes:
>In article <1992Apr06.174145.10353@skynet.uucp>, ice@skynet.uucp (Ice) writes:
>|> Cray 2 was the hottest
>|> thing back then; all of 1 billion MFLOPS at peak. 
>                             ^^^^^^^^^^^^^^
>That's pretty good. I wonder why the MITSF switched to an XMP if they had a
>machine doing 1000 TFLOPS? :-)

It was a health hazard. With the clock rate needed to achieve that FP
performance, the damned thing was radiating UV like crazy ;-).

Steve Gombosi
sog@craycos.com
From: brian@king.csd.mot.com
Newsgroups: comp.arch
Subject: Re: Generic Top Secret Microprocessor Development Plan
Date: 10 Apr 92 22:12:22 GMT

mjr@hussar.dco.dec.com (Marcus J. "will do TCP/IP for food" Ranum) writes:

>2006 Company goes out of business, while Microsoft DOS10.0-running Intel
>	based machines continue to dominate the market

 ...which still waits for The Promise of NT.
Newsgroups: comp.arch,comp.ai
From: peter@ferranti.com (Peter da Silva)
Subject: Re: Voice Recog. on Desktop
Organization: Xenix Support, FICC
Date: Wed, 15 Apr 1992 14:06:13 GMT

In article <sfu1jINNjc6@agate.berkeley.edu> jbuck@forney.berkeley.edu (Joe Buck) writes:
> In article <GLEW.92Apr14153132@pdx007.intel.com>, glew@pdx007.intel.com (Andy Glew) writes:
> |> Give me voice for entering mass quantities of text.

> Really?  I type almost as fast as I talk and I don't have to worry about
> the ums, ers, and changes of mind.

Yeh, I'd rather use voice as a command channel, letting me get away from
having modes or having to move my hand off the keyboard to pick up a mouse.
I can't imagine reliably "speaking"

	for(i = 1; i < ac; i++) {
		if(av[i][0] == '@') {
			av[i]++;
			expand(av[i]);
		}
	}
-- 
/F{findfont exch scalefont setfont}def /S{moveto show}def /T{/Times-Roman F}def
8 T(Ferranti International Controls Corporation)24 28 S(+1 713 274 5180)24 12 S
(Sugar Land, TX  77487-5012)24 20 S 12 /Courier F(`-_-')320 32 S( 'U` )320 16 S
12 T(Peter da Silva)24 36 S 16 T(Have you hugged your wolf today?)358 24 S
Newsgroups: comp.arch
From: drb@cs.brown.edu (Dan Bornstein)
Subject: Re: Microcoded processors?
Organization: Brown Computer Science Dept.
Date: Thu, 16 Apr 1992 20:41:42 GMT

In article <1992Apr13.215255.2509@murdoch.acc.Virginia.EDU>, 
sdm7g@aemsun.med.Virginia.EDU (Steven D. Majewski) writes:
>The ALPHA idea of macro-code atomic instructions looks like the best of 
>both worlds: a realization of Virtual Writable Control Store. 

Just a little request for clarification: what's the difference
between ALPHA's "macro-code atomic instructions" and good old-
fashioned traps? (If this is obvious, please don't skewer me
too bad. I'm new at this stuff.)

-dan
drb@cs.brown.edu      You have to go to school because YOUR PARENTS ARE ALIENS!
                      And when you leave they SHED THEIR HUMAN SKIN and
                      BREATHE DRYER LINT!
                          -- Dr. Stupid
From: huff@cs.cornell.edu (Richard Huff)
Subject: Re: Condition Codes and RISC arch.
Organization: Cornell Univ. CS Dept, Ithaca NY 14853
Distribution: comp
Date: Tue, 7 Apr 1992 14:08:52 GMT


Elan S. Feingold asks...
>Why don't the latest RISC processors (or any microprocessors)
>have conditional codes inbedded in every instruction?
>
>  ... an outline of how to use the facility ... (omitted)

The idea you outlined can be generalized slightly
to what Cydrome called "predicated execution" in the
Cyrdra 5 departmental supercomputer.  Instead of using condition
codes, you have explicit predicate registers (1 bit each).
The optimization that you showed is then called
"if-conversion", as it converts if statements into
straightline code.  By using different predicate registers
instead of a single condition code register, the statements
can be more flexibly scheduled.  The big win is for
VLIW machines, such as the late Cydra 5, which can do
software pipelining MUCH more easily when the innermost
loop body has been if-converted to a single basic block.
See the Jan '89 issue of IEEE Computer for a nice article
on the Cydra 5 architecture.

For RISC machines the wins are not so large.
Why?  Well, for one thing, if-conversion implies that the
CPU will issue the instructions for BOTH the true and false
branches.  If you have a VLIW with empty slots for the
extra instructions, it costs nothing.  But a RISC will
always eat one cycle per nullified instruction.

Hewlett-Packard's Precision Architecture (PA-RISC) has a
"conditional nullification" feature that has a similar
effect.  In essense, all ALU operations
can specify a condition underwhich the following instruction
should be nullified (i.e. squashed like a NOP).  Although
less general than full predicated execution, it works very
nicely in practice for the sort of example you gave.

The same issue of IEEE Computer has an article on PA-RISC.
In addition, the Hewlett-Packard Journal, Aug. 86, has a
good article on the processor's architecture.

Richard Huff

CS grad student
huff@cs.cornell.edu
Xref: sparky comp.arch:4930 comp.lang.lisp:1367
From: shafto@ils.nwu.edu (Eric Shafto)
Newsgroups: comp.arch,comp.ai
Subject: Re: Voice Recog. on Desktop
Date: 15 Apr 92 09:16:10 GMT
Organization: The Institute for the Learning Sciences

markg@pdx077 (Mark Gonzales) writes:
> In article <1992Apr15.004813.24392@nas.nasa.gov> eugene@wilbur.nas.nasa.gov (Eugene N. Miya) writes:

> Where speech recognition would be useful is in making menu selections
> when typing or drawing ("boldface", "subscript", "save", "undo",
> "rectangle", "circle", "other window" ).  Here the command set is
> small, generally unambigous, and general connected speech recognition
> is not needed.  This would allow fast typing of ornamented text,
> without stopping to fumble for the mouse every few words.

We have a professor here who uses one of the commercial Macintosh
voice-recognition menu products.  It works very poorly, and one can
hear him shouting at his computer all the time.  "Activate.  Activate!
Activate!  Activate!  Edit!  Edit!  Cut!  Cut!  Cut!"  It reminds me
of the scene in "The African Queen," where Bogart's character
confesses that he has not fixed a potentially fatal problem with the
boiler because he likes having a reason to kick it when it starts to
malfunction. 

I imagine that speech recognition of this simple sort will improve.
It's a pity.  He'll probably go back to yelling at grad students.

-- 
*Eric Shafto             * Sometimes, I think we are alone.  Sometimes I  *
*Institute for the       * think we are not.  In either case, the thought *
*    Learning Sciences   * is quite staggering.                           *
*Northwestern University *     -- R. Buckminster Fuller                   *
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.arch
Subject: Re: Ideas for new LISP Machines
Date: 11 Apr 1992 21:52:21 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: telecaster.think.com

In article <Apr.11.06.57.22.1992.8365@brushfire.rutgers.edu> gaynor@brushfire.rutgers.edu (Silver) writes:
>leinen> 000 and 100 are the resp. typecodes for "even fixnum" and "odd fixnum"
>What is the advantage over having a single nixfum tag?  Seems wasteful to this
>amateur.

In this case, the typecode serves double duty.  The high-order bits of the
fixnum typecodes are also the low-order bits of the value.  Since fixnums
are used extremely heavily, and it's always important to make them as large
as possible, it's worth wasting a type code in order to provide an extra
fixnum bit.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
From: linley@hpcuhe.cup.hp.com (Linley Gwennap)
Date: Fri, 10 Apr 1992 21:11:34 GMT
Subject: Re: Who will have the next killer micro?
Organization: Hewlett Packard, Cupertino
Newsgroups: comp.arch

(Gary Tarolli) writes:
> The 500 MB/sec is for one RAMbus chip, a workstation would probably
> use 4-8 of these to get 32-64 bits per access.  Thus the total bandwidth
> would be 2-4 GB/sec for a rating of 60-120 MFLOPS using 15 Mflops from
> above or 80-160 MFLOPS using the 20 Mflops from above.  This is quite a
> leap from todays workstations.
----------

Today's HP 730 workstation achieves 66 MFLOPS peak, and systems using the
PA7100 chip will ship this year providing 200 MFLOPS peak.  DEC also
claims the same peak MFLOPS for their Alpha chip.

Peak MFLOPS may not be an important number, but remember that the
500 MB/sec for RAMBUS is also a peak number.  The thing that would
kill the performance of a CPU using only a RAMBUS cache is the delay
while waiting for the first word of data.  

---------------------------------------------------------------------------
DISCLAIMER:  The views expressed here do not		Linley Gwennap
represent the views of the Hewlett-Packard		PA-RISC Marketing
Company.  Caveat emptor.				Hewlett-Packard
From: jfc@athena.mit.edu (John F Carr)
Newsgroups: comp.arch
Subject: Re: Condition Codes and RISC arch.
Date: 6 Apr 92 22:11:31 GMT
Article-I.D.: athena.1992Apr6.221131.13232
Distribution: comp
Organization: Massachusetts Institute of Technology

>Is there any processor that has a general 'set condition codes' bit
>in each instruction ?

Most RS/6000 instructions have such a bit.  The ones that don't are
branch instructions (which use the bit for branch-and-link instead)
and instructions with a 16 bit constant field (most or all of these
have alternate opcodes which set the condition code register).

--
    John Carr (jfc@athena.mit.edu)
Newsgroups: comp.arch
From: mo@gizmo.bellcore.com (Michael O'Dell)
Subject: Meaningless performance numbers: I propose DogMIPS
Keywords: 
 
Reply-To: mo@bellcore.com (Michael O'Dell)
Organization: Center for Chaotic Repeatabilty
Date: Thu, 16 Apr 92 02:11:56 GMT

YUP - everyone multiples their favorite best number by 7.
This way the salesdroids get a shiny new BIG number,
and the technical guys all know that if you divide be 7,
it's the same ol' number we usually fight over.

	-Mike O'Dell

Bellcore??? Bellcore isn't allowed to have opinions.  These are mine.

PS - sorry John - I've held this back a long time.
Newsgroups: comp.arch
From: solman@athena.mit.edu (Jason W Solinsky)
Subject: Re: And now for something completely different...
Organization: Massachusetts Institute of Technology
Date: Wed, 8 Apr 1992 04:28:23 GMT

In article <1992Apr7.203735.9015@nic.unh.edu>, tch@kepler.unh.edu (Travis C Hayes) writes:
|> I am only a dabbler in processor architecture, etc., but it just occurred to
|> me today that some of the things we take for granted in ALU design may not
|> be the best/fastest solutions.
|> 
|> Example: hardware multipliers (not that microcoded designs probably ever use
|> hardware multipliers).
|> 
|> The traditional shift/add and shift/subtract (for division) method seems to
|> be somewhat of a time waster. Could it possibly be enhanced by adding some
|> extra hardware to detect when the desired result has been achieved and thus
|> avoid shifting and bit testing all the remaining high-order bits (which would
|> all be zero anyway after the result was achieved)? Since in many multiplies
|> one of the numbers is likely to be small (bits near the msb end not set)
|> this idea would seem to save some time. Any ideas? Do any architectures do
|> this?

The problem here is that you usually have to plan for worst case time. There are
two ways I see around this: 1) Create different instructions for multiplying
different numbers of zeros. 2) Use an asynchronus architecture that emits a signal
when the opperation is done, so you know to go onto the next one. Both have their
problems.

Jason W. Solinsky