HDTenEightyP/NetNews huggingface dataset:
From: sysmgr@king.eng.umd.edu (Doug Mohney)
Subject: Re: Def of a workstation (a lark)
Date: Mon, 04 Jan 93 15:55:44 GMT
Organization: Computer Aided Design Lab, U. of Maryland College Park
Reply-To: sysmgr@king.eng.umd.edu

In article <1i5vdmINN3ek@cs.widener.edu>, YOUNG@tattoo.cs.widener.edu (Rob Young) writes:
>In <1993Jan3.052930.27869@wam.umd.edu> rsrodger@wam.umd.edu writes:
>
>> 	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.
>> 
>
>The bus.  At least that is how DEC is differentiating their Alpha PC (yet
>to debut) from their workstations.  The PC will have the same chip (125
>MHz) as the yet to debut low-end workstation.  The workstation is Turbochannel
>based, the PC EISA.

Hm. Does this mean the HP Workstations, which use EISA, are really PeeCees
in disguise? :-)

Actually, a "workstation" would have the following vague and fuzzy definitions,
according to the book of Moo:

	A) One big f@#$ing screen, which is nearly as expensive as the CPU.
	   Don't bother braggin' unless it's 17" or better.

	B) Designed to be seamless-ly intergrated into Internet and can run
	   news. :-) PC's don't count here because you have to:
		1) buy an Ethernet card 
		2) Add drivers to run TCP/IP
                                        
Hmm... 

On second thought, I'll take the supreme court version,

		"I'll know it when I see it"

given some people are using PCs for "workstation"-like work.

                    I have talked to Ehud, and lived.
  -- >                  SYSMGR@CADLAB.ENG.UMD.EDU                        < --
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.arch
Subject: Re: Def of a workstation (a lark)
Date: 5 Jan 93 15:10:54 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <1993Jan05.004806.14107@news.mentorg.com>, mbutts@mbutts.mentorg.com (Mike Butts) writes:
| The fundamental difference between a workstation and a well-configured 486
| PC is the software-readable serial number (hostid) in the workstation.  
| 
| Think about it.

  You may be right. Certainly if you accept a Sun 4/100, or a
Sun3/anything, or an HP 750 as workstations, you have a hard time
finding something lacking in a good 486+UNIX setup.

  Oddly, when we split our site into two class B subnets (out of IP
addresses) the "PC net" included a bunch of Suns used for NFS mounts
from DOS and TOPS mounts from Macs. The workstation subnet includes a
number of Intel based workstations. A lot comes down to "what you do
with it."

  The person who said that a workstation must use a GUI certainly let
out Sun, the default boot mode is single screen dumb terminal. I guess
that makes the Mac a workstation because it *does* boot a GUI.

  For my money, if it runs UNIX (or POSIX) and supports TCP and NFS it's
a workstation. Otherwise it's a something else.
-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
    Keyboard controller has been disabled, press F1 to continue.
From: torbenm@diku.dk (Torben AEgidius Mogensen)
Newsgroups: comp.arch
Subject: Re: Swap byte instruction - how high is the win?
Date: 8 Jan 93 11:17:31 GMT
Organization: Department of Computer Science, U of Copenhagen

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

>Subject line almost says it all. Many modern processors have an
>instruction to swap the bytes in a word. Can one quantify the
>win of using this instruction vs. the equivalent sequence of
>instructions? How much silicon is needed? What applications
>win the most and how much? There must be *some* resaon why the
>RISC folks put it in, right?

This is mostly so big-endian machines can simulate little-endian
behaviour and vice versa (see discussion elsewhere in this group).

The savings depend on how long it takes to swap the bytes using other
instructions. Here is an example from an ond posting by
RWilson@acorn.co.uk (one of the designers of the ARM processor).

>ARM's byte sex is as VAX and NS32000 (little endian). The byte sex of
>a 32 bit word can be changed in 4 clock ticks by:
>      EOR R1,R0,R0,R0R #16
>      BIC R1,R1,#&FF0000
>      MOV R0,R0,ROR #8
>      EOR R0,R0,R1,LSR #8
>which reverses R0's bytes. Shifting and operating in one instruction
>is fun. 

Newer processors (including the new ARMs) tend to have selectable
endianness instead of byte swap instructions.

	Torben Mogensen (torbenm@diku.dk)
Newsgroups: comp.arch
From: larry@eco.twg.com (Lawrence B. Henry III)
Subject: Re: Comparison of Alpha, MIPS and PA-RISC-II wanted
Reply-To: larry@eco.twg.com
Organization: The Wollongong Group (East Coast Operations)
Date: Fri, 8 Jan 93 21:31:29 GMT


