HDTenEightyP/NetNews huggingface dataset:
From: krt@ddxrsg.mlo.dec.com (Khaled Tabbara)
Subject: Re: 100 Mips Intel NeXT (processor comparison)
Reply-To: krt@avalon.mlo.dec.com
Organization: Digital Equipment Corporation
Date: Thu, 31 Dec 1992 16:08:31 GMT


In article <WAYNE.92Dec31074958@backbone.uucp>, wayne@backbone.uucp (Wayne Schlitt) writes:
|>
|>If "onboard" means "on the motherboard", then yes, I would expect that
|>some of the high end alpha systems will probably have 1MB of cache.


The highest-end Alpha AXP system has 4 MB of [second-level/backup] cache on 
the CPU board. If you configure it with 4 CPUs then you'll have 16 MB of
cache !! My workstation has 16 MB of MAIN MEMORY :-)


--
Khaled Tabbara 

Alpha Personal Systems Group
Digital Equipment Corporation

Disclaimer: I don't speak for Digital.

Newsgroups: comp.arch,comp.sys.dec,comp.sys.sgi,comp.sys.hp
From: peter@ferranti.com (peter da silva)
Subject: Re: Comparison of Alpha, MIPS and PA-RISC-II wanted
Organization: Xenix Support, FICC
Date: Wed, 23 Dec 1992 16:39:20 GMT

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.
-- 
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: pcg@aber.ac.uk (Piercarlo Grandi)
Newsgroups: comp.arch
Subject: Re: IBM AS/400 is the world's slowest computer
Date: 27 Dec 92 19:43:35 GMT
	<BzsIFK.EMF.2@cs.cmu.edu>
	<1992Dec25.033918.3246@beaver.cs.washington.edu>
Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
Organization: Prifysgol Cymru, Aberystwyth

On 25 Dec 92 03:39:18 GMT, kolding@cs.washington.edu (Eric Koldinger) said:

kolding> Last I checked (4 years ago), the AS/400 supported RPG III,
kolding> COBOL (I think), Pascal, PL/I, and they were coming out with a
kolding> C compiler.

Actually it's going to be even more bizarre. IBM have stated that C is
going to become their major app dev language on the AS/400 (and in
general across the whole SAA base, which now includes DCE!), which fact
is quite amazing; as a side note I don't think Pascal is in SAA, so
probably it is not supported on AS/400; and I seem to remember that PL/1
is not available yet, even if it is 'scheduled' as it is in SAA.

kolding> You don't generally use the capabilities at the applications
kolding> level, and the languages provide no real ability to manipulate
kolding> capabilities

Actually I think that C on the AS/400 just runs in a 16MB memory object
like most other tradictional languages. In much the same way it was
implemented on the Burroughs descriptor machines.

kolding> (I've often wondered exactly what C ended up looking like on
kolding> that machine, as pointers and ints are definitely not the same,
kolding> and casting an int to a pointer makes no sense).

The AS/400 is Not a VAX - I can see a nice Spencer article on that being
written up when we will all have AS/400s on our desks :-).

kolding> There's a fundamental difference between hardware and software
kolding> capabilities.  Software capabilities can be forged, however
kolding> improbable.  For example, Amoeba capabilities are just long
kolding> integers (32, 64 bits?).  You can forge one, but I wouldn't bet
kolding> on it.  Hardware capabilities are secure and cannot be forged.

AS I have remarked in another article, there are two general styles of
capability implementation, those that keep capabilities in a segment,
and those that mingle them with use data. Either style may be
implemented in sw or hw, and actually capability segments are quite
popular even with hw solutions.

