HDTenEightyP/NetNews huggingface dataset:
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.arch
Subject: Re: IBM AS/400 is the world's slowest computer
Date: 22 Dec 92 04:15:40 GMT
Organization: Auspex Systems, Santa Clara

>3) The AS400 is a capability based tagged architecture.  It offers security
>    like nothing else on the market.  That's not to say that it's perfect,
>    but while all us RISCy folks have been off worrying about MIPS, IBM has
>    noticed that tools providing incredibly tight control over access to
>    information are crucial in many markets.  Try writing an AS400 virus!

Just out of curiosity, how much of the capability stuff is implemented
in what I, at least, would consider the *real* instruction set - i.e.,
the so-called "vertical microcode" instruction set - and how much is
implemented in the "high-level" instruction set?

I.e., precisely how CISCy is the "vertical microcode" instruction set? I
don't particularly care how CISCy the "high-level" instruction set is -
Smalltalk bytecodes are probably somewhat "high-level", as may be the
internal bytecodes used by various language interpreters, but both can
be handled, these days, by non-"high level CISC" processors (both RISC
and CISC).
Organization: Ministry of Education, Computer Center NETNEWS system V2.3
Date: Tuesday, 29 Dec 1992 11:14:40 EST
From: <TKUS135@TWNMOE10.BITNET>
Newsgroups: comp.arch
Subject: Asking info about Sun's XDBus

Greetings:

Could anyone point me to find papers, journals or documents that
are concerning to Sun's XDBus (XBus + Dynabus ?)?
I recall about one year ago, there was an article in EE Times (?)
which adverted that the Xerox's Dynabus is similar to IEEE Futurebus+
but with different assignment of control & status registers.
Since then, it seems no much advanced info about Dynabus can be afforded
until recently that Sun SPARCcenter 2000 release news mentioned that
the XDbus is adopted in the system.

Meanwhile, it is reported that maximun 32 proceossors can be pluged
into the Furturebus+ backplane. Should this imply that the XDbus being
restricted by the same limitation?

Please forward your direction to me directly.

Thanks,

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Yin-Chih Lin                   Industrial Technology Research Institute (ITRI)
Design Eng.                    Computer & Communication Research Labs.  (CCL)
lycmit@x1sun6.ccl.itri.org.tw  Microcomputer System Department X100
Tel: 886-35-917331             14 Bldg, 195 Chung Hsing Rd., Section 4
Fax: 886-35-917503             Chutung, Hsinchu 31015
                               Taiwan, R.O.C.
Newsgroups: comp.arch
From: vhs@rhein-main.de (Volker Herminghaus-Shirai)
Subject: Re: UNIX fseek time (was Re: Comparison of Alpha, MIPS and PA-RISC-II wanted)
Reply-To: vhs@rhein-main.de
Date: Tue, 29 Dec 92 21:23:44 GMT

