HDTenEightyP/NetNews huggingface dataset:
From: fisher@highd.enet.dec.com
Newsgroups: comp.arch,alt.folklore.computers,comp.benchmarks
Subject: Re: dinosaur horsepower (now cascading into bad puns)
Date: 29 Jul 92 14:15:18 GMT
Organization: Digital Equipment Corporation

In article <Bs5ME8.1p2@news.larc.nasa.gov>, kludge@grissom.larc.nasa.gov ( Scott Dorsey) writes:
> In article <Bs5L03.3tH@exnet.co.uk> dhd@exnet.co.uk (Damon) writes:
>>In article <1992Jul28.155852.23608@sctc.com> smith@sctc.com (Rick Smith) writes:
>>>I was a fan of papertape myself. (5 points: can you spot the pun?)
>>
>>No, but I'm sure I'll burst out laughing when you list out the hole joke.
> 
> What an uncultured chad.
> --scott

Having to use an ASR33 during high school you could say that I learned to roll
my own!

-- 
-----------------------------------------------------------------------------
Lawrence Fisher                      Realtime Software Specialist
Fisher@HIGHD.ENET.DEC.COM            Digital Equipment Corporation
                                     Ridgecrest, CA
*   This message reflects my own views/opinions, not those of my company    *
-----------------------------------------------------------------------------
From: vhs@darkcube.radig.de (Volker Herminghaus-Shirai)
Newsgroups: comp.arch
Subject: Re: Productivity != SPECmarks, crap-compatibility - what for? (Was: Re: What's in a name?)
Date: 22 Jul 92 16:35:06 GMT
Reply-To: vhs@darkcube.radig.de

In article <1992Jul20.050025.13456@ntuix.ntu.ac.sg> eoahmad@ntuix.ntu.ac.sg  
(Othman Ahmad) writes:
> In article <1325@pacsoft.com> mike@pacsoft.com (Mike Stefanik) writes:
> 
> Bitnet Email: eoahmad@ntuvax.bitnet
> : : I think that quite obviously, the first form of compatibility is  
ridiculous
> : : (and somehow reminds me of the ridiculous algorithms often used on DOS  
boxes),
> : : compared to the latter.
> : 
> : UNIX boxes are "software compatable"?  I think not. 
> : 
> : : If I had intel inside(tm), I'd throw up...
> : 
> : I guess that your signature pretty much sums up your bias.  Don't get me
> : wrong: I am a die-hard UNIX fan, but I don't live with my head in the sand.
> : There are things to be learned on both sides of the fence.
> 
> Bravo! I support you!
> Customers are always right! Sometimes I just shake my heads! I am the  
minority
> after all.

Think again, please. Think about wars. Are wars good or bad? Of course
they're *good*, otherwise millions of people wouldn't lead them, right?
Wrong! People lead wars because other people, people whom they trust, or
whom they fear, tell them to.
People also trust (or fear) big vendors. Big vendors tell people to buy  
compatible hard/software so these vondors can keep their market share.
Because people are too lazy to think for themselves, they believe and buy.
That's what I said. That's what I meant. 

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

If I had intel inside(tm), I'd throw up...
Newsgroups: comp.arch
From: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Subject: Re: Finding which bit set in a bit-string.
Keywords: Bit-counting.
Reply-To: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Organization: Snake Island Research Inc, Toronto
Date: Thu, 30 Jul 92 06:09:23 GMT

In article <1992Jul28.160158.23842@crd.ge.com> davidsen@crd.ge.com (bill davidsen) writes:
>In article <1992Jul27.212607.26361@infonode.ingr.com>, aaronb@suhana.analog.ingr.com (Aaron B.) writes:
>
>| I posted this on "comp.compression":
>| 
>| >Given a bit-string of any size print out the bits set starting with the
>| >least significant bit.

I presume you mean the indices of the bits set. Otherwise, you'd end up
with:
   1 1 1 1 1 1  1 1...
>
>  Doing it in C, you don't want a bit by bit test, you want a branch
>table. A byte is too slow with a switch, so use a procedure vector:

Well, actually, you shouldn't even have to branch. Index an
appropriate byte-wide (2/4 etc depending on storage available) table,
and print all bits in the byte at once.

Of course, in J, you'd do this as:
    X/i. #X

That is: #x is the shape of x; ie the number of elements in x.
        i. #x is the integers from 0 through the shape of x.
            That is, if x =. 0 1 1 0 1 1 1 0 1 1 0 0 0 0 1,
            then #x is 15.
        x/y is "replicate", or "copy". That is, make x[i] copies of
             y[i]    


So, 1 0 2 3 5 / 'abcde' gives: accdddeeeee.

By the above, x/i.#x gives the indices of all 1's in x. If there are none,
the result is an empty array, of course.




Robert Bernecky      rbe@yrloc.ipsa.reuter.com  bernecky@itrchq.itrc.on.ca 
Snake Island Research Inc  (416) 368-6944   FAX: (416) 360-4694 
18 Fifth Street, Ward's Island
Toronto, Ontario M5J 2B9 
Canada
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 02:40:48 GMT

In article <Bs4ns4.D7v@world.std.com> dpbsmith@world.std.com (Daniel P. B. Smith) writes:
>Along the same lines, I, for one, would certainly pay good money for a
>recording of dinosaur NOISES.

>The sound of a LINC being slowly reved up through four decades of
>   auto-step speeds.

Any LINC-8 or PDP-12 can do this.

>The rusty-door noises of a LINC reading LINC-tape with the volume
>   control up

Any LINC-8 can do this.

MY nominations include the unique sounds of PDP-12 LAP6-DIAL's MAGSPY and
LINC-8's SUDSY.

cjl
From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879)
Newsgroups: comp.arch
Subject: Re: Cache Coherence
Date: 23 Jul 92 16:31:50 GMT

