HDTenEightyP/NetNews huggingface dataset:
From: pcg@aber.ac.uk (Piercarlo Grandi)
Newsgroups: comp.editors
Subject: Re: Undo, unlimited file size and internal data structure ... how ?
Date: 27 Jul 92 20:56:30 GMT
Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
Organization: Coleg Prifysgol Cymru

On 22 Jul 92 00:32:26 GMT, nmouawad@waterloo.edu (Naji Mouawad) said:

nmouawad> Two features of Emacs amazes me: unlimited file size and undo.

An approximate but fairly close description for GNU Emacs is:

The entire file is kept in memory as a malloc(3)'ed *string*.

When you insert, the right part of the string is shifted righwards.

To avoid having to do this for every character inserted, the right part
of the string is shifted by a some thousand bytes, not by just one byte.

This creates a gap/bubble in the middle of the string, which is "moved"
whenever the insertion point changes. When the gap is exhausted, the
string is realloc(3)'ed to a larger size.

Undo information is kept as a stream of string updates.

The above structure is called 'buffer gap method'.

nmouawad> The same goes with unlimited file sizes.

Actually GNU Emacs does *not* support unlimited file sizes, it supports
more or less unlimited _line_ sizes. Since it uses some bits in each
pointer for tagging, usually the maximum string (and thus file) size for
GNU Emacs is far smaller than the total address space, maybe as low as 8MB.

nmouawad> What kink of internal representation is being used by Emacs in
nmouawad> order to keep a fast response while managing big files ?

The response is only fast if you have a very fast CPU and real memory is
larger than the file size. Shifting around things is very bad for CPU
efficiency and especially for paging efficiency.
--
Piercarlo Grandi                   | ARPA: pcg%uk.ac.aber@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk
From: david@cats.ucsc.edu (David Wright)
Newsgroups: comp.editors
Subject: remapping o and O
Date: 31 Jul 92 19:34:52 GMT
Organization: University of California; Santa Cruz
NNTP-Posting-Host: mingong-ws-2.ucsc.edu



I would like to remap o and O in vi on a Unix SunOs 4.0. I would like to
remain in escape mode and not enter insert mode. When I am in the editor, 
I can give a command like:

:map o $a