In article <1477@pacsoft.com> mike@pacsoft.com (Mike Stefanik) writes:
> In an article, conor@lion.inmos.co.uk (Conor O'Neill) writes:
> >But, given that 'fseek' is incredibly slow on most Unix systems,
> >one could almost assume that Unix doesn't support random-access files.
> 
> What do you mean by this?  My understanding is that nothing is physically
> being done by the call -- it simply sets the byte offset in the file table.
> Is the copying of sizeof(off_t) bytes from user space to kernel space
> what makes it "incredibly slow", in your opinion?

Or did he mix it up with M$-DOS fseek on files opened in "text mode".
This is indeed incredibly slow because the file is searched for CR/LFs
since CR/LFs count as only one byte (a logical linefeed) in that case.
Another brilliant Bill Gates idea, ack!

--
Volker Herminghaus-Shirai (vhs@qb.rhein-main.de)

Looks good on the outside, but -
	intel inside
Newsgroups: comp.arch
From: alan@sal.wisc.edu (Alan Watson)
Subject: Re: VMS vs Unix
Organization: Space Astronomy Lab, Madison WI
Date: Thu, 24 Dec 1992 07:08:36 GMT

william davidson @crd.ge.com write:
>   joesvax::a$physical_disk$name_here_like_dra0:[dir.dir.dir]filename

don@zl2tnm.gen.nz (Don Stokes) writes:
>% rcp joesvax:/some-root/some-dir/filename localfile
>% cmd localfle
>% rm localfile

Aw, c'mon guys.  Mounting remote file systems is a doddle in both VMS
and Unix; this is a complete non-issue.  Of course, a badly configured
system can give everyone a headache.
From: mike@pacsoft.com (Mike Stefanik)
Newsgroups: comp.arch
Subject: Re: UNIX fseek time (was Re: Comparison of Alpha, MIPS and PA-RISC-II wanted)
Date: 27 Dec 92 18:40:38 GMT
Organization: Pacific Software Group, Riverside, CA

In an article, conor@lion.inmos.co.uk (Conor O'Neill) writes:
>But, given that 'fseek' is incredibly slow on most Unix systems,
>one could almost assume that Unix doesn't support random-access files.

What do you mean by this?  My understanding is that nothing is physically
being done by the call -- it simply sets the byte offset in the file table.
Is the copying of sizeof(off_t) bytes from user space to kernel space
what makes it "incredibly slow", in your opinion?

-- 
Mike Stefanik  mike@pacsoft.com  ...!uunet!pacsoft!mike  (909) 681-2623
Pacific Software Group, Riverside, CA
From: jjs40@cd.amdahl.com (John Sullivan)
Newsgroups: comp.arch
Subject: Re: Super-pipelining
Date: 30 Dec 92 23:04:48 GMT
Organization: Amdahl Corporation, Sunnyvale CA

In article <1992Dec30.175717.15249@dcc.uchile.cl>, pchris@dcc.uchile.cl
(Chris Perleberg) writes:
>After reading the Data Sheet of the 21064, I find nothing that seems
>to
>indicate the 21064 is super-pipelined, at least in terms of the common
>definition of super-pipelined.  Is DEC redefining the word
>"super-pipeline"?
>Anybody out there that can explain?

Although it's not obvious, this term really applies more to the cache
structure of a CPU pipeline than anything else.  (If you don't believe me,
flame away.)  Here's the definition that I suggest:

Super-pipelined: 
  The primary caches in the CPU pipeline are partitioned across two or
  more pipeline stages.  Because cache access  time is often a cycle-time
  determining path, the designers have decided to split the time across 
  more than one cycle.  The tradeoff is a faster instruction issue rate 
  due to a shorter cycle time) versus longer load-execute and 
  conditional-branch interlocks (leading to a higher CPI.)

The term "super-pipelined" has been widely used (and abused) since the
late 80's.  Super-pipelined machines have existed for about 20 years. 

-- 
John Sullivan, Engineer/Computer Development.      Email: jjs40@cd.amdahl.com
Amdahl Corporation, Sunnyvale CA.                  Phone: (408)746-4688
Newsgroups: comp.arch
From: bhandarkar@wrksys.enet.dec.com (Dileep Bhandarkar)
Subject: Re: Alpha Architecture Quirks
Organization: Digital Equipment Corporation
Date: 22 DEC 92 10:03:11    


In article <8840087@hpfcso.FC.HP.COM>, wlw@hpfcso.FC.HP.COM (Will Walker) writes...
>Quite right, SPECfp92 is not very sensitive to divide or square root
>latency.  Which applications are?  Possibly 3D graphics.  Perhaps Mr.
>Scidmore's applications are sensitive to divide latency since he
>brought it up?  I don't know.

The ora benchmark in cfp92 is very sensitive to the speed of square root.

/d
Xref: sparky comp.arch:11903 comp.arch.storage:884
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.arch,comp.arch.storage
Subject: Re: ?Concurrent DMA possible on smarter PC buses (EISA/MCA/Localbus)
Keywords: EISA,MCA,Localbus,VESA,PC,IBM,smartIO
Date: 23 Dec 92 19:21:54 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <1gul5nINN7ln@cbl.umd.edu>, mike@cbl.umd.edu (Michael Santangelo) writes:

| So this theoretical EISA SCSI controller and this theoretical EISA FDDI
| controller could both be doing DMA writes to main memory (interleaving their
| accesses I assume)?  Since PC's do not have multiport memory, I assume
| the EISA subsystem would itself (on behalf of BOTH of these controllers) have
| full control over the memory during the dual transfers, starving out the CPU?

a) these are shipping, not theoretical