From article <1992Jul23.140423@riese.informatik.uni-frankfurt.de>,
by feivel@riese.informatik.uni-frankfurt.de (Christine Gross):
> 
> Can anybody give me information about caches and methods to get cache
> coherence ?

Plenty has been written, but here's an outline of the basic snoopy cache
protocol:

Consider a memory bus with two or more processors plugged into it.  Each
processor has a local write-through cache.  This leads to incoherency.
To fix the problem, additional logic is added to "snoop" on the bus.  This
logic listens to all write transitions from other bus clients, and if it
detects a write to word X in memory, it invalidates any copy of word
X in the local cache.

Now, consider what happens when the following code executes on two
processors on this machine:

    Process A                Process B

     repeat                   stuff
       stuff                  flag = 1
     until flag = 1

If the flag is initially 0 and neither process has a cached copy of the
flag, and if Process A starts polling the flag before process B finishes
doing other stuff, then process A will use one bus cycle to get a copy
of the flag into its local cache, and then all further polling of flag
will involve no more bus cycles until some process changes the value
of flag.  At that point, only one bus cycle is needed for Process A to
find the new value.

Thus, with this simple snooping cache protocol, busy waiting for a
variable to change its value does not create memory contention.

Commercial shared memory machines such as those made by Encore generally
seem to have more interesting protocols than that described here, but
they all seem to follow this spirit.
					Doug Jones
					jones@cs.uiowa.edu
more int
Newsgroups: comp.arch
From: peter@ferranti.com (Peter da Silva)
Subject: Re: CISC Microcode (was Re: RISC Mainframe)
Organization: Xenix Support, FICC
Date: Fri, 24 Jul 1992 13:53:02 GMT

In article <54638@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
> >		1) The compilers can't figure out how to use them often.

> We keep hearing that compilers can do as well as humans.

They do, but not in the same way. Similarly there are optimisations compilers
will use that humans can't.

> >	or	2) Most realistic code doesn't lend itself to the mode.

> What is realistic code?  I will code differently if there is hardware
> auto-increment for addresses.

I won't.

> I expect any good programmer to do as well;

I expect any good programmer to code for the abstract machine defined for
the language. Remember, software longa, hardware brevis.

> I am not a professional programmer.

We know.
-- 
Peter da Silva                                               `-_-'
$ EDIT/TECO LOVE                                              'U` 
%TECO-W-OLDJOKE Not war?                        Have you hugged your wolf today?
Ferranti Intl. Ctls. Corp.      Sugar Land, TX  77487-5012       +1 713 274 5180
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Newsgroups: comp.arch
Subject: Re: CISC Microcode (was Re: RISC Mainframe)
Date: 26 Jul 92 15:51:35 GMT
Organization: Purdue University Statistics Department

In article <id.YGRR.V_5@ferranti.com> peter@ferranti.com (Peter da Silva) writes:
>In article <54638@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
>> >		1) The compilers can't figure out how to use them often.

>> We keep hearing that compilers can do as well as humans.

>They do, but not in the same way. Similarly there are optimisations compilers
>will use that humans can't.