In article <C0K3HC.A8B@dscomsa.desy.de>, hallam@zeus02.desy.de (Phill
Hallam-Baker) writes:
|>Has anyone any idea what the DECC RTL is like? Has anyone tried it on a VAX?
|> (is it avaliable for VAX??) Comparing DECC on Alpha to VAXC is not really
|>on...anything running on the alpha tends to look fast.
|>

From what DEC said at DECUS they are getting ready to start Field Testing the
DEC C compiler on VAX VMS.

-Larry.
Newsgroups: comp.arch
From: veijalai@klaava.Helsinki.FI (Tony Veijalainen)
Subject: FP-number cache? Unclocked VLSI design.
Organization: University of Helsinki
X-Newsreader: TIN [version 1.1 PL6]
Date: Tue, 5 Jan 1993 08:54:15 GMT


This is my third posting in my cracy thoughts series :-)

There is common trend towards harwardizing the memory lane by separating
instructions and data to separate caches with own bus to other parts of
CPU.

On the other hand FPU-units that appear more and more are in modern big
CPU:s are quite far conceptually from other operations.  I have
suspision that FP-arithmetic tends to cluster quite heavily, and because
of traditional efficiency thinking and fixed number arithmetic in
business applications some big parts of programs are integer only (not
much FP-operations in interupt code for example :-). 

So have somebody researched the havoc FPU-instructions make to general
data cache? Is there possible advantage of having FP-number (with
separate bus to FPU-register file) and fixnumber caches with advantages
outdoing the cost on CPU (like diminiching the general cache size, is
this over specialization?). 

I am very inspired about Dick Pountains articles on ARM architecture in
Dec 92 (ARM6) and Jan 93 (asyncronic ARM6) (Mayby it has something to do
with the thing that I own ARM2 based ancient Acorn Archimedes A310 have
something to do with it :-) Anyone of you real experienced experts care
to comment on these especially the unclocked VLSI design.  I can see
some RISC -perspectives attacking the new wind mill: enormous clock
circuitery in "More Risc Than Your Risc" Alpha processor.  Jan 93 ibid
article mentiones 1/4 of chip area cost of clock circuitery in current
Alpha architecture implementation.  Care to comment on architectual
suitability of asyncronism instead of superpipelining in Alpha
architecture.  I do like Alpha very much thank you, but this one sided
view of architectual development toward Cisc-scale complexity of
pipeline magic and clocking instead of simple asyncronic circutery is
mayby mistake, is it not?


-- 
Tony Veijalainen	e-Mail: Tony.Veijalainen@helsinki.fi (preferred)
 		(finger veijalai@plootu.helsinki.fi for more information)
From: cs89rdb@brunel.ac.uk (Roger D Binns)
Newsgroups: comp.arch
Subject: Re: IBM AS/400 is the world's slowest computer
Date: 4 Jan 93 17:25:36 GMT
Organization: Brunel University, Uxbridge, UK
X-Newsreader: TIN [version 1.1 PL8]

: In article <1993Jan1.102554.28575@metapro.DIALix.oz.au> bernie@metapro.DIALix.oz.au (Bernd Felsche) writes:

: >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.

The answer at the end of the day is always software.  It is commonly
ignored in the my Amiga is better than your AS/400 is better than your Unix
which knocks out VMS type debates.  At the end of the day, users want to
run software, and get results from that software in such a way that it
benefitted them to use the system in the first place.  Show me someone who
adds one to one on a computer.

Whether or not to use a multi user box will be determined by the software.
If you don't need access to resources (eg a word processor), it doesn't
matter what is underlying it in terms of os and hardware, providing you can
print and save, and there is a decent interctive response.

When you need a lot of people accessing scarce resources, the situation is
not cut and dried.  It will depend on whether you need them for a long
time, close to you, or if access can be batched.  Consider peripherals such
as modems, scanners and printers.

The costs and facility of your software, and the hardware neccesary to run
it will be the end determiner of what you do.  This is why msdos exists,
and does very well, even though it is 'technically' inferior.