With capability segments, as long as you have a suitable MMU, hw or sw
does not matter; otherwise it does, because the hw solution is to tag
each word of memory with a bit, the sw solution si to tag each
capability with a random key (encrypted), which, as you say, might be
guessed.
--
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
Newsgroups: comp.arch
From: mo@gizmo.bellcore.com (Michael O'Dell)
Subject: Re: No Last Call Optimization on Sparc and DECstation
Followup-To: comp.compilers
Keywords: 
 
Reply-To: mo@bellcore.com
Organization: Center for Chaotic Repeatabilty
Date: Sat, 2 Jan 93 14:45:18 GMT

this is also known as "tail recursion folding" (or conversion or some
such) and is practised routinely (ouch!) by LISP compilers on RISC
machines.  There are a number of challenges to exploiting the technique 
in C compilers (having to do with exception handling, setjmp/longjmp,
etc).  the other issue is "how big is the win?"  for languages like
Lisp and Prolog the frequency of the construct may well be rather
different than in C code, making the effort less interesting.

but as I said, as least in LISP compilers, tail recursion is indeed
handled on modern RISC machines - several language definitions
*require* tail-recursion folding, so they gotta do it.

further discussions should probably move to comp.compilers, however.

	-Mike

Bellcore?? Bellcore ain't allowed to have opinions - these be mine.

Newsgroups: comp.arch
From: rsrodger@wam.umd.edu (Yamanari)
Subject: Re: 100 Mips Intel NeXT (processor comparison)
Organization: University of Maryland, College Park
Date: Thu, 31 Dec 1992 02:23:17 GMT

In article <1992Dec31.013141.132685@zeus.calpoly.edu> mneideng@thidwick.acs.calpoly.edu (Mark Neidengard) writes:
>I think that the way of getting around this bottleneck is to use EXTENSIVE
>caching with sophisticated read-ahead logic.  I figure that a 200 MHz
>processor like the Alpha should be mated with 5 ns RAM in order to do "hot
>cycle" memory access, which is a practical impossibility.  So, like everyone
>else, they have waitstates and attempts at caching.  And the Alpha is only
>the tip of the iceberg.  If you got a chip that executes a lot of
>instructions at once (say, three or more in parallel sustained), just
>trying to keep the instruction prefetch pipelines filled would require more
>throughput than the memory bus could handle.  The only solution will have to
>be making faster memory, and caching to a farethewell until then.
>
>Don't be surprised if CPU's start coming out with 1 meg of onboard cache
>within the next year...


	Is this really likely, given the complexity (according to 
	net rumor) already involved in fabricating the Alpha?


>
>Mark Neidengard
>mneideng@cosmos.acs.calpoly.edu
>"You gotta concentrate on the mission you be takin'.
> It's not so much the mission, but you got crazy ignition!"
>           A Tribe Called Quest
>


-- 
	Blaming society for your problems is like blaming clouds for rain.
	         ---  Boycott == censorship == cowardice  ---
	Do I even need to point out that my views do not represent
	those of my employer, institution or relations?
Newsgroups: comp.arch
From: bernie@metapro.DIALix.oz.au (Bernd Felsche)
Subject: Re: IBM AS/400 is the world's slowest computer
Organization: MetaPro Systems, Perth, Western Australia
Date: Fri, 1 Jan 93 10:25:54 GMT

In <id.TX9W.FC3@ferranti.com> peter@ferranti.com (Peter da Silva) writes:

>In article <1992Dec26.003022.25532@bilver.uucp> wbeebe@bilver.uucp (Bill Beebe) writes:
>> >Now I won't say I was happy with the performance on the 286, but the current
>> >systems with moderately old 386es are adequate, and our 486 box screams.

>> Maybe I *really* am dumber than a box of dirt, but why, in this day of
>> networking, would anyone do team development on a single box when it would
>> appear that team development on networked single-user boxes would be a lot
>> more efficient?

>Because team development on networked multiuser boxes is better than either.
[ valid points regarding development deleted ]

>> Why do we still need multi-user boxes except to support obsolete business
>> practices?

>Because they work?

It's more efficient and practical, technologically and in
terms of organizational topology to have multi-user boxes
for sharable resources such as the non-computing business's
main operational database (truly distributed databases are
still (IMHO) research toys or vapourware) and a really fast
compute engine.

For small organizations with limited computing staff (yes,
even none!), a multi-user box is often the way to go.
Networking introduces many complications which are often
difficult to diagnose from off-site using anything less than
a megabit/second link and a voice link to have a "slave" do
the physical checks.

Finally, let's not forget the ultimate reality check: Cost!
There is no cheaper way to provide computing access to those
with well-defined requirements, than a multi-user box with
character-cell terminals on each desk. It's not pretty, but
it's just as productive (some say more productive) than a
graphics workstation for the majority of business users.

-- 
+-----+ Bernd Felsche                     _-,_|\  #include <std/disclaimer.h>
| | | | MetaPro Systems Pty Ltd          /  |   \ bernie@metapro.DIALix.oz.au
| | | | 328 Albany Highway,              X_.'-._/         Fax: +61 9 472 3337
|m|p|s| Victoria Park, Western Australia 6100  v        Phone: +61 9 362 9355
Newsgroups: comp.arch
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.arch
Subject: Re: Def of a workstation (a lark)
Date: 3 Jan 93 20:16:15 GMT
Organization: Auspex Systems, Santa Clara

>The workstation is Turbochannel based, the PC EISA. 

Don't HP's newer RISC-based workstations use the EISA bus?
Newsgroups: comp.arch
From: duzan@gumby.cis.udel.edu (Gary D. Duzan)
Subject: Re: Def of a workstation (a lark)
Organization: Your Organization Could Be Here!
Date: Sun, 3 Jan 1993 22:07:21 GMT

In article <1993Jan3.052930.27869@wam.umd.edu> rsrodger@wam.umd.edu (Yamanari) writes:
=>	Can anyone give me a definition of workstation, other than 
=>	cost, that seperates it from modern high-end PC systems (in his
=>	case, one that cost no more than $3500).  
=>
   A (computer) workstation is a machine that actually lets you get
your work done without excessive migranes. :-) Of course, this
definition varies, depending on what kind of work you are doing. If you
are doing data entry (or professional news-reading :-) then a
workstation can be a piece of antiquity like the HP 2621P I'm currently
using. If you are doing real-time 3D rendering, you might want
something a little more powerful. :-)

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts


p.s. Anything running DOS is obviously disqualified since it is bound
to cause excessive migranes. (But then I'm prejudiced: I have to work
with them all the time.)

                                      GD,TL,TR,HPotCA



-- 
                             duzan@cis.udel.edu
   _o_                       ------------------                         _o_
 [|o o|]       Virtual Reality? No thanks, I've already got one.      [|o o|]
  |_O_|       Disclaimer: I have no idea what I am talking about.      |_O_|
From: bengtl@maths.lth.se (Bengt Larsson)
Newsgroups: comp.arch
Subject: Re: Comparison of Alpha, MIPS and PA-RISC-II wanted
Date: 26 Dec 92 23:06:42 GMT
Organization: Lund Institute of Technology, Sweden

In article <1992Dec24.231152.17240@netcom.com> feustel@netcom.com (David Feustel) writes:
>Just curious: Is EDT the "real" editor referred to in earlier posts?
>If so, I'll stick with the "toy" vi editor.

He probably meant EVE and the TPU extensions language.

-- 
Bengt Larsson - bengtl@maths.lth.se
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, 30 Dec 1992 19:17:24 GMT

In article <1992Dec29.012215.10632@ryn.mro4.dec.com> Peter.Mayne@cao.mts.dec.com writes:
> ** I believe that you can also run into problems if you have
> ** a signal handler that gets invoked, and resets errno in the period
> ** between your successful system call and your test for success. It's

You also have problems if you invoke a signal handler that jumps to a random
location. Assuming broken code, you can derive anything.

See my previous message on this subject.
-- 
Peter da Silva                                            `-_-'
Ferranti International Controls Corporation                'U` 
Sugar Land, TX  77487-5012 USA
+1 713 274 5180                            "Zure otsoa besarkatu al duzu gaur?"
Xref: sparky comp.arch:11985 comp.sys.intel:2846
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.arch,comp.sys.intel
Subject: Re: Superscalar vs. multiple CPUs ?
Date: 29 Dec 92 20:02:47 GMT
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Organization: Commodore, West Chester, PA

pcg@aber.ac.uk (Piercarlo Grandi) writes:
>This is another reason for which I think hyperscalar is premature:
>a vector instruction has the very nice property that it implies a very
>definite memory access pattern, as compared with a loop that does the
>same thing. And many important applications have FIFO data reference
>patterns, for which predictive memory accesses are essential, and
>adaptive ones, like those implied by a cache, are fatal:

	This is one reason I've been advocating smarter caches, particularily
the ability to do predictive pre-fetching.  There are a couple of ways to
set this up:

1.	Instruction sets address, bound, and perhaps amount to fetch.  Access
	to address causes the next item to be fetched (or it could be more
	aggressive than that, depending on memory latency).

2.	Load instruction encodes prefetch-enable and bounding size in the
	instruction.  The problem here is finding enough bits in the
	instruction.

3.	Instruction sets register, bound and perhaps size, and any load
	relative to that register causes a prefetch (the RPM40 data cache
	design included this - never built though).  Only works if the
	register number is available to the cache controller.