If an optimization involves extensive calculation, a superfast sub-imbecile
can do it better than a human.

>> >	or	2) Most realistic code doesn't lend itself to the mode.

>> What is realistic code?  I will code differently if there is hardware
>> auto-increment for addresses.

>I won't.

Why not?  Because this would involve using an optimization not in the
usual set?  This is the vicious cycle which has removed many useful and
cheap instructions even from present computers.

>> I expect any good programmer to do as well;

>I expect any good programmer to code for the abstract machine defined for
>the language. Remember, software longa, hardware brevis.

This might be reasonable if we had a language produced by people who have
some respect for the capabilities of humans.  An analogy to the present
programming languages would be a car-controller in which one could feed
in a destination, but would not allow manual control.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@pop.stat.purdue.edu (Internet, bitnet)  
{purdue,pur-ee}!pop.stat!hrubin(UUCP)
Xref: sparky comp.arch:8221 comp.misc:2969 talk.bizarre:22972 alt.religion.computers:448
From: mathew <mathew@mantis.co.uk>
Newsgroups: comp.arch,comp.misc,talk.bizarre,alt.religion.computers
Subject: Re: net.views question -- obsolete desktops
Date: Thu, 23 Jul 92 14:26:15 BST
Followup-To: alt.religion.computers
Distribution: world
Organization: Mantis Consultants, Cambridge. UK.

wagner@utoday.com (Mitch Wagner) writes:
>           What are some things you can do with an obsolete
>           desktop system?

You can run MS-DOS, Windows or OS/2 on it.


mathew
-- 
Ceci | n'est pas une pipe.
From: mash@mips.com (John Mashey)
Newsgroups: comp.arch
Subject: Re: More P5 Speculation...
Date: 23 Jul 1992 18:03:40 GMT
Organization: MIPS Computer Systems, Inc.
Distribution: usa
NNTP-Posting-Host: winchester.mips.com

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 
Easy, I got one of those special newspaper subscriptions that
delivers tomorrow's paper today :-)
>referring everyone to the cover of the July 6 issue of EE Times.

>On the cover there's a block diagram of the P5.  It has the expected
>units: I and D caches, bus, FP and SScalar RISC CPU.  But there's one
>I don't quite follow: Intel386 unit.  Does this mean that the P5 will
>be running some kind of emulation of x86 instructions?  Is there a
>"native" RISC instruction set that differs from the x86 instruction
>set?
Well, there are two obvious possibilities:
1) The microcode for the stuff that is difficult to hardwire,
just as some S/370 models have had.
2) A "decoded instruction cache", i.e., where you fetch instructions,
decode them into some more-easily-executed form [perhaps akin to
RISC instructions, or perhaps more likely, into more horizontal
microcode-like things], and then use the result to control the
execution units.
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	 mash@mips.com [soon to be mash@sgi.com, but not quite moved yet].
DDD:  	408-524-7015,  or 524-8253
USPS:	(soon) Silicon Graphics, 2011 N. Shoreline Blvd, Mountain View, CA 94043
From: magnus@THEP.LU.SE (Magnus Olsson)
Newsgroups: comp.arch
Subject: Re: Proposal: Computer History Project
Date: 30 Jul 92 11:55:53 GMT
Organization: Theoretical Physics, Lund University, Sweden

In article <1992Jul29.015101.7523@SSD.intel.com> prp@SSD.intel.com writes:

>Other projects I am aware of include emulators for the IBM 1401, 1410, and 650.
>There are Z80 and IBM/370 simulators (which include OS simulation) for the PC.
>And of course there are several PDP-8 simulators.

Also, don't forget Lars Gislen's (larsg@thep.lu.se) excellent Macintosh
emulation of SMIL - one of the first Swedish computers, a vacuum-tube
beast. The emulator emulates not only the CPU, but also the front panel
with all its switches and blinkenlights. Programs are entered via
(simulated) punched tape. It's freeware, available via anonymous FTP
from the info-mac archives at sumex-aim.stanford.edu, or from
leif.thep.lu.se [130.235.92.55].

There's also the Warwick University emulation of EDSAC, one of the very
first stored-program machines in the world. But that's a commercial
product.

-- 
Magnus Olsson                   | \e+      /_
Dept. of Theoretical Physics    |  \  Z   / q
University of Lund, Sweden      |   >----<           
Internet: magnus@thep.lu.se     |  /      \===== g
Bitnet: THEPMO@SELDC52          | /e-      \q
From: wolfgang@sunspot.nosc.mil (Lewis E. Wolfgang)
Newsgroups: comp.arch
Subject: Call for Opinion: Viking or i860
Date: 30 Jul 92 23:53:36 GMT
Originator: wolfgang@sunspot

