HDTenEightyP/NetNews huggingface dataset:
From: zstern@adobe.com (Zalman Stern)
Newsgroups: comp.arch
Subject: Re: IBM AS/400 is the world's slowest computer
Date: 22 Dec 92 09:23:55 GMT
Organization: Adobe Systems Incorporated

In article <16030@auspex-gw.auspex.com> guy@Auspex.COM (Guy Harris) writes:
> >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).

My understanding is the further down you go in instruction sets on the  
AS/400, the more differences there are between different implementations.  
That is, the "vertical microcode" instruction set is implementation  
dependent. Of course my main complaint with incredibly "high level" machines  
like this is that I've never really been able to understand how they work.  
My disgust level is exceeded about the point someone says "well though,  
that's not the instruction set the hardware implements. We have another  
layer here that..." for the second or third time.

There was an article in one of "the rags" claiming that IBM is going to do a  
64 bit RISC based version of the AS/400. Details on what that means would be  
very interesting. In particular, is it based on PowerPC or is IBM going to  
have two 64 bit RISC architectures floating around. Or is it one of these  
"RISC implementations" rather than a "RISC architecture."
--
Zalman Stern		   zalman@adobe.com		    (415) 962 3824
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
  "Yeah. Ask 'em if they'll upgrade my shifters too." Bill Watterson
Newsgroups: comp.arch,comp.sys.dec,comp.sys.sgi,comp.sys.hp
From: mdchaney@fractal.ucs.indiana.edu (M Darrin Chaney)
Subject: Re: Comparison of Alpha, MIPS and PA-RISC-II wanted
Organization: Indiana University, Bloomington
Date: Thu, 24 Dec 1992 15:35:20 GMT

In article <1992Dec22.201616.5907@ais.com> bruce@ais.com (Bruce C. Wright) writes:
>In article <Bzo3tJ.KGo@usenet.ucs.indiana.edu>, mdchaney@fractal.ucs.indiana.edu (M Darrin Chaney) writes:
>> For stream-lf files, just buffer those blocks, and keep track of where the
>> lf is.  It's not difficult, and you can easily get around the 65534 limit
>> that RMS places on files.  Have fun...
>                     ^^^^^^
>
>Darrin,
>
>Don't you mean `records' where I've underlined the word `files'?  This
>looks like a typo, I'm sure from other things of yours that I've read
>that you're reasonably familiar with VMS.  RMS does unfortunately keep
>the record length in a 16-bit word, hence the limitation.  If memory
>serves there are also a few places where you may get into trouble if
>the record length is > 32766 (signed 16-bit integer) :-(.  
>
>The rest of the article looks to be completely accurate.

Yes, that's a record limit, not a file limit.  I've never ran into a problem
with record lengths between 32767 and 65534, though.  65535 is reserved for
the EOF, coincidently.

>Bruce C. Wright

	Darrin
-- 

mdchaney@iubacs mdchaney@bronze.ucs.indiana.edu mdchaney@rose.ucs.indiana.edu

"I want- I need- to live, to see it all..."
From: jgd@csd4.csd.uwm.edu (John G Dobnick)
Newsgroups: comp.arch
Subject: Re: branch-and-link
Date: 28 Dec 1992 01:35:37 GMT
Organization: University of Wisconsin - Milwaukee
Reply-To: jgd@csd4.csd.uwm.edu
NNTP-Posting-Host: 129.89.7.4
Originator: jgd@csd4.csd.uwm.edu

From article <1hkqk3INNsns@transfer.stratus.com>, by dswartz@sw.stratus.com (Dan Swartzendruber):
> Here's a question for the hardware types: is there any reason either of
> design complexity or performance to not have *all* branches (conditional
> and unconditional) save their origin somewhere (probably in a fast
> dedicated register)? 

Can't speak to the hardware complexity, but it _has_ been done.

The Unisys (formerly Univac) 1100 series machines did this.   Various
models saved the last "n" jump locations ("n" being model dependent)
in part of the fast register stack.  I believe the minimum value
of n was 4.   Even this much "jump history" was quite useful in
debugging certain types of program failure.  (What is saved is the
value of the program counter when the jump is executed -- this is
usually one past the actual jump.  For conditional jumps, this
address is saved only if the jump is taken.)

I'm not quite sure what the specs are on the more recent models of the
2200 series machines (successors to the 1100's), but I think they 
save at least 8 previous jump locations. 

The Operating system also has the facility to detect "jump history
full" conditions and trap to a routine to save these values in main
memory.  This allows the OS to maintain a much longer jump history --
useful for OS debugging -- at the cost of lessened system performance.

Except for the "special" use of this in OS debugging, there was _no_
performance hit for the feature.  In fact, it was always "on" for
normal user code.  When the jump history filled, it "wrapped".   There
was a hardware status bit set to flag where the "oldest" of the 
history entries was, so one could make sense of them.

All in all, a _quite_ useful feature.  More machines should have it!

-- 
John G Dobnick                          ATTnet: (414) 229-5727
Computing Services Division             INTERNET: jgd@uwm.edu
University of Wisconsin - Milwaukee     UUCP: uunet!uwm!jgd

"Knowing how things work is the basis for appreciation,
and is thus a source of civilized delight."  -- William Safire
Newsgroups: comp.arch
From: lindsay+@cs.cmu.edu (Donald Lindsay)
Newsgroups: comp.arch
Subject: Re: Def of a workstation
Date: 3 Jan 93 21:31:15 GMT
Article-I.D.: cs.C0Ars4.5sD.2
Organization: School of Computer Science, Carnegie Mellon


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

"A workstation is a personal computer which allows you to get a
variety of work done, in a relatively unfettered way, in an
environment with coworkers.  Today, that means three things.

1) the workstation has to have at least 800,000 pixels.
2) the workstation has to network very naturally.
3) the workstation has to be multiprogrammed."

