HDTenEightyP/NetNews huggingface dataset:
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:24:53 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <1993Jan3.235327.13718@qb.rhein-main.de>, vhs@rhein-main.de (Volker Herminghaus-Shirai) writes:

| (Additional menu items for move, resize, etc that are useless if you have
| a mouse since no one in his sane mind would use them then.)
| The video-mode desaster is another example. I have yet to see a workstation
| that keeps switching between "text-mode" and a horrendous amount of
| "graphics-modes" (except for the RS6000, which does text/graphics mode. Sigh.

  I have yet to see a non-accelerated workstation which did scrolling of
text windows as fast as a dedicated text mode. Since you are moving less
data with a hardware supported text mode it will always be faster,
unless you deliberately cripple the hardware to make a point.

  I prefer to do long interractive editing (like writing articles and
books) on a text screen because of this. It definitely has uses.

| A decent workstation has IMHO *at least* the following items of which the
| software can and does take advantage of:
| 	a high-resolution screen
| 	a pointing device
| 	an ethernet connection (or token ring if your management was bribed ;-)
| 	a UN*X operating system with TCP/IP support and a C compiler
| 	a boot prom that allows for interactive diagnosis etc.
| 	a decent amount of RAM and hard disk space
| 	a tape drive for backups and data exchange as opposed to floppy disk
| 	other items I may have forgotten (it's already tomorrow...;-)
| 
| Software writers are usually driven to write for the lowest reasonable
| common denominator, so if any of the above items don't exist in the base
| configuration of a workstation line, forget at least 50% of their usefulness
| if you have them. (E.g. >50 AIX or SCO UNIX installation disks vs. one tape.
| Newer releases may give you one or two floppies and a tape, but still no
| delivery on CD-ROM, as far as I see. Also no installing via ethernet, since
| not everybody has it, etc.)

  Your "far as I can see" should get glasses. SCO has been shipping on
CD for years, and Dell has been supporting network install for several
years, too. For ease of install I would rate Dell first, then Sun and
SCO tied, and HP-UX down a good bit from that.

  Sun beats SCO for ease of network setup, but that's because you can't
offer choices without having either menus or prompts. Installing a smart
net card on a Sun, like 4/670 for instance, a small server, is more
complex than adding a net card to SCO.

  I can remember installing V7 on a PDP-11, and it startet with toggling
the boot so the paper tape could be read to boot the magnetic media...
we have made progress in the last few decades.
-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
    Keyboard controller has been disabled, press F1 to continue.
From: daryl@bovill.auspex.com (Daryl Starr)
Newsgroups: comp.arch
Subject: Re: Def  of a workstation (a lark)
Date: 8 Jan 93 16:49:51 GMT
Organization: Auspex Systems

Shoot! I don't think y'all could agree on what a bear does in the woods!

I'm sure that Data Quest has handled this one before. Anyone from there
care to comment?

Daryl
Newsgroups: comp.arch
From: zstern@adobe.com (Zalman Stern)
Subject: Re: Swap byte instruction - how high is the win?
Organization: Adobe Systems Incorporated
Date: Sat, 9 Jan 1993 06:00:54 GMT

Byte swap instructions are used for two things:

1) Handling network (big-endian) byte order on a little endian machine.
2) Emulating x86 code on big-endian machines.

If you don't do either of these things, then the byte swap instruction is  
close to useless. (It might get used in device drivers that talk to brain  
dead hardware.) Even in these applications, the speed up is dubious because  
there is lots of other stuff going on.

I'm not sure I agree that many RISC processors implement byte swap  
instructions. The only one I know of is the POWER architecture which has 16  
bit swap instructions. Many RISC processors implement selectable endianness,  
but that is an entirely different matter. For example, the mechanism the  
R4000 (R3000A, R6000A) uses to switch endianness cannot be used to byte swap  
a word. The mechanism used on the Motorola 88000 series can be used to do  
that though I doubt it is efficient to do so from user mode. Vendors put  
these features in to make their chips more widely marketable more than to  
increase performance. (I.e. some potential customers would only accept a  
big-endian chip and others would only accept a little-endian one.)
--
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
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Subject: Re: FP-number cache? Unclocked VLSI design.
Summary: This will only make it worse
Organization: Purdue University Statistics Department
Date: Tue, 5 Jan 1993 12:47:17 GMT