Call for opinion:

	We run large acoustic modeling programs on a
variety of Sun Sparc systems and in the past have
considered purchasing array processors to hasten things
along.  It seems as if many array processors are based
on Intel's i660 chip, certainly a respectable 
numerical masticator, but how does it stack up against
current RISC based CPUs?

	We have a Sun 690MP that we could upgrade to
SuperSparc (Viking) with SuperCache for not much more
money than an equal number of i860 based processors.  
It seems as if integer performance is better with Sparc,
with floating point not quite as good.  An advantage of
a Sparc upgrade is that old code would not have to be
modified, at a cost of slightly less relative floating 
point performance.

	What do you think?  Upgrade the cpu with Viking?
Or purchase an equal number of i860 based array processors?

				Thanks,
				Lew Wolfgang
				wolfgang@nosc.mil
Newsgroups: comp.arch,alt.folklore.computers,comp.benchmarks
From: dpbsmith@world.std.com (Daniel P. B. Smith)
Subject: Dinosaur noises (was: Re: dinosaur horsepower)
Organization: The World Public Access UNIX, Brookline, MA
Date: Wed, 29 Jul 1992 01:50:24 GMT

Along the same lines, I, for one, would certainly pay good money for a
recording of dinosaur NOISES.
The waltz-time 407 (kchunk-Pink kchunk-Pink glup kchunk-Pink kchunk-Pink glup)
The PDP-1 paper tape reader (slip slup slip slup slip slup)
The sound of a LINC being slowly reved up through four decades of
   auto-step speeds.
The rusty-door noises of a LINC reading LINC-tape with the volume
   control up
The subtly different beeps of various machines (BTW, the Windows 3.1 beep
   is noticeably different from the Windows 3.0 beep, at least on a
   PS/2-40SX).  
The original Mac department-store chime.
Flexowriters! 
Card sorters!
etc. etc.

Oh, and on side 2 (say, I can be archaic when I want to be), how about
great video-game classic sounds of the past? The menacing Urgh Urgh Urgh
of Space Invaders...
--Daniel P. B. Smith
dpbsmith@world.std.com
From: doconnor@sedona.intel.com (Dennis O'Connor)
Newsgroups: comp.arch
Subject: Re: CISC Microcode (was Re: RISC Mainframe)
Date: 23 Jul 92 21:17:20 GMT
	<ADAMS.92Jul21011202@PDV2.pdv2.fmr.maschinenbau.th-darmstadt.de>
	<Brsx7o.G69@zoo.toronto.edu> <2369@nic.cerf.net>
Organization: Intel i960(tm) Architecture
In-reply-to: davsmith@nic.cerf.net's message of 22 Jul 92 22:49:41 GMT


davsmith@nic.cerf.net (David Smith) writes:
] All CPUs I have seen to date (not every CPU by any means - if you know
] of counter examples, please post) cannot do asynchronous address
] generation.  When they request a word of memory they want it *NOW* or
] within a cycle or two and will block until it arrives.

In the micrprocessor arena, two of the Intel i960(R) families
military parts, the MM and MX, do support this. They use a split
transaction bus that can have some number ( 4 ? ) of outstanding
transactions active at any one time. But I think the motivation
for doing this was shared-memory multi-processor architectures.
--
Dennis O'Connor			doconnor@sedona.intel.com
From: john@theus.rain.com (John Theus)
Newsgroups: comp.arch
Subject: Re: what is a non-split transaction bus called?
Date: 29 Jul 92 07:44:59 GMT
Distribution: na
Organization: The Theus Group; Sherwood, OR

In article <dbg-270792201001@kinetics.slac.stanford.edu> dbg@slacvm.slac.stanford.edu (David Gustavson) writes:
>The IEEE standards seem to be adopting "unified transactions" for those
>that are not split, at least in an environment that permits both kinds.
>
Dave should have said that some IEEE standards (ie p1394; any other protocol
standards?) use that phrase. The IEEE bus standards I'm involved in use
"connected transaction".

Terminology as well as several other minor topics continue to be areas for
major turf battles between different sponsors within the IEEE -- in this case
the MSC (Microprocessor Standards Committee) vs. the BASC (Bus Architecture
Standards Committee).