If his PC fits this, then it *is* a workstation. Computers are tools,
not religions.
-- 
Don		D.C.Lindsay	Carnegie Mellon Computer Science
From: dswartz@sw.stratus.com (Dan Swartzendruber)
Newsgroups: comp.arch
Subject: Re: branch-and-link
Date: 2 Jan 93 03:02:19 GMT
Organization: Stratus Computer, Inc.
NNTP-Posting-Host: redondo.sw.stratus.com

In article <GLEW.92Dec31162920@pdx007.intel.com>, glew@pdx007.intel.com (Andy Glew) writes:
> 

[deleted]

> 
> Other, quite reasonable, microarchitectures can't do it at all without
> slowing down (or requiring a PC to be attached to every instruction as
> it flows through the pipe).
> 
> When you can do it, great! But don't slow down other implementations
> for a debug feature that is not in use most of the time.
> 

Maybe I'm missing something here.  I only care about the last xfer-of-control instruction
which was actually executed before an exception occurred.  Given that, I'm not sure why
you care about any intermediate state of instructions in the pipeline.  


-- 

#include <std_disclaimer.h>

Dan S.
From: grover@brahmand.Eng.Sun.COM (Vinod Grover)
Newsgroups: comp.arch
Subject: Re: Alpha Architecture Quirks
Date: 22 Dec 1992 18:12:31 GMT
Organization: Sun
NNTP-Posting-Host: brahmand

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?  

The benchmark 048.ora in SPECfp92 is very sensitive to the latency of
sqrt. 

Vinod Grover
Newsgroups: comp.arch
Subject: Re: VMS vs "Unix"
From: dougcc@brt.deakin.edu.au (Douglas Miller)
Date: 23 Dec 92 01:53:29 EST
Followup-To: comp.arch
Organization: C&CS, Deakin University

In article <42743@sdcc12.ucsd.edu>, xm9@sdcc12.ucsd.edu (richard g. adair)
writes:

> 
> No, UNIX is better for these reasons:
> 
> 	pipes
yes
> 	make
no, several flavors of make are available for VMS
> 	light sub-processes
> 	the path
yes, yes
> 	transparent networking
> 	network file sharing
no, no, take your pick of VMScluster, DNS, NFS, DECnet/OSI, TCP/IP
> 	no RMS
don't fight it, feel it!
> 	choice of shells
no, VMS provides DCL and posix shells standard, others should be possible
> 	machine independant, choice of vendor
VMS gives you this (more so than many "Unix"es).  Just keep your
application standards compliant, so you can move it anover O/S when the
fancy takes you.
> 	vendor price and speed wars
no, VMS is as much caught up in this as any other O/S
> 	better hardware
VAX and AXP not good hardware?  I beg to differ
> 	graphics
What's wrong with graphics under VMS?
> 	it does't have DEC-this DEC-that all over (gak!)
There is lot less of this than popularly supposed.  Although they can
sometimes produce white elephants, most DEC produced enhancements add
useful functionality and/or standards compliance not present in the
original.
> 	simplicity
nothing is simple :-)
From: davidc@panix.com (David B. Chorlian)
Newsgroups: comp.arch
Subject: Re: <None> (Should be Open Systems, bloody NEWS system...)
Date: 25 Dec 92 01:18:51 GMT
Organization: PANIX Public Access Unix, NYC

In <1992Dec23.212321.26522@ryn.mro4.dec.com> pjdm@chmeee.enet.dec.com (Peter Mayne) writes:


>In article <id.CG2W.R8A@ferranti.com>, peter@ferranti.com (peter da silva) writes:

>>That's right. The UNIX programming model. The point is that the UNIX API is
>>very high level, and can be modified to provide any capability I've ever
>>heard of without breaking it. There is NO excuse for any new operating
>>system after about 1984 or 85 to use anything lower level. It increases the
>>cost of software design, increases the cost of education and training, and
>>decreases the amount of commonly available high quality software.

>OK, try this. VMS has something called an AST (Asynchronous System Trap) which
>is similar to a user-mode interrupt. This may occur at any time: for instance,
>an asynchronous I/O can call an AST routine when the I/O completes. When the
>AST routine completes, control returns to the code that was executing at the
>time the AST occurred. (The analogy in NT is the APC, or Asynchronous
>Procedure Call.)

>Now, much of the run-time stuff in UNIX is non-reentrant. In particular, the 
>use of errno springs to mind. If the AST (or APC) was introduced into the
>UNIX model, how can I use these non-reentrant routines safely in an AST
>routine without screwing things up?

Use the right Unix.  Concurrent (formerly Masscomp) RTU provides
user-level AST's, reentrant (and preemptable) run-time stuff in UNIX
kernal routines, without any problem.  Much of the device-driver
libraries for asynchronous devices (data acquisition, programmable
graphics system, vector processor, etc.) is written with AST's.  The
model for the user is a more sophisticated signal interface.
(Masscomp was started by people from DEC, I recently learned.)

>Peter Mayne                     | My statements, not Digital's.
>Digital Equipment Corporation   |
>Canberra, ACT, Australia        | "AXP!": Bill the Cat

David B. Chorlian
Neurodynamics Lab
SUNY/HSCB 
davidc@panix.com