b) every memory system has a limit to bandwidth, after which you make
   either i/o or cpu wait. Most people find better total throughput when
   they make the cpu wait. A quick calculation of the bandwidth of the bus
   and any remotely plausible i/o system will tell you the cpu doesn't wait
   long.

-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
    Keyboard controller has been disabled, press F1 to continue.
Newsgroups: comp.arch,comp.sys.dec,comp.sys.sgi,comp.sys.hp
Subject: Re: Comparison of Alpha, MIPS and PA-RISC-II wanted
From: rmk@rmkhome.UUCP (Rick Kelly)
Organization: The Man With Ten Cats
Date: Thu, 24 Dec 1992 04:08:57 GMT
Reply-To: rmk@rmkhome.UUCP (Rick Kelly)

In article <id.3H2W.BOB@ferranti.com> peter@ferranti.com (peter da silva) writes:
>In article <1992Dec22.203644.5908@ais.com> bruce@ais.com (Bruce C. Wright) writes:
>> added functionality.  C, unfortunately, does not provide a very good
>> interface to RMS;  but other languages do (eg, PL/I).
>
>Near as I can tell, VAX C is a deliberate attempt to discourage the use
>of C on VMS. It's *that* bad.

No, it's worse. :-)

-- 

Rick Kelly	rmk@rmkhome.UUCP	merk!rmkhome!rmk	rmk@frog.UUCP
Newsgroups: comp.arch
From: skwong@cuse1.se.cuhk.hk (Wong Sai Kee (Graduate Assistant))
Subject: What is Cyrix 486? What is the relationship btn NeXTStep & 486?
Organization: Faculty of Engineering, The Chinese U. of Hong Kong
Date: Tue, 29 Dec 1992 10:11:16 GMT

As I did not read news on NeXTStep and 486, I lost tracking.  Would
anybody give me pointers/information about "What is Cyrix 486 ?" &
"What is the relationship between NeXT, NeXTStep and 486" ?

In order to save netnews bandwidth, you could send me via email.

Thanks

Mr.Sai-Kee WONG
skwong@se.cuhk.hk
Newsgroups: comp.arch
From: peter@ferranti.com (peter da silva)
Subject: Re: <None> (Should be Open Systems, bloody NEWS system...)
Organization: Xenix Support, FICC
Date: Wed, 23 Dec 1992 15:53:23 GMT

In article <JAN.92Dec22131534@pallas.neuroinformatik.ruhr-uni-bochum.de> jan@pallas.neuroinformatik.ruhr-uni-bochum.de (Jan Vorbrueggen) writes:
> In article <id.GL0W.ED9@ferranti.com> peter@ferranti.com (peter da silva)
> writes:
>    In general, user friendliness requires detailed control over every aspect
>    of the user interface (as any Apple developer about that!).

> Not quite. While being able to tailor your environment to your needs is
> important, it's much more important that things are consistent across
> applications, intuitive in the sense that you don't need more than two or
> three tries to find out how to do what you intend to do, and easy to memorize
> (which, of course, is much easier if things are consistent).

I know you think you understand what you thought I said, but you must
understand that what you read is not what I meant. And if you can understand
THAT sentence...

When I said "detailed control over every aspect of the user interface" I
was talking about control by the vendor (for example, Apple), via developer
guidelines and withholding releases and support from developers who do not
toe the line, rather than by the user.

User level customizability is a whole different issue. How customizable is
your toaster? You can toast dark, or light, and you can use one slot. That's
about all. But it's sure user-friendly.

>    Open systems require conformance to externally defined standards and
>    interoperability with software you've never had a chance to spec. It's VERY
>    hard to get the two together, which is why so many people are excited about
>    the NeXT.