I paid #1500 for word for windows, and got a pc free, not the other way
round. (#  is UK pounds, approx 1.7$ per #).

Roger
-- 
+=============================================================================+
| cs89rdb@brunel.ac.uk     Roger Binns    Brunel University - UK              |
|:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
| Do your bit to destroy the American economy by overwhelming their legal     |
| system - buy an Intel chip to run your Lotus software TODAY.                |
+=============================================================================+
Xref: sparky comp.arch:12244 comp.sys.ibm.pc.hardware:35573
From: kxs5829@ultb.isc.rit.edu (K.X. Saunders)
Subject: Re: Def of a workstation (a lark)
Originator: kxs5829@ultb
Organization: Rochester Institute of Technology
Date: Tue, 5 Jan 1993 05:54:47 GMT

In article <WAYNE.93Jan3184216@backbone.uucp> wayne@backbone.uucp (Wayne Schlitt) writes:
<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).
<
<
<This is almost certain to cause a long string of definitions, and
<quite possible a flame war or two.


	Quite right ;-).

	I would define a workstation as the hardware that ~$15000 will buy at
any point in time, running a Real OS(tm). 

	- Kyle

-- 
+-"Remember, [MS]DOS is sort of a UNIX deviant already" - dmoscny@piglet.-----+
|    // Only /\          kxs5829@ultb.isc.rit.edu                 cincinatti. |
| \ //      /--\MIGA     kyle@nick.csh.rit.edu                    oh.us       |
| \X/ SQLdb - $40 rdbms  Rochester Institute of Technology                    |
Newsgroups: comp.arch,comp.sys.dec,comp.sys.sgi,comp.sys.hp
From: hallam@zeus02.desy.de (Phill Hallam-Baker)
Subject: Re: Comparison of Alpha, MIPS and PA-RISC-II wanted
Reply-To: Hallam@zeus02.desy.de
Organization: Deutsches Elektronen Synchrotron, Experiment ZEUS bei HERA
Date: Fri, 8 Jan 1993 22:22:23 GMT

In article <3623363@zl2tnm.gen.nz>, don@zl2tnm.gen.nz (Don Stokes) writes:

|>zrepachol@cc.curtin.edu.au writes:

|>Exactly.  Well, you can pull kludgery with magic numbers....
|>
|>> Never a truer word spoken... The intertwining of the C language and Unix IO
|>> is a *HUGE* mistake.
|>
|>I personally believe VAXCRTL is a serious impediment to DEC's claims of 
|>"openness" in VMS.  Life's too short to have to go re-implementing half
|>the RTL whenever you try to get anything done because the standard stuff
|>is too slow, too buggy or more often than not, both.

Has anyone any idea what the DECC RTL is like? Has anyone tried it on a VAX? (is
it avaliable for VAX??) Comparing DECC on Alpha to VAXC is not really on...
anything running on the alpha tends to look fast.

--

Phill Hallam-Baker
From: ken@sugra.uucp (Kenneth Ng)
Newsgroups: comp.arch
Subject: Re: Swap byte instruction - how high is the win?
Date: 12 Jan 93 01:50:29 GMT
Organization: Private Computer, Totowa, NJ

In article <PRENER.93Jan7233525@prener.watson.ibm.com: prener@watson.ibm.com (Dan Prener) writes:
:The win is approximately zero for general code.  But it is significant
:for emulating a processor with the opposite byte order.

And if you are using something like TCP/IP, you are emulating a network
processor (ie: network byte ordering).

-- 
Kenneth Ng
Please reply to ken@eies2.njit.edu for now.
Apple and AT&T lawsuits: Just say NO!
Newsgroups: comp.arch
From: jfc@athena.mit.edu (John F Carr)
Subject: Re: Swap byte instruction - how high is the win?
Organization: Massachusetts Institute of Technology
Date: Fri, 8 Jan 1993 22:49:06 GMT

In article <1993Jan8.111731.19116@odin.diku.dk>
	torbenm@diku.dk (Torben AEgidius Mogensen) writes:

>Newer processors (including the new ARMs) tend to have selectable
>endianness instead of byte swap instructions.

The RS/6000 has a duplicate set of load and store instructions that
byte-swap, but no register to register byte swap instruction.  The
store multiple and string instructions only come in big-endian forms,
but those tend to be used when byte reversal isn't important (it
doesn't matter if the saved registers on the stack are byte swapped,
as long as they are correct once restored).

--
    John Carr (jfc@athena.mit.edu)
Newsgroups: comp.arch
From: mbutts@mbutts.mentorg.com (Mike Butts)
Subject: Re: Def of a workstation (a lark)
Date: Tue, 05 Jan 1993 00:48:06 GMT
Organization: mentor
Keywords: 
Followup-To: 

The fundamental difference between a workstation and a well-configured 486
PC is the software-readable serial number (hostid) in the workstation.  