In article <1993Jan5.085415.19676@klaava.Helsinki.FI> veijalai@klaava.Helsinki.FI (Tony Veijalainen) writes:

>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?). 

Those of us who use more sophisticated numerical procedures consider this
to be essentially the opposite direction to go.  It is not the case that
integers are only used for addresses and indices; they are vitally needed
for what is commonly called "number-crunching."  Fixed-point arithmetic
has great advantages in many situations, and often is so slow in some of
the "modern" machines, especially multiplication, that it pays to go to
the massive headaches of making the floating arithmetic emulate fixed-point
arithmetic.  This is especially bad with the formats in which floats are
automatically normalized and with the most significant bit missing, and
where there are even separate registers for integers and floats.

-- 
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: pcg@aber.ac.uk (Piercarlo Grandi)
Newsgroups: comp.arch
Subject: Re: Swap byte instruction - how high is the win?
Date: 9 Jan 93 11:45:43 GMT
	<PRENER.93Jan7233525@prener.watson.ibm.com>
Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
Organization: Prifysgol Cymru, Aberystwyth

On 8 Jan 93 04:35:25 GMT, prener@watson.ibm.com (Dan Prener) said:

prener> (Volker Herminghaus-Shirai) writes:

Volker> Subject line almost says it all. Many modern processors have an
Volker> instruction to swap the bytes in a word. [ ... ] There must be
Volker> *some* resaon why the RISC folks put it in, right?

prener> The win is approximately zero for general code.  But it is
prener> significant for emulating a processor with the opposite byte
prener> order.

This is one reason: emulating a little endian x86 on a a big endian RISC
machine. The other two reasons are:

Dealing efficiently with data to/from a little endian OS (usually MSDOS
or VMS) on a big endian machine.

Dealing efficiently with network byte order (big endian) on a little
endian machine.


Summary: two extremely important architectures (x86 and VAX) are little
endian; another two (68000, i.e. Mac and Sun) and network byte order are
big endian; RISC machines tend to be big endian, but want to support
interchange of data and emulation of little endian ones. Some RISC
architectures are endian configurable for this reason.
--
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: abaum@armltd.uucp (Allen Baum)
Newsgroups: comp.arch
Subject: Re: Superscalar vs. multiple CPUs ?
Date: 4 Jan 93 15:39:03 GMT
Organization: Advanced RISC Machines Ltd

I'm pretty sure this didn't make it out last time 
(cross posting problems- why comp.sys.intel?), so here it is again:


>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, 

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