> I think people are excited about the NeXT because it fits the bill I gave
> above...When first introduced, the machine was anything but inter operable
> (optical disk, not all SCSI disks talk to it, nonstandard window system with
> nonstandard monitors, no power switch :)).

You could take a NeXT system, stick it on a network or a phone line, and
run it as a peer with any other UNIX system. The application programmer
interface is UNIX with Mach extensions, and both UNIX and Mach are open
standards. The primary disk interface is SCSI (quality of that SCSI
implementation aside, it *is* a standard). You could run X11 on it
pretty easily if you wanted to. It's an awfully open system compared
to Mac, or NT, or OS/2, or VMS... the only nonstandard stuff was the
window system, and given the quality of X you really can't blame them.
-- 
Peter da Silva                                            `-_-'
Ferranti International Controls Corporation                'U` 
Sugar Land, TX  77487-5012 USA
+1 713 274 5180                            "Zure otsoa besarkatu al duzu gaur?"
From: wright@duca.hi.com (David Wright)
Newsgroups: comp.arch
Subject: Re: UNIX fseek time (was Re: Comparison of Alpha, MIPS and PA-RISC-II wanted)
Date: 30 Dec 92 11:15:43 GMT
Organization: Hitachi Computer Products, OSSD division
NNTP-Posting-Host: duca.hi.com

In article <28162@dog.ee.lbl.gov> torek@horse.ee.lbl.gov (Chris Torek) writes:
>In article <1hnqdeINN15a@duca.hi.com> wright@duca.hi.com (David Wright) writes:
>>In addition, fseek() is generally moronic about checking whether the
>>new file pointer is within the current buffer.  That is to say, it
>>doesn't check.  So if you, say, try to read a file backwards, one byte
>>at a time, you'll do as many reads as there are bytes in the file.
>
>Speak for yourself. :-)
>
>I wrote most of the 4.4BSD stdio (bugs and all---so far we have found
>and fixed three or four).  My fseek() can read a file backwards fairly
>quickly.  You will do better if you read() directly---no general
>subroutine can be perfectly optimal for all tasks---but there is no
>longer an order of magnitude slowdown for short backwards seeks when
>reading.

OK, you're a genius :-)  My point was not that fseek() is inherently
slow, just that some implementations were not well thought out.  I
know you know how this all works, but judging from the email I've
been getting, some people are confused.  So, tutorial time: 

 fseek is a library routine, and these libraries have their own
 buffers, WHICH ARE UNRELATED TO THE FILE SYSTEM CACHE.  The idea
 behind fseek, fread, etc, is to avoid doing many system calls when a
 program wants to do many small reads.  Instead, the library routine
 does one large read, then hands small chunks of data to its caller.
 This way, the (relatively expensive) system calls are replaced by
 (relatively cheap) procedure calls.  (I'm primarily considering
 reading here.  Writing is a bit more complex.)

 Inefficiencies arise because a simple-minded version of fseek (and
 most of them are) will not check to see whether the new pointer is
 still within the current buffer -- it just assumes not and always
 rereads the file.  

I hope this makes things clearer.
Newsgroups: comp.arch
From: essbaum@rchland.vnet.ibm.com (Alexander Essbaum)
Subject: Re: Alpha and Super-pipelining
Date: Wed, 30 Dec 1992 20:06:29 GMT
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
Organization: IBM Rochester

In article <1992Dec30.175717.15249@dcc.uchile.cl>, pchris@dcc.uchile.cl (Chris Perleberg) writes:
|> 
|> After reading the material available about the Alpha, I noticed that it was
|> mentioned a few times that the first implementation of the Alpha, the 21064,
|> is *super-pipelined* as well as superscalar.  For example, in "infosheet.txt"
|> that is available on gatekeeper.dec.com the following is stated:
|> 
|> >    Digital's 21064 Microprocessor
|> >    ....
|> >    The 21064 is a super-scalar, super-pipelined implementation of the
|> >    Alpha architecture. Super-pipelined means that an instruction is issued
|> >    to the functional units at every clock tick and the results are
|> >    pipelined. Being super-scalar, the architecture allows the instruction
|> >    unit to issue two instructions per clock tick, resulting in
|> >    significantly higher throughput and performance.
|> 
|> After reading the Data Sheet of the 21064, I find nothing that seems to
|> indicate the 21064 is super-pipelined, at least in terms of the common
|> definition of super-pipelined.  Is DEC redefining the word "super-pipeline"?
|> Anybody out there that can explain?
|> 
|> 	Chris Perleberg
|> 	pchris@dcc.uchile.cl

