HDTenEightyP/NetNews huggingface dataset:
From: henry@zoo.toronto.edu (Henry Spencer)
Subject: Re: CISC Microcode (was Re: RISC Mainframe)
Date: Thu, 23 Jul 1992 17:50:46 GMT
Organization: U of Toronto Zoology

In article <1992Jul22.163956.57436@cc.usu.edu> ivie@cc.usu.edu (CP/M lives!) writes:
>> Item 3 can still be
>> an issue, particularly on old architectures with clunky interrupt handling,
>
>What do you mean by "clunky interrupt handling"?

Many, many CPU cycles needed to get into and out of an interrupt, so it's
impossible to take very many of them or respond quickly to one.  You have
to figure in both hardware and software interrupt overhead; the relevant
metric is elapsed time between stopping mainline execution and starting
the interrupt handler *for that specific interrupt*.  Time spent figuring
out deciding who gets to handle this one, or saving and restoring registers
so he can be invoked safely, is part of the overhead regardless of whether
it's in software or hardware.

Pretty much the inescapable minimum is two pipeline breaks plus a cycle for
the "return from interrupt" instruction.  There are CPUs that approach this
for simple cases where the interrupt can be dealt with quickly (they do
typically incur somewhat more overhead if the interrupt handler wants to
run for a while and use substantial resources).
-- 
There is nothing wrong with making      | Henry Spencer @ U of Toronto Zoology
mistakes, but... make *new* ones. -D.Sim|  henry@zoo.toronto.edu  utzoo!henry
Newsgroups: comp.arch
From: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Subject: Re: CISC Microcode (was Re: RISC Mainframe)
Reply-To: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Organization: Snake Island Research Inc, Toronto
Date: Thu, 30 Jul 92 06:00:53 GMT

In article <BDS.92Jul28085651@maui.linus.mitre.org> bds@maui.linus.mitre.org (Barry D. Smith) writes:
>In article <55117@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
>
>2) What exactly is a "superfast sub-imbecile?"

Superdrooler?



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
From: sunny@unl.edu (Sunil Kumar Burra)
Newsgroups: comp.arch
Subject: Parallel Port interface Tape Backup: Request
Date: 30 Jul 92 20:09:54 GMT
Organization: University of Nebraska - Lincoln

I am planning to work on Parallel port interface for tape backup(as a project
for one of my grad course).

I didn't know where to start.

If anyone has done anything similar to this, can u help me with
the information and the references to the literature.

Any piece of information is highly appreciated.

u can mail the responses to

sunny@cse.unl.edu
Sunil K. Burra
Newsgroups: comp.arch
From: tarolli@tenno.boston.sgi.com (Gary Tarolli)
Subject: Re: CISC Microcode (was Re: RISC Mainframe)
Organization: Silicon Graphics, Inc.
Date: Fri, 24 Jul 92 18:46:36 GMT

In article <13v76qINN1ap@rodan.UU.NET>, avg@rodan.UU.NET (Vadim Antonov) writes:
|> Did anybody thought that bcopy has nothing to do with the central processor?
|> I'd prefer to have a machine which thinks of it as of a pair of DMA-s.
some people think DMA is a dirty word....