-- 
David B. Chorlian
Neurodynamics Lab
SUNY/HSCB 
davidc@panix.com
Newsgroups: comp.arch
From: mo@gizmo.bellcore.com (Michael O'Dell)
Subject: Re: reentrant, etc...
Keywords: 
 
Reply-To: mo@bellcore.com
Organization: Center for Chaotic Repeatabilty
Date: Sat, 2 Jan 93 22:04:00 GMT

OS/360 MFT & MVT back in the late 60s/early 70s had full support for
threads, and distinguished between reentrant and serially-reusable modules
(not to mention fully async I/O and many other things, some good). And of
course, OS/360 wasn't the first commercial operating system to support
such notions (Burroughs MCP on the 5500 may come close to the first,
though).

As for "horrid", a better description is "misunderstood" or "well
disguised".  The fact that all the facilities were available only
to ASM programmers did much to conceal the horsepower there.
There were certainly things the OS/360 didn't do very well, but they
didn't lack for richness.  Actually, that was the greatest weakness:
OS/360 had everything in the world EXCEPT a simple way to do something.  

	"All mechanism but no policy."

Does this sound familiar?

	-Mike

Bellcore?? Bellcore isn't allowed to hold opinions. Any here were
found along the road somewhere down through the ages.
From: gorton@sousa.tay.dec.com (Richard Gorton)
Newsgroups: comp.arch
Subject: Re: IBM AS/400 is the world's slowest computer
Date: 30 Dec 92 22:11:29 GMT
Reply-To: gorton@sousa.tay.dec.com (Richard Gorton)
Organization: Digital Equipment Corporation, Littleton MA


In article <1992Dec18.165950.15013@webo.dg.com>, lewine@cheshirecat.webo.dg.com (Donald A. Lewine) writes:
|>From: lewine@cheshirecat.webo.dg.com (Donald A. Lewine)
|>Subject: IBM AS/400 is the world's slowest computer
|>
|>IBM is currently running full-page Ads that claim "The AS/400
|>is the world's most powerfull computer with the industry's best
|>price/performance(*)"
|>
|>"(*) According to the TPC-C benchmark results published through
|>     12/3/92"
|>
|>IBM does not point out the the AS/400 is the only computer with
|>TPC-C results published as of 12/3/93.  The AS/400 is also the
|>world's slowest and most expensive computer by the same benchmark.

And it has a WHETSTONE of 1 (ONE).  Batch compiles ran faster
when the system thought it was heavily loaded as opposed to effectively
single-user mode.

Really.  (I know someone whom worked on a FORTRAN compiler for it)

--
Richard Gorton		Alpha AXP Migration Tools - Digital Equipment Corp.
Reply-to: gorton@tallis.enet.dec.com
All standard disclaimers apply.
From: pj@sam.wpd.sgi.com (Paul Jackson)
Newsgroups: comp.arch
Subject: Re: big + little endian (was: Comparison of Alpha, MIPS ..)
Date: 31 Dec 1992 00:04:56 GMT
Organization: Silicon Graphics, Research & Development
Distribution: world
Reply-To: pj@sgi.com
NNTP-Posting-Host: sam.wpd.sgi.com

In article <1992Dec30.193752.9796@oracle.us.oracle.com>, akao@.com (Adam Kao) writes:
|> In article <1hquujINNmov@fido.asd.sgi.com> pj@sgi.com writes:
|> >In article <28164@dog.ee.lbl.gov>, torek@horse.ee.lbl.gov (Chris Torek) writes:
|> >|> 01101001 may mean `105' (big-endian) or `150' (little-endian)
|> >
|> >Big and little endian refer to the order of bytes within words,
|> >not to the order of bits within bytes.
|> 
|> You're teaching grandmother how to suck eggs ...

Ok - as several folks pointed out - endianness can refer to
various orderings, of bits, bytes, words, ...

And apparently Chris Torek is a certified old-timer.

Oh well.

-- 

				I won't rest till it's the best ...
				Software Production Engineer
				Paul Jackson (pj@sgi.com), x1373
Newsgroups: comp.arch
From: conor@lion.inmos.co.uk (Conor O'Neill)
Subject: UNIX fseek time (was Re: Comparison of Alpha, MIPS and PA-RISC-II wanted)
Organization: INMOS Limited, Bristol, UK
Date: Thu, 24 Dec 1992 11:24:22 GMT

In article <fW0DHHa@quack.sac.ca.us> dfox@quack.sac.ca.us (David Fox) writes:
>
>>Honestly it's the definition of IO that's missing here. C/UNIX
>>have standardized on NOT sequential but flat direct-access files
>>for the filesystem and sequential access for pipes, some devices,
>>input format for most system commands, etc.
>
>That's an interesting point.  I am not an expert in Unix file access
>but I'd guess that Unix has standardized on both sequential
>and flat direct-access files, and that sequential access is just a
>special case of direct access: read so many bytes sequentially from
>a randomly-accessible point in a file.  Or, it has standardized on
>sequential file access, and that direct access is a special case, using
>the fseek() library call.

But, given that 'fseek' is incredibly slow on most Unix systems,
one could almost assume that Unix doesn't support random-access files.

---
Conor O'Neill, Software Group, INMOS Ltd., UK.
UK: conor@inmos.co.uk		US: conor@inmos.com
"It's state-of-the-art" "But it doesn't work!" "That is the state-of-the-art".
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: 28 Dec 1992 16:09:02 -0000
Organization: Hitachi Computer Products, OSSD division
NNTP-Posting-Host: duca.hi.com
Summary: it depends

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?

While it's true that there is not necessarily any I/O initiated by the
call, fseek() generally invokes the lseek() system call, so you do
have that overhead.

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.

  -- David Wright, Hitachi Computer Products (America), Inc.
     wright@hicomb.hi.com


Newsgroups: comp.arch
From: bret@technix.mn.org (Bret Indrelee)
Subject: AST on UNIX
Summary: How can you do AST on UNIX?
Organization: Private System - Saint Paul, MN
Date: Thu, 24 Dec 1992 18:09:08 GMT

In article <1992Dec23.212321.26522@ryn.mro4.dec.com> Peter.Mayne@cao.mts.dec.com writes:
>
>In article <id.CG2W.R8A@ferranti.com>, peter@ferranti.com (peter da silva) writes:
>
>>That's right. The UNIX programming model. The point is that the UNIX API is
>>very high level, and can be modified to provide any capability I've ever
>>heard of without breaking it. There is NO excuse for any new operating
>>system after about 1984 or 85 to use anything lower level. It increases the
>>cost of software design, increases the cost of education and training, and
>>decreases the amount of commonly available high quality software.
>
>OK, try this. VMS has something called an AST (Asynchronous System Trap) which
>is similar to a user-mode interrupt. This may occur at any time: for instance,
>an asynchronous I/O can call an AST routine when the I/O completes. When the
>AST routine completes, control returns to the code that was executing at the
>time the AST occurred. (The analogy in NT is the APC, or Asynchronous
>Procedure Call.)
>
>Now, much of the run-time stuff in UNIX is non-reentrant. In particular, the 
>use of errno springs to mind. If the AST (or APC) was introduced into the
>UNIX model, how can I use these non-reentrant routines safely in an AST

While you are at it, don't forget to include a separate 32-bit value
passed to the AST.  The AST is fully queue'd, and if you send 32 ASTs
before the application executes it's handler the application will still
see ALL the ASTs with their separate 32-bit value.

If you can make this work, now port it to AIX, SunOS, Solaris, Ultrix,
IRIX, and HP-UX.  Those are the only environments I currently would like
it on, I'm sure there would be more within a few months.


BTW, if you really want to emulate it then set the priority of the AST
handler above the scheduler (after locking it in memory, of coarse) so
that it can have high priority.

---

In my environment, ASTs and ASYNC I/O are the two best features of VMS.
Event flags come close, but not quite as valuable.

-Bret
-- 
------------------------------------------------------------------------------
Bret Indrelee               |         Nature Adores Chaos
email: bret@technix.mn.org  |   
Newsgroups: comp.arch
From: rsrodger@wam.umd.edu (Yamanari)
Subject: Def of a workstation (a lark)
Organization: University of Maryland, College Park
Date: Sun, 3 Jan 1993 05:29:30 GMT

	We all spend time with strange people for New Years..
 
	So I'm trying to explain to a friend who has just bought a 
	new Gateway system (dx2-66, lb ATI ultra @ 1024x768, running
'	OS/2) what a workstation is (he asked, because I was discussing
	the schools computer lab and used the word), and, well.. 
 
	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).  

	At first I was tempted to talk about UNIX or RISC, but these
	were less than satisfactory (UNIX because he could be running
	UNIX, and RISC sounds deficient--those old M68k based Suns are
	still workstations...and then there's the 386i...)..
 
	Anyone?  Come to think of it, it's pretty muddled to me, too.


-- 
	Blaming "society" for your problems is like blaming clouds for rain.
         ---  boycott == censorship == closed mindedness == cowardice  ---
	      "Psalms 23:1  The LORD is my shepherd; I shall not want."  
		Shepherds are for sheep.   -----      Pain teaches.
From: willmore@iastate.edu (David Willmore)
Newsgroups: comp.arch
Subject: Re: Any new instructions in a i486?
Date: 24 Dec 92 15:27:42 GMT
Organization: Iowa State University, Ames IA

rmk@rmkhome.UUCP (Rick Kelly) writes:

>Exactly.  I would almost bet that it is some weird timing problem.

That's where my money is.  Linux, the PD unix system, had quite a 
few problems with race conditions within the filesystem code in
earlier versions.  Each new fast processor that it got moved to 
found more and more.  It wouldn't suprise me that the DLC does
something (read some series of instructions) in a sufficiently
different amount of time than the 486 does.  That would be enough.
I wouldn't trust a company that can't remove such simple problems
from its code.  Then again, I don't trust NeXT anyway. :)

Cheers, 

David Willmore
willmore@iastate.edu