This sounds just like the WM machine. It has an instruction that says: start a
vector fetch from this base with this stride and put it in this FIFO. The FIFO
is accessed as a GPR, which any instruction can use (including, presumably, another
load for gather/scatter. There are two read FIFOs and a write FIFO in the WM design.

The HPPA has some bits in the short displacement load/store
instructions that can be used for cache hints of the type you want- I
think only one combination has been defined so far
-- 
-- 

----------------
Allen J. Baum		Apple Computer		baum@apple.com, abaum@armltd.co.uk
From: mikef@sarah.lerc.nasa.gov (Mike J. Fuller)
Newsgroups: comp.arch
Subject: Re: SPARC Simulator ...
Date: 13 Jan 93 04:22:31 GMT
Reply-To: mikef@sarah.lerc.nasa.gov
Organization: Computational Materials Laboratory, NASA Lewis Research Center
X-Newsreader: GNU Emacs 18.58.2, GNUS 3.14.1, NNTP 3.10

>>>>> On Mon, 11 Jan 1993 07:18:32 GMT, wong@rkna50.riken.go.jp (Wong Weng
>>>>> Fai) said:

Wong> Thanks to everyone who responded. Unfortunately, it appears that my
Wong> search is in vain. There were more mails saying "Yeah ! I want that
Wong> too ! So keep me posted of anything you got" than those offering help.

Well, you can add me to the list of people looking for one, because I was
just about to post something asking if one existed when I came across your
query.  

I seem to remember reading something a long time ago, back when Sun was a
relatively small company and a 4/110 was a state-of-the-art machine instead
of something to prop a door open with, about how Sun had SunOS completely
ported to the Sparc processor before one was ever produced!  So, it appears
that Sun must have had a pretty complete Sparc emulator in-house.  Given
that the Sparc is an open architecture and quite readily available now, I
don't know what Sun would have to lose by making the emulator available to
the net.  In fact, making a Sparc emulator freely available could only make
the Sparc more popular.  Can anybody out there from Sun confirm or deny the
emulator's existence?

Wong> Those who did offer help spoke of the two trace tools for the SPARC
Wong> available on the public domain : SPA and Shade/Shadow - both of which
Wong> I have.

I've got to ask -- where do I get SPA and Shade/Shadow?  I asked Archie, but
came up empty.

Wong> A suggestion though ... if anyone do come up with such a simulator,
Wong> may I suggest that in line with SPIM, one should name it "SPARC"
Wong> spelled backwards, i.e.

Wong> C R A P S   ! ! !

I may just do that, since it looks like I may have to write one to do my
project.  If I do write one, I suppose I'll need a Sparc architecture
manual.  Can anybody suggest how to get one, since I doubt the campus
bookstore will have one. :-)

/-----------------------------------------------------------------------------\
| Mike J. Fuller | Internet: mikef@sarah.lerc.nasa.gov      |     "I hate     |
|----------------|           mikef@zippysun.math.uakron.edu |   quotations."  |
|/\/\/\/\/\/\/\/\| Bitnet:   r2mjf@akronvm                  | -- R.W. Emerson |
\-----------------------------------------------------------------------------/
Newsgroups: comp.arch
From: wws@craywr.cray.com (Walter Spector)
Subject: Re: Def  of a workstation (a lark)
Organization: Cray Research, Inc.
Date: 6 Jan 93 12:11:45 CST

One set of critera I use for the PC vs. workstation dividing line is:

	Does it have hardware memory management (so program A can't
	clobber program B)?

	And does the operating system in use enforce this?

The '836 and '486 chips appear to have some capabilities in this respect,
but vanilla MSDOS seems hopeless.

Walt
----
Walt Spector				God created the world in 7 days,
(wws@renaissance.cray.com)		  but God didn't have an installed base.
Sunnyvale, California			    (unknown Usenet poster)
_._ _._ _.... _. ._.
From: snail@lsl.co.uk
Newsgroups: comp.arch
Subject: Re: Def  of a workstation (a lark)
Date: 6 Jan 93 16:56:40 GMT
Organization: Laser-Scan Ltd., Cambridge