i always thought super-piplining referred to piplining funtions that would
normally be given a single pipeline stage.  ie. if a processor has 4 stages
with delays like:

ifetch   10ns
decode/operand fetch   10ns
execute   20ns
writeback   10ns

you can cut the critical path delay by 10ns if you break the execute into
2 stages:

ifetch   10ns
decode/operand fetch   10ns
execute1   10ns
execute2   10ns
writeback   10ns

the second example is super-piplined.

axel
Newsgroups: comp.arch
From: wayne@backbone.uucp (Wayne Schlitt)
Subject: Re: Any new instructions in a i486?
Organization: The Backbone Cabal
	<PCG.92Dec19162224@decb.aber.ac.uk> <BzMEIJ.Anz@pix.com>
Date: Mon, 21 Dec 1992 21:31:40 GMT

In article <BzMEIJ.Anz@pix.com> stripes@pix.com (Josh Osborne) writes:
> In article <PCG.92Dec19162224@decb.aber.ac.uk> pcg@aber.ac.uk (Piercarlo Grandi) writes:
> >No, this cannot be the reason. As a rule the Cyrix 486DLC CPU chip is
> >sold with the Cyrix Fasmath (a 387) coprocessor, the combo being touted
> >quite reasonably as a 486DX equivalent.
> 
> I don't think this is the case (but I would love to be wrong...).  I beleve
> the #clocks each insn takes is more like the 386, then the i486.


to quote an article that was just posted last week to comp.sys.intel:

< Intel 486SX:
< execution unit:  RISC-like execution unit with five stage pipeline. Barrel
<                  shifter. Conditional jump taken/not taken: 3/1 clock cycles.
<                  Instructions that can be executed in 1 clock cycle if the
<                  destination is a register and the source is either a register
<                  or an immediate value:
<                  ADC,ADD,AND,BSWAP,CMP,DEC,INC,MOV,NEG,NOT,OR,POP,PUSH,SBB,
<                  SUB,TEST,XOR
< 
< Cyrix 486DLC
< 
< instruction set: complete Intel 486SX instruction set, including *all*
<                  486 specific instructions: WBINVD (write back and
<                  invalidate data cache), XADD (exchange and add), CMPXCHG
<                  (compare and exchange), BSWAP (Byte Swap), INVLPG
<                  (Invalidate TLB entry), INVD (Invalidate Data Cache)
< 
< execution unit:  RISC-like execution unit with five stage pipeline. Barrel
<                  shifter. 16x16 bit hardware multiplier (16x16 bit multiply:
<                  3 cycles, 32x32 bit multiply: 7 cycles, AAD: 4 cycles).
<                  Conditional jump taken/not taken: 6/1 clock cycles.
<                  Instructions that can be executed in 1 clock cycle
<                  if the destination is a register and the source is
<                  either a register or an immediate value:
<                  ADC,ADD,AND,CDQ,CLC,CLD,CMC,CMP,CWD,DEC,INC,MOV,MOVSX,
<                  NEG, NOT,OR,SBB,SHLD,SHRD,STC,STD,SUB,TEST,XOR

So, for most instructructions that the Intel 486 executes in 1 cycle,
the cyrix 486 does also.  There are some things that take longer,
there are some things that take less time.

I haven't seen any SPEC*92 info on the Cyrix, but it is my
understanding that they are about 10% slower than intel's parts at the
same clock speed.


-wayne