John Theus     TheUs Group     +1 503 625 7387     john@theus.rain.com
Newsgroups: comp.arch
From: dhd@exnet.co.uk (Damon)
Subject: Re: What's in a name?
Organization: ExNet Systems Ltd Public Access News, London, UK
Date: Sun, 26 Jul 1992 20:57:39 GMT

In article <GLEW.92Jul23225243@pdx007.intel.com> glew@pdx007.intel.com (Andy Glew) writes:
>> |> 1)  Backwards compatability is a waste of everyones time.
>> >
>> > Fortunately for the vendors, consumers disagree with that statement.
>> > In millions.
>> 
>> You're right. Fortunately *for the vendors*.
>
>
>12 years ago, my dream was to build cheap high performance RISC
>processors that brought really high performance computing power to the
>masses. My parents (non-computer nerds) in particular.
>
>Through all of those years, there was never built a cheap high
>performance computer system using a RISC that my parents would want to
>use.  (Sure, I know about the BBC Micro - I mean *use*, not play
>with.) All of the RISC companies concentrated on high margin
>workstations that only companies and universities could purchase.

Now steady on!  Both my parents use BBC micros to write.  My father and mother
have brought in a substantial portion of their income from books/scripts
written in VIEW (and that won't even each all fit on one disc).  My father has
*only just* bought an x86 portable.  Both *still* use the BBC Micros.  Not
everyone thinks using a computer is doing intensive floating-point arith on
nnnMB files.  I'm trying to pursade my mother to upgrade to a *Sun-3/50*; she
remains unconvinced she needs the extra power.  I'm using an 8088 in my palmtop
and a 680?0 in my Sun-3/60 I write at now.

So the current and previous generation of RISC is *streets* ahead of what any
of us use to make our living day by day.  (BTW our family and businesses
between us own and use 4 BBC Micro variants + Acorn Electron, many (>6?) PC
clones, several Suns, plus now-unused things like MZ-80Ks, etc.  RISC/CISC
about 1:1, nearly all about 5 years or more behind the bleeding edge.)

Damon
-- 
Damon Hart-Davis | Tel/Fax: +44 81 755 0077 |1.21|| ALL MAIL FREE.
Internet: dhd@exnet.co.uk | Also: Damon@ed.ac.uk || Hotrod motor groups soon.
--------------------------+----------------------++ >12 mail&news polls / day.
Public access UNIX (Suns), news and mail for #5 per month.  FIRST MONTH FREE.
Newsgroups: comp.arch,alt.folklore.computers
From: Steinar.Haug@delab.sintef.no (Steinar Haug)
Subject: Re: Proposal: Computer History Project
Organization: SINTEF DELAB, Trondheim, Norway.
	<1992Jul29.161307.24081@tessi.com>
Date: 31 Jul 92 11:52:30

> However, I'm one of three PERQ collectors that are actively working to
> create a shared library of software, documentation, literature, stories, and
> other goodies, as well as maintaining the genuine hardware.  At least there
> are two others that I've found on the net - and while we're just hobbyists,
> I've heard rumors that there are people out there still doing "real" work
> with PERQs.  We'd love to hear from others that have the machines, or even
> just bits of folklore.

At SINTEF DELAB, we have a couple of PERQs stored away in our basement
computer room. They were taken out of use several years ago, and are now
basically just gathering dust...

Steinar Haug, system/networks administrator
SINTEF DELAB, University of Trondheim, NORWAY
Email: Steinar.Haug@delab.sintef.no, 
	sthaug@idt.unit.no, steinar@tosca.er.sintef.no
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.arch
Subject: Re: Productivity != SPECmarks, crap-compatibility - what for? (Was: Re: What's in a name?)
Date: 23 Jul 92 18:54:29 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <1992Jul22.163506.306@darkcube.radig.de>, vhs@darkcube.radig.de (Volker Herminghaus-Shirai) writes:

| People also trust (or fear) big vendors. Big vendors tell people to buy  
| compatible hard/software so these vondors can keep their market share.
| Because people are too lazy to think for themselves, they believe and buy.
| That's what I said. That's what I meant. 

  People buy machines to run software, and in business cases that's
about the only reason. If the software runs on a MIPS you buys MIPS, if
you need a Mac you buy it. If you can get the same package for MS-DOS
for $500 and HP700 for $5000 you buy MS-DOS. The cost of the hardware is
swamped by the cost of the software. And changing architectures vs.
faster versions of what you have adds the cost of new software and
training to the initial cost of the machine.
-- 
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.
Newsgroups: comp.arch