4.	Prefetch instruction is executed earlier in the instruction stream
	to fetch a location.  This is probably the least-useful way to do
	this, certainly it's highest-overhead in cycles (and might require
	more instructions to set up).

-- 
-
GNU Emacs is a LISP operating system disguised as a word processor.
 - Doug Mohney, in comp.arch

Randell Jesup, Jack-of-quite-a-few-trades, Commodore Engineering.
jesup@cbmvax.commodore.com  BIX: rjesup  
Disclaimer: Nothing I say is anything other than my personal opinion.
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.arch
Subject: Re: question about DMA devices
Date: 22 Dec 92 22:25:45 GMT
Organization: Auspex Systems, Santa Clara

>So this is quite an old trick, and not really that difficult to do.  I would
>assume that current Unix/workstation systems do something similar.

Well, it's what Suns do.  Suns with "Sun-style" static RAM MMUs use the
MMU as a bus map - addresses on the I/O bus get run through the MMU
(after having, e.g. 0xFF stuck in as the top byte) to get the physical
address to which they refer.  Some, perhaps all, Suns with
in-memory-page-table MMUs have separate "I/O MMUs" for that purpose (the
3/80 and 3/4xx, which used the 68030's MMU as the main MMU, did, as do
the SPARC Reference MMU machines, or at least the Sun-4m machines; dunno
about the 386i).

Other UNIX boxes may or may not do that.
Xref: sparky comp.arch:11859 comp.sys.dec:6591 comp.sys.sgi:18265 comp.sys.hp:14308
From: rf@cl.cam.ac.uk (Robin Fairbairns)
Newsgroups: comp.arch,comp.sys.dec,comp.sys.sgi,comp.sys.hp
Subject: Re: Comparison of Alpha, MIPS and PA-RISC-II wanted
Date: 22 Dec 92 14:05:43 GMT
Organization: U of Cambridge Computer Lab, UK

In article <mwp.724991851@iconix.oz.au>, mwp@iconix.oz.au (Michael
Paddon) writes (in a rather tetchy, but pretty well-informed post):
|> [...]
|> >	3) No standardized user firendly shell.
|> 
|> Last time I looked POSIX had standardized at least one of the Unix shells.
|> You can move to any modern Unix, and be able to use your favorite shell.
|> 
|> In comparison, VMS provides DCL. A language with 60's control structures
|> (no for loops, while loops etc). No pipes. No command output substitution.

True, all true.  VMS enthusiast though I am, I have to agree here.

|> No globbing, so that's its done different by every command. God save us!