Think about it.
-- 
Mike Butts   mbutts@qcktrn.com    Research Engineering Mgr.    503-685-1302 
Quickturn Systems, Inc.,  8005 SW Boeckman Road, Wilsonville, Oregon  97070
My opinions are my own, and aren't necessarily shared by Quickturn Systems.
Newsgroups: comp.arch
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Subject: Re: A theory for Big & Little Endian's origin
Organization: Purdue University Statistics Department
Date: Fri, 8 Jan 1993 13:12:43 GMT

In article <1iinltINNi0l@darkstar.UCSC.EDU> haynes@cats.ucsc.edu (Jim Haynes) writes:
>
>In article <1iig7aINNtc@spim.mti.sgi.com> jackc@vermont.mti.sgi.com (Jack Choquette) writes:
>>For reasons explained in previous posts, humans (who read left to right)
>Well, now, some of them do and some of them don't.  How about Big Endian
>for the West, and Little Endian for the East (starting at Israel and
>the Arab nations and going to Japan)

This has been almost beaten to death, but there are many Eastern
civilizations which had both left-to-right reading and Big Endian
numerations, including the Hindu writings which were the first use
of decimal notation with the same characters in all places.

Also, when Hebrew texts use the traditional representation of numbers
by Hebrew letters, it is definitely Big Endian.  To my knowledge, this
seems to be universal; Little Endian occurs when a system of writing 
in one direction directly adopts a system of numeration going in the
other direction.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@snap.stat.purdue.edu (Internet, bitnet)  
{purdue,pur-ee}!snap.stat!hrubin(UUCP)
From: woodacre@sgi.com (Michael Woodacre)
Newsgroups: comp.arch
Subject: Re: How does an R4000-style cache work?
Keywords: Write-back Cache
Date: 7 Jan 93 20:41:36 GMT
Followup-To: comp.arch
Organization: mips technolgies
NNTP-Posting-Host: krell.mti.sgi.com

In article <1993Jan6.235455.25425@Princeton.EDU>, awolfe@moo.Princeton.EDU (Andrew Wolfe) writes:
|> I am unclear on the timing involved when write misses occur on a write-back
|> cache (like in the R4000).  Perhaps someone can clarify.
|> 
|> When a write is attempted - a virtual index is used to select a cache line
|> and a virtual offset selects bytes within that line.  This happens during
|> the DF stage in the R4000.  The memory can then be accessed during the DS
|> stage.  I assume that the tag is read at this time.  If a write is allowed
|> to occur at this time - it may destroy data in the cache.
|> 
|> The tag is checked at the next stage (TC).  If the tags match - all is OK -
|> but if the tags do not match, then I have written over the previous data in
|> the cache.  If I delay stores until after the tag check - then the memory is
|> busy with another instruction in the pipeline.
|> 
|> 
|> 
|> I can conceive of several possible solutions:
|> 
|> 1)  Always save a copy of the overwritten line (for writeback).
|> 
|> 2)  Delay the write - then simultaneously read and write the cache.
|>     (write from instruction in TC, read from instruction in MS)
|> 
|> 3)  Delay the write - then stall the pipeline on a hit or miss if the next 
|>     instruction is a load.
|> 
|> The first two require a heavy-duty dual-ported cache.  The third requires
|> stalls that I cannot find documented.
|> 
|> What method is really used to solve this problem in the R4000 and similar
|> write-back caches?
|> 
|> 
|> -- 
|> --------------------------------------
|> Andrew Wolfe
|> Assistant Professor
|> Department of Electrical Engineering
|> Princeton University

The cache is accessed during the df/ds stages to read the tag, but the
write is not done at this time. The data to be stored is placed in a store
buffer and written into the cache at a later stage. The data cache has
seperately indexed data and tag arrays to allow this to work without 
adding additional stalls into the pipeline. Data in the store buffer is
written into the cache when there is spare bandwidth to the cache (when
there is a cycle when we are not accessing the cache for a load).

The store buffer obviously has logic to allow the data in it to be bypassed
to any other operations that need the data before it has been retired into
the cache.

Hope this helps,

Cheers,
Mike

-- 
   Michael S. Woodacre | Phone: (415) 390 4175
UUCP: {ames,pyramid,decwrl}!sgi!woodacre OR woodacre@sgi.com
USPS: MIPS Technologies Inc, M/S 10U-178,
      2011 N. Shoreline Blvd, Mountain View, CA 94039
From: mshute@cs.man.ac.uk (Malcolm Shute)
Newsgroups: comp.arch
Subject: Re: Def of a workstation (a lark)
Date: 5 Jan 93 12:08:01 GMT
Organization: Dept Computer Science, University of Manchester, U.K.