(with the appropriate 's; before each control character)

Which does the job fine. However, I can`t seem to write it into my .exrc 
file. Any suggestions?
-- 
   |^^^^^^|      _______________________________________________________
   |      |      |"There is nothing in the marginal conditions that    | 
   |      |      | distinguish a mountain from a mole hill"            |
   | (o)(o)      O         Kenneth Boulding                            | 
   @      _)    o|_____________________________________________________|  
    |  ____\ o o
    |     /   
   /     \                              All comments  are mine---(David Wright) 
Newsgroups: comp.editors
From: wolff@inf.fu-berlin.de (Thomas Wolff)
Subject: Re: Undoing
Organization: Free University of Berlin, Germany
Date: Fri, 31 Jul 1992 17:03:38 GMT

Stepwise total undoing is also implemented by the built-in system editor 
of the "Display Manager" (best window system I've seen) of Apollo's DOMAIN/OS 
operating system (best operating system I've seen, unfortunately being 
conquered by Unix after HP bought Apollo).

Thomas Wolff
wolff@inf.fu-berlin.de
Organization: Doctoral student, Engineering and Public Policy, Carnegie Mellon, Pittsburgh, PA
Newsgroups: comp.editors
Date: Fri, 24 Jul 1992 14:42:51 -0400 
From: "Marek J. Druzdzel" <md33+@andrew.cmu.edu>
Subject: Re: ?Emacs and VI for MS-DOS?

A list of all known implementations of Emacs (and a subsequent
discussion) followed my original posting, so this cut-and-paste
summary contains only information on VI implementations for
MS-DOS.

-------------------------------------------------------
There are zillions of versions of vi for DOS.  You will find at least 2
or three on the anonymous ftp server wuarchive.wustl.edu
(128.252.135.4), the better known being stevie and elvis.  They are
reasonable, but now as complete as the "real" vi.  Probably the MKS
version (about $250 for the complete MKS tools) is the closest to the
original.  Those who like vi, praised it.
-------------------------------------------------------
As of version 3.21, vile will compile and run on DOS.  
ftp from ftp.cayman.com:pub/vile
-------------------------------------------------------
Elvis is one of the vi clones I have been using for a while.  It is
also available on simtel20 in /msdos/editor (or something like that)
-------------------------------------------------------
I have heard of emacs being compiled with DJGPP (Delorie's
port of GNU CC) on MSDOS.  Also, there's GNU elvis and something
called Stevie, which are vi clones.  Commerically, there's
Mortice Kern Systems vi.
-------------------------------------------------------

Thanks (all respondents to my query, so not only
those quoted above) go to:

  messina@netcom.com (Tony Porczyk)
  pgf@Cayman.COM (Paul Fox)
  Craig Durland <craig@hpcvxkm.cv.hp.com>
  kyw7468@tamuts.tamu.edu (Clement Ka-yiu Wong)
  hayes@valkris.aero.org (Brian Hayes 74-35 x65129)
  timlee@btr.com (Timothy J. Lee  timlee@btr.com)

I downloaded ELVIS and I'm so far happy with it.
Thanks again,

Marek
Newsgroups: comp.internet.library
From: takefuji@donald.EEAP.CWRU.Edu (Yoshiyasu Takefuji)
Subject: letters.7-24-92
Organization: Dept. of Electrical Engineering, CWRU, Cleve. OH
Date: Fri, 24 Jul 92 00:27:00 GMT

From news@murdoch.acc.Virginia.EDU Thu Jul 23 12:59:42 1992
From: news@murdoch.acc.Virginia.EDU
Subject: Re: letters.7-23-92


  I am well aware that BIP is copyrighted and that availability on the
Internet was an unlikely possibility.  I am also aware that Dialog
carries the BIP for a price only libraries could afford anyway, which
would make it just as easy to go to the library and look in the
hard-bound volumes, unless one could convince the library to add it to
their dial-in service, given the student's social security number for
access.
  What my request really regarded was the existence of publishers
and/or bookstores on the Internet.  I have been told Stanford
University's bookstore is on the net, as is a Canadian distributor
(DOBIS?).  If anyone else can provide similar services, please post
them.  They will probably do one just as much good as BIP would anyway.

Doug Lamb
University of Virginia
dtl8v@Virginia.EDU
Newsgroups: comp.internet.library
From: takefuji@donald.EEAP.CWRU.Edu (Yoshiyasu Takefuji)
Subject: letters.7-23-92
Organization: CWRU/Keio University
Date: Thu, 23 Jul 92 00:44:47 GMT

From news@u.washington.edu Wed Jul 22 16:52:46 1992
From: tdowling@lib.washington.edu (Thomas Dowling)
Subject: Re: letters.7-20-92


>   I appreciate your Internet libraries newsgroup a great deal.  I was
> wondering, however, if there is an on-line Books In Print anywhere.
> Despite DRA.COM's admirable Library of Congress index, it has neither
> all books currently in print (as categorized by ISBN, that is, being
> various versions of the same book, such as paperback availability) nor
> the current price etc.  Is there any way to obtain this information,
> short of finding an Internet library with some of this information
> stored in it for a particular book?

This has become something of a FAQ, so apologies to those who have seen this 
answer before.

BIP (and CARL Uncover, the IEEE database, etc.) is a commercial database 
whose producer depends on it to make money.  Providing it anywhere for free 
would tend to discourage anyone from paying for it through other channels.  
If you were to find free access to it, you would know that someone had 
already paid for your access; when that person finds out about this, he or 
she will most likely turn that access off.

So, if you really want to search Books in Print via the Internet, my suggestion
is to get an account from Dialog Information Services (1-800-3-DIALOG in the 
U.S.), telnet to dialog.com, and search BIP from there.

On the other hand, if you want a free listing of new books, Stanford's 
bookstore has their holdings in the Stanford catalog.  Telnet to 
forsythetn.stanford.edu,
 use the account "socrates", and issue the command "select bookstore".

>
> Doug Lamb
> Center for Semicustom Integrated Systems
> University of Virginia
> dtl8v@Virginia.EDU

|Thomas Dowling                    |          tdowling@u.washington.edu|
|Engineering Library               |                     (206) 543-0741|
|University of Washington FH-15    |                Seattle, WA   98195|
From: chen-m@acsu.buffalo.edu (Mingteh Michael Chen)
Newsgroups: comp.arch
Subject: burst mode
Date: 30 Jul 92 19:32:07 GMT
Organization: UB

Dear Netters:
     I am a novice in the group, so please bear with me if I am wrong. 8-)

My question is : 

What is the burst mode of the Micro channel architecture?
and what makes it to be superior than other approaches? (maybe DMA?) 
I have some vague idea that it transfers a whole memory "block"
instead of a memory word individually. But as long as the bus bandwidth is
fixed, each memory "word" still needs to be transferred sequentially...


     Thank you very much for any comments or directions!

Regards,

-- 
Mingteh Chen
State Univ. of New York at Buffalo,
Dept. of Electrical & Computer Engineering
INTERNET: chen-m@acsu.buffalo.edu
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.arch
Subject: Re: Request Info Re Bus Trends & Intel 486s
Keywords: Intel 486 Bus
Date: 28 Jul 92 15:23:31 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <1992Jul27.013814.25878@metapro.DIALix.oz.au>, bernie@metapro.DIALix.oz.au (Bernd Felsche) writes:

| >world, they're available (under the ugly name "passive motherboard"), and until
| 
| Yes, you can now get a PC on a card to plug into a
| backplane, but only because the technology is now available
| and reasonably cheap.

  Sort of... many of these "passive motherboards" do have the interrupt
controller and DMA on them, and clock, and CMOS, and other stuff. Only
the CPU is on a board. This is not the way we did it with S-100.
-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
	It never ceases to amaze me that otherwise rational people, able to
	understand calculus, compound interest, and the income tax form, can
	continue to believe that poker is a game of chance.
From: daryl@hpcuhe.cup.hp.com (Daryl Odnert)
Date: Thu, 23 Jul 1992 00:29:29 GMT
Subject: Re: Code Repositioning on MIPS Systems?
Organization: Hewlett Packard, Cupertino
Newsgroups: comp.arch

According to the information I've been sent via e-mail, MIPS has a
postprocessor tool called "cord" which can reposition the procedures
within an executable file so that run time cache conflicts will
be reduced.  The positioning is guided by information in "feedback
files" which are generated by the "prof" command with the -feedback
option.

Does anyone know of any existing tools or planned enhancements to cord
that will reposition the basic blocks of code within procedures so that
taken conditional branches are reduced?  Is anyone aware of any tools
or compilers that perform this optimization on ANY existing architecture?

Daryl Odnert     daryl@cup.hp.com
Hewlett-Packard
Cupertino, California

Newsgroups: comp.arch
From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Subject: Re: dinosaur horsepower
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University
Date: Wed, 29 Jul 1992 00:30:32 GMT

In article <13307@ns-mx.uiowa.edu> jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) writes:

>The DEC PDP-8, in 1965, had a 1.5us memory cycle time, so it took 3 us to
>do a single 12 bit memory to accumulator add (1.5us for the instruction
>fetch and 1.5us for the operand fetch and add).  You could say that this
>was a 1/3 MIP machine, but if you want any precision, you'll have to do an
>extended precision add.  A memory to memory 24 bit add on this machine
>takes 7 instructions.  A similar 36 bit add takes at least 11
>instructions.
>
>The PDP-8 was a second generation machine (transistorized, discrete
>components, core memory).  The maximum memory capacity of the architecture
>was 32K 12 bit words.  Although it was a small inexpensive system,
>by the standards of its day, the speed of the logic was very typical of
>the times.

As some people say, MIPS is Meaningless Instructions Per Second, so that's not
a fair comparison.  The PDP-8 can do 512 different operate instructions in only
one cycle each.  Most of them are meaningful, not just a NOP, such as:
SMA SZA CLA which is skip the next instruction if the Accumulator is currently
negative or zero and then clear the accumulator.  All of this in 1 cycle of
1.5 microseconds, so therefore it's 2/3 MIPS not 1/3 MIPS.  In terms of 1965
pre-TTL logic, this was typical timing.  Note that the I/O instruction was
stretched to take 4.5 microseconds so that 1 microsecond spaced pulses
could be generated on the bus, which could be 50 or more feet long.  In later
designs, the instructions optimized out unused pulse states so that most
instructions could shave 3 microsecods off the time.  Virtually none of them
needed all three states; a few did need two.  But the original PDP-8 and
LINC-8 didn't optimize, so all I/O instructions did take 4.5.

cjl
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.arch
Subject: Re: More P5 Speculation...
Date: 24 Jul 92 15:33:53 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Distribution: usa
Organization: GE Corporate R&D Center, Schenectady NY

In article <1992Jul23.173724.14764@pony.Ingres.COM>, thall@Ingres.COM (Trevor Hall) writes:
| According to today's San Jose Mercury News it looks like we're going to 
| get another quarter's worth of speculation on the P5 (where do you get
| your information, John Mashey?).  So I thought I'd start another round by 
| referring everyone to the cover of the July 6 issue of EE Times.

  Intel taking a page out of IBM's book. The P5 is the big stuck to keep
people from going to other vendors. What this means is that people who
intended to go with P5 for top of the line can now buy whatever systems
they want, secure that Intel can't deliver more performance in a
reasonable timeframe.

  I tend to believe the rumors of big trouble making the chip. Why else
announce a super low price to keep people interested, and then delay
introduction? Lots of business customers on a yearly budget have been
saving their money to buy 586 machines before year end. Now that they're
not coming, other machines are being scheduled instead, and Intel has
lot one year market share of the kinds of users who buy top of the line
machines.

  Maybe now we can move discussion of the P5 to comp.folklore.
-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
	It never ceases to amaze me that otherwise rational people, able to
	understand calculus, compound interest, and the income tax form, can
	continue to believe that poker is a game of chance.
From: S_JUFFA@iravcl.ira.uka.de (|S| Norbert Juffa)
Newsgroups: comp.arch
Subject: Address of Chips & Technology (C&T)?
Date: 23 Jul 1992 15:31:02 GMT
Organization: University of Karlsruhe (FRG) - Informatik Rechnerabt.
Distribution: world
NNTP-Posting-Host: irav1.ira.uka.de
X-News-Reader: VMS NEWS 1.23

Hi netters,

I am not sure that this is the appropriate newsgroup for my question, but I
had no idea which one would have been better. So here goes:

I am looking for the address (snail mail, *not* email) of Chips & Technology
in the USA. They are the manufacturers of PC chips sets and the like. Any
pointer is appreciated. Thanx in advance!

Norbert

------------------------------------------------------------------------------
Norbert Juffa      email: S_JUFFA@IRAVCL.IRA.UKA.DE         Live and let live!

Newsgroups: comp.arch,alt.folklore.computers,comp.benchmarks
From: lamaster@puma.arc.nasa.gov (Hugh LaMaster -- RCS)
Subject: Re: dinosaur horsepower
Organization: RIACS, NASA Ames Research Center
Date: Thu, 30 Jul 92 16:52:47 GMT

In article <1992Jul30.053240.20199@yrloc.ipsa.reuter.COM>, rbe@yrloc.ipsa.reuter.COM (Robert Bernecky) writes:
|> In article <Bs3oGt.6vp@helios.physics.utoronto.ca> mark@cita.toronto.edu writes:

|> >Larry Stewart's proposal regarding the computer history project prompts
|> >me to offer a suggestion for something I'd like to see:

:
:
                      Another article noted that the "supercomputer" was 
|> an IBM S/370/168. Ahah! False advertising from Big Blew strikes again!
|> 

|> I then went and looked up rough timings on said machine. Hard, because
|> the closest thing I have on hand is a System S/370 system summary
|> (GA22-7001-2)which gives the following information:
:

|> This means that the "supercomputer" which solved the 4-color problem
|> was about on a par with high-end PC's of today, IF YOU IGNORE THE
|> I/O BANDWIDTH of the system.
|> 
|> Given that the 4-color theorem was not I/O intensive, this means that 
|> today's PCs could solve the same problem in a similar timeframe, a
|> mere 20 years or so later.


According to my references, the 370/168-3 was about 2.0-2.5 
Dean-Witter-Reynolds, and/or "ComputerWorld", and/or "Electronics", "MIPS", 
which would make it about 4-5 SPEC92ints.  Just about any decent 486-based
system would be faster, let alone the current crop of RISC workstations,
which are 40-50 SPEC92ints.


However, I don't remember seeing the 370/168 line referred to as a 
"supercomputer", although I'm sure someone did.  The CDC 7600, and the
IBM 360/370/195, would have both been about 4 times faster, and had
already been out for 2-3 years by then.  The Illiac IV, CDC STAR-100, TI-ASC, 
and CDC 8600 (turned into Cray-1), in various stages of development, were
supposed to be the next generation of "supercomputers".  The mid-70's
IBM 370 systems were the archetypal "second generation mainframes".


-- 
  Hugh LaMaster, M/S 233-9,     UUCP:      ames!lamaster
  NASA Ames Research Center     Internet:  lamaster@ames.arc.nasa.gov
  Moffett Field, CA 94035-1000  Or:        lamaster@george.arc.nasa.gov 
  Phone:  415/604-1056                     #include <usenet/std_disclaimer.h> 
Newsgroups: comp.arch
From: glew@pdx007.intel.com (Andy Glew)
Subject: Re: Scheduling in Shared Memory Multiprocessor Systems
Organization: Intel Corp., Hillsboro, Oregon
	<1992Jul24.183213.9699@elroy.jpl.nasa.gov>
Date: Mon, 27 Jul 1992 04:13:16 GMT

    >Gould PN machines used a simple affinity algorithm:
    >    The run queue was divided into 32 priorities (each a single chain)
    >    - the classic BSD run queue.
    Isn't this an artifact of the Vax architecture having 32 hardware
    queues and instructions to manipulate them?  Have most BSD vendors
    kept this structure or gone with something radically different?

I wasn't aware of any limitation on VAX queues.

What was convenient, however, was keeping a bit per queue indicating
occupancy. 32 bit words.  That way simple tests against 0 and FFS
could be used to query the run queue.

At one occasion we did try > 32 queues, but the overhead wasn't worth it.

With 64 bit integers common, 64 run queues will be likely.
--

Andy Glew, glew@ichips.intel.com
Intel Corp., M/S JF1-19, 5200 NE Elam Young Pkwy, 
Hillsboro, Oregon 97124-6497

This is a private posting; it does not indicate opinions or positions
of Intel Corp.

Intel Inside (tm)
Newsgroups: comp.arch
From: vhs@darkcube.radig.de (Volker Herminghaus-Shirai)
Subject: Re: What's in a name?
Reply-To: vhs@darkcube.radig.de
Date: Sat, 25 Jul 92 12:19:52 GMT

In article <MKAHN.92Jul22092527@hopi.sedona.intel.com>  
mkahn@hopi.sedona.intel.com (Mitch Kahn) writes:
> mfrank@wilma.cs.wisc.edu (Matt Frank) writes:
> 
> 
> ] >>>There'll be a 686 all right.  It may look like the x86 architecture from  
the
> ] >>>outside, but on the inside ...
> ] [Lot's of stuff about whether the P5 is going to be performance competitive
> ] with RISC chips and whether PC-compatible owners are idiots or just  
ignorant]
> ]
> ] Backwards compatability has always been a particular pet peeve of mine, so  
I
> ] feel the need to add my two cents worth.  I have two specific problems.
> ]
> ] 1)  Backwards compatability is a waste of everyones time.
> 
> Better tell that to DEC, IBM, MIPs, Motorola etc. as well as all the users
> in the world who do not want to buy new software every time they get a
> faster box. What color is the sky in your world?

DEC, MIPS and Motorola started with a cleaner, more future-oriented design
in the first place. Of Motorola and DEC I know they also abandoned instructions
that weren't used very much, replacing them with emulation libs. This kind
of compatibility is OK, it's the 100%-stick-to-fouled-up-design-and-make-
everyone-believe-this-is-the-only-way-to-go that's not..

> ] 2) Nobody ever uses the backwards compatable features anyway.
> 
> You're right. I'm getting a new workstation this week and to celebrate
> I'm going out and buyin $10K worth of new (incompatible) software just
> because some technogeek decided incompatibility wasn't an issue. NOT

I think what the original poster meant was "Nobody uses the *new* features
anyway unless they provide a *real huge* advantage". The 286 didn't provide
any. The *real huge* advantage that's used on the 386 is to make it more
backwards-compatible (virtual 8086-mode). This would be considered silly
everywhere outside of commerce-driven PC- or IBM-world.

> ] Intel has done very well for itself making better/faster 8086's for the  
past
> ] 10+ years because they had a monopoly on chip designs that run MS-DOS.  If
> ] Win/NT is successful they will need to compete against many other chip  
makers.
> ] If Intel designs an 80686 some day, Microsoft may port Win/NT to t
> 
> Intel boxes will still be the cheapest MIPs on the planet. Who cares if
> a Crimson (or a Chartreuse) can run Windows. I'll get my P5 box for
> $5k which is about $10K cheaper than anyone else.

You get what you pay for. Really.

--
Volker Herminghaus-Shirai (vhs@darkcube.radig.de)

If I had intel inside(tm), I'd throw up...
Newsgroups: comp.arch,alt.folklore.computers,comp.benchmarks
From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Subject: Re: Dinosaur noises (was: Re: dinosaur horsepower)
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University
Date: Wed, 29 Jul 1992 17:01:29 GMT

In article <kitchel.712420361@moray> kitchel@moray.dpsi.com (Sidney W. Kitchel) writes:
>
>	Some fairly early computers came with speakers. One of these
>was the CDC 1604. Most operators kept the volume way down, but I can
>recall going into the machine room at Sunray DX Oil ca. 1965 and
>hearing the science-fiction-esque music of the CDC beast.
>

The LINC, LINC-8, and PDP-12 come with speaker and volume control standard.

The Lab-series of modules for the 8/e and -11 came with a mounted speaker
but I'm not sure of the interface officially associated there with.  (I
have one that was mounted in the lab mounting panel I got from a used
computer dealer; not enough of the other panelettes were present to
determine the original system which could have been either or perhaps
something else?  The cable for the speaker is the same connector as the
PDP-12's scope if that helps.  I think it's an Amphenol 57-series like a
Centronics 36-pin connector, only with less pins (25?).)

cjl
Newsgroups: comp.arch