Xref: sparky comp.arch:11953 comp.sys.intel:2841
From: pcg@aber.ac.uk (Piercarlo Grandi)
Newsgroups: comp.arch,comp.sys.intel
Subject: Re: Superscalar vs. multiple CPUs ?
Date: 27 Dec 92 20:07:33 GMT
	<PCG.92Dec23144916@decb.aber.ac.uk>
	<1992Dec23.164617.8055@athena.mit.edu>
Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
Organization: Prifysgol Cymru, Aberystwyth

On 23 Dec 92 16:46:17 GMT, solman@athena.mit.edu (Jason W Solinsky) said:

solman> We seem to be saying the same things only you keep on talking
solman> about macro-level parallelism as though it would be difficult to
solman> exploit, and I feel that the existence of macro-level
solman> parallelism justifies increased superscalarity.

It's your very feeling that I find very, very optimistic, and totally
unsupported by past experience. But maybe I am too conservative, and I
hope that I am wrong. After all the human brain seems to be built like
you say, as a very highly parallel dataflow engine, not a massively
(macro) parallel machine.

solman> It is my contention that as processors continue to get more and
solman> more hyperscalar, they will be increasingly able to exploit
solman> macro-level parallelism without the help of smart compilers

As a contention, stated so bluntly, it stands on its own. I can only
repeat that I am skeptical, as the experience so far seems that basic
block level parallelism (which can exploited with multiple functional
units within the same CPU) is quite a different thing from continuation
level parallelism (which can be exploited with multiple CPUs within the
same machine).

solman> In a hyperscalar chip it will be necessary to implement tagging
solman> and/or scoreboarding protocols to control resource allocation
solman> and make sure that none of the data gets mixed up.

One of the big problems in going from the basic block to the
continuation level is that scheduling basic blocks is relatively easy,
as there are no conditional branches, or at most you deal with loops
(I am discounting heroic attempts to fit things like trace scheduling to
general purpose codes).

Getting multiple threads to run within the same CPU requires more than a
bit of things like speculative execution, and maybe even backtracking.

solman> Once this overhead is paid, the protocols can be altered to find
solman> macro level parallelism on their own with very little additional
solman> cost in either performance or area.

More than overhead I would say that the problem is that as of now nobody
have got the faintest clue on how to make this work in particular cases,
not to mention in the general case. I'd love to be proved underinformed
on this.

Maybe you are thinking of something like Hewitt's ideas on actor based
computing; but to me they look like an imaginative way organize macro
level parallelism.
--
Piercarlo Grandi, Dept of CS, PC/UW@Aberystwyth <pcg@aber.ac.uk>
  E l'italiano cantava, cantava. E le sue disperate invocazioni giunsero
  alle orecchie del suo divino protettore, il dio della barzelletta
From: paulh@msen.com (Paul Haas)
Newsgroups: comp.arch
Subject: Re: uniprocessor design ceiling
Date: 29 Dec 1992 00:00:50 GMT
Organization: Msen, Inc. -- Ann Arbor, Michigan
NNTP-Posting-Host: garnet.msen.com
X-Newsreader: TIN [version 1.1 PL8]

Bob Supnik (supnik@human.enet.dec.com) wrote:

: The ingenuity of processor designers (and semiconductor technologists) being
: far from exhausted, I believe this performance growth can continue for the
: rest of this decade.  There are some limiting factors:

: - Process technology evolution appears to be slowing somewhat, due to
:   lengthening development time (and cost) for new generations of semiconductor
:   processing equipment.

Is this a long term trend?

: - Increases in performance have been accompanied by increases in power
:   consumption, in opposition to rising requirements for 'green' technology.

Are you talking about the CPU chip or the whole system?  The top of the line
CPU chips are using more power, but the system requirements are going down
dramatically.  During the same period that the microprocessor went from a
few hundred milliwatts to 30 watts, disk drives went from a few hundred watts
to a few watts.  There are usually more disks in a system than CPUs.  Likewise
almost everything else in the system uses less power.

--
Paul Haas, work: paulh@ox.com, (313) 930-1888. home: paulh@hamjudo.mi.org