>In article <1993Jan3.052930.27869@wam.umd.edu> rsrodger@wam.umd.edu (Yamanari) writes:
>> 	Can anyone give me a definition of workstation, other than 

In article <WAYNE.93Jan3184216@backbone.uucp> wayne@backbone.uucp (Wayne Schlitt) writes:
>* A workstation must be network ready.
>  This doesn't mean that you can't have one workstation sitting
>  somewhere, but you must be able to add additional workstations easily.

For me, you've hit the nail on the head, here... as did a later poster
by observing, rather flippantly, that you are more likely to have to login
on a workstation than on a PC.

A personal computer, it would seem to me, is a computer that is for one person's
personal use.  A workstation is a station which is available for doing work,
presumably by anyone who can demand it.

My workstation here is in a locked office... but anyone on the network
can send work to it, or even remotely login to it.  I would say that if it
weren't for this property, that I would have a PC connected to a network.
Similary, as Wayne points out, it is equally possible to have a WS which is
not (yet) connected to a network... but is ready to be so.

Just my thoughts, anyway...
I look forward to being shown the error of my logic :-)
--

Malcolm SHUTE.         (The AM Mollusc:   v_@_ )        Disclaimer: all
Newsgroups: comp.arch
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.arch
Subject: Re: Swap byte instruction - how high is the win?
Date: 10 Jan 93 05:56:50 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In article <willmore.726621153@class1.iastate.edu>, willmore@iastate.edu (David Willmore) writes:
> ...
> This makes the whole issue of NextStep 486 strange.  If the purported
> reason that NextStep is only supported for the 486 is to sell more 486's
> then why don't they sell a 386 version with all the bswap's replaced by
> the long and slow series of 386 instructions which it takes to emulate
> it?....


The sequence of 3 386 instructions for byte-swapping EAX is not very
long or slow, especially in view of its likely frequency.


Vernon Schryver,  vjs@sgi.com
Newsgroups: comp.arch
From: dbg@slac.stanford.edu (David B. Gustavson)
Subject: Re: Swap byte instruction, Endianness
Followup-To: comp.arch
Organization: SLAC Computation Research Group
Date: Sat, 9 Jan 1993 03:08:20 GMT

In article <1993Jan8.111731.19116@odin.diku.dk>, torbenm@diku.dk (Torben
AEgidius Mogensen) wrote:
> 
> Newer processors (including the new ARMs) tend to have selectable
> endianness instead of byte swap instructions.
> 
That's too bad, because selectable endianness isn't well defined and won't
solve the problem in general. The trouble becomes obvious when you consider
general interconnected systems with multiple bridges connecting data paths
of various widths. Unless these bridges agree to preserve the relative byte
addresses of all data, it gets thoroughly shuffled as it propagates from
one convention to another. 

Thus the principle of Address Invariance has (after many person-years of
arguments) been adopted by the IEEE bus standards (like 1596 SCI and 896
FutureBus+). One of the SCI follow-on standards addresses the final part of
this problem, P1596.5 Data Transfer Formats. The idea is to give the
compiler enough information so that it can unscramble the data in a
heterogeneous environment, generating only those swaps that are needed.
Efficient swap instructions work well for this, but selectable endianness
doesn't hack it.
Contact the P1596.5 chair for more info, David James: dvj@apple.com.

By the way, the clearest definition of endianness that I know is:

In a Big-endian machine, the significance of bytes (or bits) in any data
item decreases as the address (byte or bit number) increases.

In a Little-endian machine, the significance of bytes (or bits) in any data
item except character strings increases as the address (byte or bit number
increases. For character strings the significance decreases.


Numbering bits and bytes oppositely is a loser, as Motorola discovered when
they added the Bit Field instructions in the 68020. They are not
independent choices once instructions exist that couple them. 

Endianness describes how data gets loaded into registers, not how it gets
mapped to bus lines or other hardware. For multiplexed buses, an additional
descriptor is needed, which distinguishes "Big addressan" and "Little
addressan" sexes. (Ugh, but that's the term that won out.) The existence of
this independent choice confuses the endianness arguments considerably, and
was a major cause of the confusion that caused selectable endianness to be
implemented incorrectly in some processors. 

--------------------------------------------------------------
-- David B. Gustavson, Computation Research Group, SLAC, POB 4349 MS 88,
    Stanford, CA 94309   tel (415)961-3539  fax (415)961-3530
-- What the world needs next is a Scalable Coherent Interface!
-- Any opinions expressed are mine and not necessarily those
   of the Stanford Linear Accelerator Center, the University, or the DOE.
Newsgroups: comp.arch