In article <1993Jan3.235327.13718@qb.rhein-main.de>, vhs@rhein-main.de (Volker Herminghaus-Shirai) writes:
> A decent workstation has IMHO *at least* the following items of which the
> software can and does take advantage of:
> 	a high-resolution screen
> 	a pointing device
> 	an ethernet connection (or token ring if your management was bribed ;-)
> 	a UN*X operating system with TCP/IP support and a C compiler
> 	a boot prom that allows for interactive diagnosis etc.
> 	a decent amount of RAM and hard disk space
> 	a tape drive for backups and data exchange as opposed to floppy disk
> 	other items I may have forgotten (it's already tomorrow...;-)

Yes, this gets its for me..

A workstation doesn't *have* to run UNIX. Any good OS will do. bye bye MSDOS,
TOS, etc etc...

A workstation has high-resolution graphics and lots of colours per pixel and
the graphics card does perform quickly. Not strictly true, since some people
like mono screens (I edit on a mono screen, but I don't test my code on one).

On a workstation, software does not worry about how much memory it has; just
page it out to disk. Microsoft windows can release memory and re-read it from
the disk, but it can't page memory *out* to the disk (not unless it changed
recently).

and as someone else said:
With a workstation, none of your money goes to Microsoft or Bill Gates. This 
must be the best definition of a workstation yet.

> Looks good on the outside, but -
> 	intel inside

Oooooo, so right!
-- 
snail@lsl.co.uk      

"Washing one's hands of the conflict between the powerful and the powerless
 means to side with the powerful, not to be Neutral."
                                                     Quote by Freire.
                                                     Poster by OXFAM.

Motorola inside.
Newsgroups: comp.arch
From: tipley@solo.eng.hou.compaq.com (Roger Tipley)
Subject: Re: FP-number cache? Unclocked VLSI design.
Organization: Compaq Computer Corp.
Date: Tue, 5 Jan 1993 21:24:51 GMT

In article <1993Jan5.170446.15655@Princeton.EDU> awolfe@moo.Princeton.EDU (Andrew Wolfe) writes:
>...
>
>(Philosophical note.  This experiment also raised the issue of whether or
>not the architecture community will accept the publication of negative
>results.  We could not locate any recent papers in major conferences that
>did not have positive results)
>
>Andrew Wolfe
>...
>Princeton University

The publication of failures is nearly as important as the publication of 
successes.  The problem is finding a place to air these.  If the major 
conferences have an adequate supply of success story papers, then they aren't
apt to want to run interesting failures.  Trouble is, the failures are usually
MUCH more interesting than the triumphs and probably include "real world" 
factors that are often left out of theoretical successes.
 
Publishing failed attempts would help to keep others from 
duplicating the exact mistakes, and prompt the rest of us to conjure up
scenarios of "if they only did it THIS way, then ...", and we could all feel so superior that we would NEVER have made those silly mistakes ;)  

My bookshelf has many ACM SIGARCH Computer Architecture News publications.
They all have papers published in them, and 
most of them have so few articles it makes me wonder why I subscribe to it.  I
would lay odds that that publication would relish a whole host of "failure 
stories", if for no other reason than to justify its existence and make it
more interesting to read.
 
The challenge, then, is to see if researchers are willing to risk embarrassment
and competition on a subsequent retry, by telling the world why a certain
experiment didn't turn out so well.

Roger E. Tipley
Compaq Computer Corporation
tipley@twisto.compaq.com
From: tim@apple.com (Tim Olson)
Newsgroups: comp.arch
Subject: Re: How does an R4000-style cache work?
Date: 8 Jan 93 14:59:24 GMT
Followup-To: comp.arch
Organization: Apple Computer Inc. / Somerset

In article <1993Jan7.201733.16338@csrd.uiuc.edu>, grout@sp90.csrd.uiuc.edu
(John R. Grout) wrote:

> So, the indicated solution is:
> 
> 4)   Put the data in a write buffer until tag check.
> 
>      On a cache miss, stall the pipeline and write the data to cache as part
>       of miss processing.
> 
>      On a cache hit, put the data to the store buffer and unload it when:
> 
> 	a) The cache bandwidth is available: no pipeline effects.
> 	b) A load which wants to use the results of the store is
> 	    detected: stall the pipeline and empty the store buffer.
> 	c) The store buffer is full: not clear (is this handled like case "b"?)