Indeed no globbing (in the Un*x sense).  RMS (or is it the underlying
ACP? - I don't have direct access to VMS systems any more, boo hoo)
provide wildcard searching to every application.  An application that
rolls its own is distinctly out of order here...

There are advantages to the Un*x globbing mechanism, but on the whole
I prefer the VMS way.

|> [...]
|> 
|> After using both, I found that I produce code up to 10 times faster under
|> Unix. Which is superior?

Depends what you want it for.  For me now, using a Un*x platform to
support research into other OSs is fine.  In my previous job,
developing applications to _sell_, I appreciated what I perceived as
the solid base that VMS offered.

|> >If UNIX was ever allowed to become the sole O/S it would halt O/S deelopment
|> >completely. The only effort UNIX has ever made is in catching up.
|> 
|> There should never be a sole OS. That way lies stagnation. However Unix
|> has broken ground in some extremely important areas; examples are easy to
|> find, for instance the BSD networking development.
|> 
|> The most important point, however, is that Unix is *not* perfect. The
|> problem with commercialization is that is becomes harder and harder to
|> throw away old ideas, because code must be supported.
|> 
|> So Unix grows crusty with age, and thereby creates room for a newcomer.
|> What will it be? That's the real question.

If anyone comes up with the real answer any time soon, let me know...
--
Robin (Campaign for Real Radio 3) Fairbairns       rf@cl.cam.ac.uk
U of Cambridge Computer Lab, Pembroke St, Cambridge  CB2 3QG, UK
"They had twelve years to lay in wait for us" - Bush supporter on Nov 4
Newsgroups: comp.arch,comp.sys.dec,comp.sys.sgi,comp.sys.hp
From: pchris@dcc.uchile.cl (Chris Perleberg)
Subject: Performance Evaluation Papers
Originator: pchris@pehuen
Date: Mon, 21 Dec 1992 14:27:42 GMT
Reply-To: pchris@dcc.uchile.cl
Organization: Universidad de Chile, Depto. de Ciencias de la Computacion


I'm looking for the five most important papers (the "must read" papers) in
the following two areas:

Applied Performance Evaluation

Theoretical Performance Evaluation

Anybody out there that can help me out?
Thanks,
	Chris Perleberg
	pchris@dcc.uchile.cl
Xref: sparky comp.arch:12012 comp.sys.intel:2854
From: pcg@aber.ac.uk (Piercarlo Grandi)
Newsgroups: comp.arch,comp.sys.intel
Subject: Re: Superscalar vs. multiple CPUs ?
Date: 31 Dec 92 11:58:03 GMT
	<PCG.92Dec23144916@decb.aber.ac.uk> <Bzpzwq.18q@news.udel.edu>
	<PCG.92Dec27201257@decb.aber.ac.uk> <38194@cbmvax.commodore.com>
Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
Organization: Prifysgol Cymru, Aberystwyth

On 29 Dec 92 20:02:47 GMT, jesup@cbmvax.commodore.com (Randell Jesup) said:

jesup> (Piercarlo Grandi) writes:

pcg> This is another reason for which I think hyperscalar is premature:
pcg> a vector instruction has the very nice property that it implies a
pcg> very definite memory access pattern, as compared with a loop that
pcg> does the same thing. And many important applications have FIFO data
pcg> reference patterns, for which predictive memory accesses are
pcg> essential, and adaptive ones, like those implied by a cache, are
pcg> fatal:

jesup> This is one reason I've been advocating smarter caches,
jesup> particularily the ability to do predictive pre-fetching.  There
jesup> are a couple of ways to set this up: [ ... ]

But should they be called 'caches' then? If they become memory queues,
should not they be called 'memory queues'? Or maybe 'vector registers'?

You seem to agree that making a cache double as an implicit set of
memory queues a la RS/6000 can be fatal; but you still seem to like
making the cache become an *explicit* set of memory queues.

Why not separate the two? They are used for such different purposes, and
in such different ways! I find it fairly odd to have a single bit of hw
be both a vast LIFO repository of recently accessed data and a small
funnel for prefetching.

Maybe you could argue that in this way the queues would not be exposed,
other than in the instruction set. But the trend I seem to understand
is towards exposing the naked hardware to the lusty gaze of the compiler
ever more :-).

jesup> 1.	Instruction sets address, bound, and perhaps amount to
jesup> fetch. [ ... ]
jesup> 2.	Load instruction encodes prefetch-enable and bounding
jesup> size in the instruction.
jesup> in the instruction. [ ... ]
jesup> 3.	Instruction sets register, bound and perhaps size, and
jesup> any load relative to that register causes a prefetch [ ... ]
jesup> 4.	Prefetch instruction is executed earlier in the
jesup> instruction stream to fetch a location. [ ... ]

These look a fairly Ok set of ideas, but in some sense they are all too
"high level". Suppose that there is effect several memory queues; then
multiple prefetch streams could be outstanding. With the four ideas
above the CPU would have to mask completely this. It takes a bit of
bookkeeping to do this. With explicit queues (or something like vector
registers) things are a bit simpler. On the other hand maybe the
difficulty is less than that I imagine.
--
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: lindsay+@cs.cmu.edu (Donald Lindsay)
Newsgroups: comp.arch
Subject: Re: IBM AS/400 is the world's slowest computer
Date: 25 Dec 92 00:52:31 GMT
Article-I.D.: cs.BzsIFK.EMF.2
Organization: School of Computer Science, Carnegie Mellon

kolding@cs.washington.edu (Eric Koldinger) writes:
>The AS/400 uses a tagged memory-system and tagged registers to
>protect capabilities (or pointers, as they call them).  There are
>also a number of operations that only take place on capabilities.
>This makes it rather unlikely that they'd use a stock micro-processor
>from the workstation group.

I don't think that RPG programmers deal with capabilities, so, the
stock microprocessor needs only a stock RPG.

What other languages are of importance on the AS/400? What is the OS
written in, and are capabilities actually explicit at the source
level?

My experience with software-based capabilites has been positive, so
it's not clear to me, offhand, that a stock RS/6000 is out of the
question.


-- 
Don		D.C.Lindsay	Carnegie Mellon Computer Science
Newsgroups: comp.arch,comp.sys.intel