|> It makes the whole system more "consistent" from the OS point of view.
|> There is no need to pump unchanged words through all those CPU
|> data caches effectively flushing them. 
how do you then keep your data caches consistent with memory (in case some
of the bcopy's destination bytes were in the cache)?  If you flush or invalidate
your data cache, its not any different than pumping those words thru the cache.

|> The additional circuits are trivial but allow to keep the CPU simplier.
when one throws in all the non-simple complexities of alignment, direction,
and sometimes stride (used more for framebuffer operations than memory),
things become non-trivial real fast.  In fact, sometimes, they are complex
enough that its difficult to ever get DMA working correctly or more efficiently
than load/stores.
______________________________________________________________________________
  _____              ______           _  _	(508)562-4800  tarolli@sgi.com
 / ___  __  __         / __  __  ___ // // *	M/S DER-200
(____/ (_/_/ (_(_/    / (_/_/ (_(_/ (/_(/_/_
	       _/
Newsgroups: comp.arch
Organization: Penn State University
Date: Thu, 30 Jul 1992 19:18:52 EDT
From: <GNR100@psuvm.psu.edu>
Newsgroups: comp.arch
Subject: .Z and .tar

    I know that .Z and .tar files are unix compression.  I also have the
software to do this in Dos.  The problem is, I can decompress a .Z file,
but when I go to unarchive a .tar file I get an archive not found error.
I know the .Z decompression works, because I have tested it on text filez.
I decompress the .Z file, and then I try to unarchive the .tar file.
I am usinf Ltar, and also detar, which I got off of wuarchive.wustl.edu.
Anybody familiar with these programs who can help?
           gnr100@psuvm.psu.edu
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:25:16 GMT
Reply-To: vhs@darkcube.radig.de

In article <1992Jul20.183334.19342@crd.ge.com> davidsen@ariel.crd.GE.COM  
(william E Davidsen) writes:
> In article <1325@pacsoft.com>, mike@pacsoft.com (Mike Stefanik) writes:
> |> UNIX boxes are "software compatable"?  I think not. 
>   It's getting a lot closer... most modern versions of UNIX have the
> same features and provide both SysV and BSD compatibility. Admitedly
> there are people who have gone their own way, like SCO and some of the
> realtime variants, but the world is a LOT better than it was a few years
> ago.

No no no, yor're getting me all wrong! What I stated was that that on a UNIX
system the various pieces of software work *together*, while on the <shudder,
don't mention it> they work more or less against each other, i.e. product A
will only run under conditions under which product B will *not* run. That
is what I meant (and expressed) by "software compatibility".

> |> : If I had intel inside(tm), I'd throw up...
> 
>   There's the heart of the whole discussion. It's not a matter of UNIX
> vs. MS-DOS, it's a matter of "Intel must be evil because they make money
> doing something I don't think is neat."

Wrong again. My original post was about the fact that compatibility is *not*
necessarily a Good Thing. While it is repeated mantra-like by the marketroids,
it does not help most customers very much. What does help is the sort of
fade-out compatibility that BSD uses, i.e. for each item, guarantee  
compatibility for two generations, then fade it out. But the kind of   
compatibility-or-death that IBM, Microsoft, Intel and the like enforce
only helps them! It leads into dead-ends quickly, especially if, like in
the cases mentioned, slavish compatibility is coupled with an initial
design that is so short-sighted it almost hurts.
That's what makes me like intel/MS/IBM so much.

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

If I had intel inside(tm), I'd throw up...
From: pmontgom@math.orst.edu (Peter Montgomery)
Newsgroups: comp.arch
Subject: Re: Running Sum Adders
Date: 23 Jul 92 15:49:21 GMT
Organization: Oregon State University Math Department

In article <MISHA.92Jul22214158@espresso.ai.mit.edu>
misha@ai.mit.edu (Mike Bolotski) writes:
>>>> On 21 Jul 92 23:46:23 GMT, ronus@eecg.toronto.edu (Ron White) said:

>Ron> Hi.  I have a paper that mentions the use of a: "running sum
>Ron> adder commonly found parallel processing units".  The paper
>Ron> doesn't go into any more detail and doesn't list any references
>Ron> w.r.t. this type of parallel adder.  Could someone point me to a
>Ron> reference that will explain the operation of a "running sum
>Ron> adder" ?

>I'll bet they're referring to a carry-save adder.  You can look
>that up in any text on computer arithmetic.

        Also look up ``fetch-and-add'' instruction, FAD.  This
takes and address addr and an (integer) increment amt.

        FAD  addr,amt   replaces  (addr) <- (addr) + amt

which returning the old contents (addr).

        The application to parallelism comes because several
processors might increment the same address at once.  Consider

        Processor 0:  FAD  addr0,amt0
        Processor 1:  FAD  addr0,amt1
        Processor 2:  FAD  addr2,amt2
        Processor 3:  FAD  addr0,amt3

where addr0 <> addr2.  There are many acceptable behaviors.
All increment (addr0) by amt0 + amt1 + amt3 and (addr2) by amt2,
while returning the old (addr2) to Processor 2.
The order of the three increments on addr0 is not specified, but each
is treated as an atomic operation.  For example, it might
return the old (addr0) to Processor 1, (addr0) + amt1 to
Processor 3, and (addr0) + amt1 + amt3 to Processor 0.

        The special aspect of this instruction is that memory
interface boxes can detect the duplicate addr0 and combine the
requests to reduce congestion.  For example, if it observes that
Processors 0 and 1 are incrementing the same address, it can
merge the two transactions into a single increment by amt0 + amt1.
Then, when the old (addr) comes back, the box can send this
(addr0) to Processor 0 and (addr0) + amt0 to Processor 1.
The corresponding box for Processors 2 and 3 would see different
addresses and need to make two separate memory operations.
-- 
New address as of June 26, 1992:
        Peter L. Montgomery              Internet: pmontgom@math.orst.edu
        Dept. of Mathematics, Oregon State Univ, Corvallis, OR 97331-4605 USA
Xref: sparky comp.arch:8423 alt.folklore.computers:11426 comp.benchmarks:1213
From: cc_s525@kingston.ac.uk (Francis Bell)
Newsgroups: comp.arch,alt.folklore.computers,comp.benchmarks
Subject: Re: Dinosaur noises (was: Re: dinosaur horsepower)
Date: 29 Jul 92 16:51:10 GMT
Organization: Kingston University

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.

My first machine was an Elliott 903 with paper tape reader (of course)
and built-in speaker. The manual billed it as "a desk-size computer"
which I mis-read for "desktop" the first time; silly me, they really
meant desk-size, and there was a memory expansion sitting next
to it (a whopping 16K core store) which was just as big.

Anyway when we were bored late at night we would load our favourite
little number "flight of the bumblebee" from paper tape and listen
to it performed flawlessly on the internal speaker. I've still got
the tape somewhere, but sadly the actual hardware was scrapped 10
years ago.
-- 
   _____                 "If the JNT had called the Grey Book 
    /  '                     the Black Book,
 ,-/-, __  __.  ____         we'd all communicate via BlackMail"
(_/   / (_(_/|_/ / <_    fgtbell@kingston.ac.uk
Newsgroups: comp.arch
From: aaronb@suhana.analog.ingr.com (Aaron B.)
Subject: Finding which bit set in a bit-string.
Keywords: Bit-counting.
Reply-To: aaronb@suhana.analog.ingr.com
Organization: Home Office Enterprise
Date: Mon, 27 Jul 1992 21:26:07 GMT


Article: 93 of comp.compression.research
From: moss@cs.umass.edu (Eliot Moss)
Newsgroups: comp.compression.research
Subject: Re: Algorithm for finding set bits in a bit-string.
Date: 26 Jul 92 02:23:37 GMT
Reply-To: moss@cs.umass.edu
Organization: Dept of Comp and Info Sci, Univ of Mass (Amherst)

I posted this on "comp.compression":

>Given a bit-string of any size print out the bits set starting with the
>least significant bit.

And somebody reply with this:

>In-reply-to: aaronb@suhana.analog.ingr.com's message of 26 Jul 92 01:03:25 GMT
>The "find first set bit" operation was recently discussed at length in
>comp.arch, and could be relevant, especially if the one bits are sparse.

My question is: did anybody follow this thread in this group.  Is there anyway
I could get access to the archive of this group.  If anybody had save the
postings on this topic please E-mail me a copy.


This is my current solution for this problem.  If anybody have a better one
please E-mail your response.  Thanks.


static unsigned char binvalue[9]={0x00, 0x01, 0x02, 0x04, 0x08,
                                        0x10, 0x20, 0x40, 0x80 };

int
show_msb(ch, off)
unsigned char ch;
long          off;
{
  int pos;

  if ( ch )
   {
     pos = ilog2( ch );
     printf("position = %d\n",pos+off);
     ch ^= binvalue[pos];         /* could also use: ch -= binvalue[pos]; */
     show_msb(ch, off);           /* recursive call for rest of bits */
   }
  return( 0 );
}

int
ilog2(n)
register unsigned char n;
{
   register long q;

   q = 0;
   while( n )
    {
      n >>= 1;
      q++;
    }
   return( q );
}   /* ilog2 */


Thanks in advance.

Aaron B
aaronb@suhana.analog.ingr.com
From: zeke@fasttech.uucp (Bohdan Tashchuk)
Newsgroups: comp.arch
Subject: Re: Proposal: Computer History Project
Keywords: software, history, computer
Date: 25 Jul 92 21:45:08 GMT
Article-I.D.: fasttech.1992Jul25.214508.4312
Organization: Fast Technology

In article <1992Jul24.144643.19792@crl.dec.com> stewart@crl.dec.com writes:
>Modern computers are so much faster than historic machines that
>it is possible to emulate the instruction set and I/O systems
>of a historic machine at full speed.  Thus students will be
>able to actually sit down and use TENEX running on an emulated
>PDP-10, or Bravo on a Xerox Alto, even when no more PDP-10's or
>Altos exist.

Aren't SPECmarks computed relative to a VAX 780? Is there still one of these
machines somewhere that gets powered up every year or so to run a new set of
tests? I think we need a 780 simulator that understands the hardware well
enough to do cycle-by-cycle simulation.

A hundred years from now kids can read in textbooks about "VAX mips", just like
we learn about Btu and horsepower today.
From: pcg@aber.ac.uk (Piercarlo Grandi)
Newsgroups: comp.arch
Subject: Re: BUSES
Date: 30 Jul 92 16:14:51 GMT
	<1992Jul27.191347.4485@ksmith.uucp> <33751@cbmvax.commodore.com>
Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
Organization: Coleg Prifysgol Cymru


On 29 Jul 92 02:25:59 GMT, jesup@cbmvax.commodore.com (Randell Jesup) said:

jesup> keith@ksmith.uucp (Keith Smith) writes:

keith> Is it not also true however, that the current disk devices can't even
keith> swamp an ISA bus?  The average desktop doesn't have multiple striped
keith> disks and whatnot.

jesup> Sure they can.  A single 3.5" drive can sustain 4.2MB/s.  With a
jesup> couple (or even maybe 1) of those, I think an AT bus would get
jesup> pretty crowded...

The old tirade! Do you think the "average desktop" has got the new
superfast/superspinning/4.2MB/s drives?

Of several dozen workstations at this site, very few have disks at
all... This seems typical.

It is always possible to find counterexample at the high end, but most
buses are not designed for the highest possible performing workstations,
they are most often designed for what 80% of the people are prepared to
pay for. Engineering means doing a decent job at a low cost.

If everybody could afford FB+/IPI/>5400RPM subsystems everybody would be
happier. Unfortunately "average desktop"s are endowed with a single
$1000/300MB/3.5" or $1500/600MB/5.25" drive that does 1.5MB/s sustained.

My own home machine, which is larger than the average desktop (at least
on this side of the Pond), has got two such drives and a 2MB/s VGA
board, and I am very far away from bumping into the limits of the ISA
bus. In practice the "average desktop" has got a single SCSI-1 host
adapter, and indeed I would suggest that the ISA bus is perfectly
adequate for all those setups that aren't/wouldn't be bottlenecked by a
single SCSI-1 bus; these are, as of now, the vast majority.

Clearly people who need to do real time TV, for example, need much
faster disks and much faster video cards, but they don't use "average
desktop"s.
--
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
Newsgroups: comp.arch,alt.folklore.computers
From: chris@tessi.com (Chris Lamb)
Subject: Re: Proposal: Computer History Project
Keywords: software, history, computer
Organization: Test Systems Strategies, Inc., Beaverton, Oregon
Date: Wed, 29 Jul 1992 16:13:07 GMT


Though it's not possible in many cases to keep the really old stuff in
working order, I think preserving the genuine article is more fun.  But I
certainly support the idea of trying to gather up as much of the old
software and documentation too, even if the "hardware" to run it on is a
software emulator.

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.

One more question before I go:  can someone say with certainty whether or
not the Boston Computer Museum has a PERQ?  If so, is it a working system or
just a dead hulk on display?  I've heard conflicting reports, and I'd like
to get a definitive answer, if possible.

Thanks!


-- Chris Lamb, Certified Perq (and NeXT) Fanatic	chris@tessi.com
Newsgroups: comp.arch
From: kludge@grissom.larc.nasa.gov ( Scott Dorsey)
Subject: Re: Proposal: Computer History Project
Organization: NASA Langley Research Center and Reptile Farm
Date: Thu, 30 Jul 1992 14:07:53 GMT

In article <9207301153.AA24130@thep.lu.se> magnus@THEP.LU.SE (Magnus Olsson) writes:
>
>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].

Someone on the net wrote an IBM 601 emulator a couple of years ago, as a
thesis project.  For the life of me I have no idea where to obtain it, but
if anyone does, I would be quite curious.  I had a copy running at a 
previous site, and it was a fun thing to program on.
--scott
From: supnik@human.enet.dec.com (Bob Supnik)
Newsgroups: comp.arch
Subject: Re: Proposal: Computer History Project
Summary: Looking for MIMIC sources
Keywords: MIMIC, PDP-8, PDP-11
Date: 25 Jul 92 02:16:20 GMT
Organization: Digital Equipment Corporation


In article <1992Jul24.144643.19792@crl.dec.com>, stewart@crl.dec.com (Larry Stewart) writes...
>Here is the beginning of an idea.  Let's kick it around and build on it.
>I've been thinking about this for 6 months or so, and I've mentioned
>the idea to several people privately, but klh's recent announcement 
>galvanized me into action.
>	-Larry Stewart
> 
>THE COMPUTER HISTORY PROJECT
> [rest deleted]

Back in the early 1970's, Applied Data Research [now defunct] marketed
a product called MIMIC [now defunct] which simulated the PDP-8, PDP-11,
PDP-7/9/15, Nova, and other minis [mostly now defunct] on a DECsystem-10
[now defunct] under TOPS-10 [etc].

MIMIC's simulations were extraordinarily accurate, both in terms of timing
and accuracy;  many of the CPU and device simulators were constructed from
hardware print sets and microcode listings.  We routinely ran the minis'
own operating systems under simulation.

Unfortunately, with the passing of the years, MIMIC, its parent company,
and now the sources have all disappeared.  If >>anyone<< has a lead on
where these sources can be found, please let me know by EMAIL
(supnik@human.enet.dec.com), as I would like to use these simulators
(rewritten to C) for modules in the proposed history project.

Bob Supnik	>Supnik@human.enet.dec.com
		>All opinions expressed are those of a hardline microcoder
		>and do not reflect those of Digital Equipment Corporation
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.arch
Subject: Re: BUSES
Date: 29 Jul 92 02:25:59 GMT
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Organization: Commodore, West Chester, PA

keith@ksmith.uucp (Keith Smith) writes:
>Is it not also true however, that the current disk devices can't even
>swamp an ISA bus?  The average desktop doesn't have multiple striped
>disks and whatnot.

	Sure they can.  A single 3.5" drive can sustain 4.2MB/s.  With
a couple (or even maybe 1) of those, I think an AT bus would get pretty
crowded...

>Someone please correct me if I'm wrong, but I think the inherent problem
>with a 'bus' of any description is the delay while the electrons take a
>torturous route across the copper foiling, and thru the connectors and
>buffers from the CPU to whatever card.  As clock speeds of CPU chips
>go up, it just takes too long for the information to run accross the
>conductors.

	Well, that and the fact that skew between different signals becomes
more of a problem at high speeds.

-- 
"Rev on the redline, you're on your own; seems like a lifetime, but soon it's
 gone..."  Foreigner
-
Randell Jesup, Jack-of-quite-a-few-trades, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com  BIX: rjesup  
Disclaimer: Nothing I say is anything other than my personal opinion.
Newsgroups: comp.arch
From: bs@fatima.mitre.org (Robert D. Silverman)
Subject: Re: CISC Microcode (was Re: RISC Mainframe)
Organization: Research Computer Facility, MITRE Corporation, Bedford, MA
Date: Thu, 30 Jul 1992 13:16:27 GMT

In article <1992Jul30.060053.20582@yrloc.ipsa.reuter.COM> rbe@yrloc.ipsa.reuter.COM (Robert Bernecky) writes:
:>2) What exactly is a "superfast sub-imbecile?"
:
:Superdrooler?
 
Dan Quayle??

--
Bob Silverman
These are my opinions and not MITRE's.
Mitre Corporation, Bedford, MA 01730
"You can lead a horse's ass to knowledge, but you can't make him think"
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Newsgroups: comp.arch
Subject: Re: CISC Microcode (was Re: RISC Mainframe)
Date: 24 Jul 92 13:14:48 GMT
Organization: Purdue University Statistics Department

In article <Brus8r.2K7@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
>In article <1992Jul22.163956.57436@cc.usu.edu> ivie@cc.usu.edu (CP/M lives!) writes:
|>> Item 3 can still be
|>> an issue, particularly on old architectures with clunky interrupt handling,

|>What do you mean by "clunky interrupt handling"?

>Many, many CPU cycles needed to get into and out of an interrupt, so it's
>impossible to take very many of them or respond quickly to one.  You have
>to figure in both hardware and software interrupt overhead; the relevant
>metric is elapsed time between stopping mainline execution and starting
>the interrupt handler *for that specific interrupt*.  Time spent figuring
>out deciding who gets to handle this one, or saving and restoring registers
>so he can be invoked safely, is part of the overhead regardless of whether
>it's in software or hardware.

>Pretty much the inescapable minimum is two pipeline breaks plus a cycle for
>the "return from interrupt" instruction.  There are CPUs that approach this
>for simple cases where the interrupt can be dealt with quickly (they do
>typically incur somewhat more overhead if the interrupt handler wants to
>run for a while and use substantial resources).

This "inescapable minimum" is at least partly due to the failure to realize
that planned interrupts are becoming more necessary.  The initial overhead
of an interrupt should be no greater than that for a subroutine call, and
possibly less.  FULL context switching needs speeding up.
-- 
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)
Newsgroups: comp.arch