Case c) probably never occurs -- a store can sit in the store buffer of the
cache until another store occurs, at which time the first store can use the
second store's pipeline slot to write into the cache (as long as tag
addressing and cache data addressing are split).  We used the same trick on
the Am29000 to multiplex the single register-file writeback port between
ALU results and LOAD results (as LOAD results come back sometime after the
LOAD's writeback slot has passed...)
 
     -- Tim Olson
        Apple Computer Inc. / Somerset
        (tim@apple.com)
Newsgroups: comp.arch
From: sl@wimsey.bc.ca (Stuart Lynne)
Subject: Re: A theory for Big & Little Endian's origin
Organization: Wimsey Information Services
Date: Sat, 9 Jan 1993 09:14:47 GMT

In article <JR.93Jan8171051@gilligan.ksr.com> jr@ksr.com (John Robinson) writes:
>In article <C0JnLq.K2x@uceng.uc.edu> jpenix@uceng.uc.edu (John Penix) writes:
>
>The consumate reference (IMO) is Danny Cohen's "On Holy Wars and a
>Plea for Peace", IEEE Computer v14n10, Oct. 1981, pp 48-54.  I think
>this floated around the net for a while (RFC?) before it was
>published.

Is it really time to post it again? Maybe it should be posted
yearly as a FAQ :-)

Anyone who want's to read it can ftp it from:

	ftp.wimsey.com:pub/folklore/holywars

-- 
Stuart Lynne <sl@wimsey.com> ......................... UNIX Facsimile Software
Wimsey Information Technologies ................... moderator biz.sco.binaries
uucp login:nuucp passwd:nuucp .................... ftp.wimsey.com:~ftp/ls-lR.Z
PD Software for SCO UNIX .................... ftp.wimsey.com:~ftp/pub/wimseypd
Newsgroups: comp.arch
From: willmore@iastate.edu (David Willmore)
Subject: Re: Swap byte instruction - how high is the win?
Organization: Iowa State University, Ames IA
Date: Sat, 9 Jan 1993 23:12:33 GMT

prener@watson.ibm.com (Dan Prener) writes:
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?

>The win is approximately zero for general code.  But it is significant
>for emulating a processor with the opposite byte order.

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?  That way, they could show that the 486 was much superior to the 386
by demonstrating how much faster NextStep runs on the 486 as compared to
the 386?  That would be a more subtle way of selling 486's.  It might
even carry over to people who want to run things other than NextStep
because, "Well, if it runs that faster, it will run my program faster
too, right?(wrong)" :)

Looks like another bad marketing plan.

--David Willmore
willmore@iastate.edu
From: burke@seachg.uucp (Michael Burke)
Subject: Re: big + little endian (was: Comparison of Alpha, MIPS ..)
Reply-To: burke@seachg.UUCP (Michael Burke)
Organization: Sea Change Corporation, Mississauga, Ontario, Canada
Date: Thu, 7 Jan 93 15:41:37 GMT

In article <markg.79.726169747@county.lmt.mn.org> markg@county.lmt.mn.org (Mark Gilbert) writes:
>I have identified the root of this whole big-endian/little-endian debate.  
>The conflict is is between text and numbers.  We read left to right.  But, 
>if you were to number the digits of an integer, you would do it right to 
>left.  The one's digit would be 0, the ten's digit, 1, etc.
>
>This should never have been the case.  We adopted our number system from the 
>Arabs, and the Arabs read right to left.  For them, the direction of reading 
>text and numbers is CONSISTENT.  The whole problem arose because we failed 
>to reverse the numbering system when we borrowed it from the Arabs.
>
>I propose that we now correct this historical oversight.  Let us write 
>numbers least significant digit first.  The bang symbol can be used to 
>replace the decimal point, in order to distinguish little-endian numbers 
>from big-endian.  The integer six hundred and fifty four should now be 
>written !456.  Sixteen dollars and twenty five cents is now $ 52!61.
						No -         ^^^^^^^^
						Should be     52!61$
						read "25 cents, 16 dollars"
-- 
---
Michael Burke

Sea Change Corporation
6695 Millcreek Drive, Unit 8 
Mississauga, Ontario, Canada L5N 5R8
Tel: 416-542-9484  Fax: 416-542-9479
UUCP: ...!uunet!uunet.ca!seachg!burke
Newsgroups: comp.arch