HDTenEightyP/NetNews huggingface dataset:
From: adiwan@quick.fox.cs.cmu.edu (Amer Diwan)
Newsgroups: comp.arch
Subject: Write buffer on DS5000
Date: 11 Jan 93 18:51:37 GMT
Article-I.D.: QUICK.ADIWAN.93Jan11135137
Reply-To: adiwan@cs.cmu.edu
Distribution: comp.arch comp.sys.mips
Organization: School of Computer Science, CMU

I am collecting memory reference traces from ML programs compiled with SML/NJ
compiler and running them through cache simulators (dinero/tycho).  I am doing
this on DECStations 5000/120 and DECStations 5000/200 running Mach.  For
me to be able to accurately evaluate the effects of memory access patterns on
the running time of the programs, I need to have a detailed understanding of
the write buffer behavior.  I need answers to the following:

1. Latency of a write hit when the write buffer is empty
2. Latency of a write hit when the write buffer is full
3. Latency of a write miss when the write buffer is empty
4. Latency of a write miss when the write buffer is full

The DS5000/200 specs. seem to answer at least 3: 13 cycles (CPU cache fill).
What about the rest?

Are there any trace driven simulators out there that take the write buffer
into consideration?

Thanks a lot.
    Amer
--
---------------------------------------------------------------------------
Amer Diwan					School of Computer Science
Fox Project					5000 Forbes Avenue
adiwan@cs.cmu.edu				Carnegie Mellon University
(412) 268-3066                                  Pittsburgh, PA 15213
From: carlton@scws1.harvard.edu (david carlton)
Newsgroups: comp.arch
Subject: Re: big + little endian (was: Comparison of Alpha, MIPS ..)
Date: 8 Jan 93 01:19:24 GMT
 <3623363@zl2tnm.gen.nz><WAYNE.92Dec30093950@backbone.uucp><markg.79.726169747@
 county.lmt.mn.org> <1993Jan6.171242.2895@lsl.co.uk><RABIN.93Jan7132015@nuthatch.CS.Yale.Edu> <FY.93Jan7111925@hardwick.lucid.com>
Organization: Citizens for Boysenberry Jam
In-reply-to: fy@lucid.com's message of 7 Jan 93 11:19:25

In article <FY.93Jan7111925@hardwick.lucid.com>, fy@lucid.com (Frank Yellin) writes:

> Of course, how were numbers done in ancient Greek.  It was written in
> boustrophedon:  the lines alternated left-to-right and right-to-left.

Some rather old writings were written boustrophedon, but I wouldn't
present it as the norm.

david carlton
carlton@husc.harvard.edu

       YOW!!  I'm in a very clever and adorable INSANE ASYLUM!!
Newsgroups: comp.arch
From: bogstad@rhombus.cs.jhu.edu (Bill Bogstad)
Subject: Re: Def of a workstation (a lark)
Organization: Johns Hopkins Computer Science Department, Baltimore, MD
Date: Sun, 10 Jan 1993 02:38:30 GMT

In article <1iarmrINNk28@news.cerf.net> davsmith@nic.cerf.net (David Smith) writes:
>
>Top ten differences betweed PC's and workstation's
>...
>8. Can't buy workstation peripherals at Crazy Al's Discount Computer

	Crazy Al's has been selling SCSI disks and tape drives along with
SIMM memory modules for several years now...

				Bill Bogstad
				bogstad@cs.jhu.edu
From: cah@hpfcso.FC.HP.COM (Craig Heikes)
Date: Wed, 6 Jan 1993 04:32:21 GMT
Subject: Re: Dhrystone Benchmark
Organization: Hewlett-Packard, Fort Collins, CO, USA
Newsgroups: comp.arch

>I need some up to date dhrystone numbers for some hardware selection
>that we are doing. Attached you will find the dhrystone benchmark.
>I'm particularly interest in the 68040 and newer RISC processors.
>It would be great if you would run it and mail me the results in the following
>sample form. I'll post the results if people are interested.

>    -Mike Grenier
>     mike@atc.sp.paramax.com

MANUF:HP
MODEL:9000 Series 730
PROC: PA-RISC
CLOCK:66 Mhz
OS:HPUX
OVERSION:8.07
COMPILER:cc    
CVERSION:HP92453-01 A.08.71 HP C Compiler
OPTIONS:+O3
NOREG:115000
REG:115000
NOTES:run on my machine, lightly loaded, 10e6 iterations, user time agrees
DATE:1/5/93  
SUBMITTER:cah@fc.hp.com

---  Craig Heikes
---  My opinions, not HP's
From: daryl@bovill.auspex.com (Daryl Starr)
Newsgroups: comp.arch
Subject: Re: VME bus
Date: 8 Jan 93 16:35:28 GMT
Distribution: na
Organization: Auspex Systems

In article <thia.726452926@mira.sce.carleton.ca>, thia@sce.carleton.ca (Yong Thia) writes:
|> Hi! I would like to know if the VME bus is a synchronous
|> or asynchronous bus.
|> ANy pointers will be greatly appreciated
|> 
|> Regards
|> Jimmy

The VME bus is an asynchronous bus although the next revision of the spec.
will include SSBLT (Source Synchronous BLock Transfers).

There is a news group (comp.arch.bus.vmebus) to answer your questions
about VME.

I would be willing to answer more questions if you move the queries to the
above news group.

Daryl
Newsgroups: comp.arch
From: snail@lsl.co.uk
Newsgroups: comp.arch
Subject: Re: Def  of a workstation (a lark)
Date: 11 Jan 93 18:49:14 GMT
Organization: Laser-Scan Ltd., Cambridge

In article <C0GJzC.GFJ@metaflow.com>, rschnapp@metaflow.com (Russ Schnapp) writes:
> In article <1993Jan6.165640.2894@lsl.co.uk>, snail@lsl.co.uk writes:
> |> 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).
> 
> Not terribly recently -- Windows 3.1 has fully virtual memory in
> "enhanced mode".  (For some reason, they limit virtual memory to twice
> the size of physical memory.)  I believe that 3.1 has been out for a
> year or so.

OK, thanks for the correction, I'm a Windows novice and X/Motif Guru type, so
we do GIS, and expect program + data size to hit 100Meg or more, so I'm
afraid as far as VM goes, I still can't really take Windows that seriously,
however maybe using a Watcom C compiler and some of their enhancements....
(or maybe it isn't Watcom, but someone else).

Windows ain't that bad (but I haven't coded it yet), but it sure does need a
Wt on top of it (Xt like thingumy) - no problem, I know what to write, but the
guys at work don't want me to get down and do it yet.
-- 
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.
From: snail@lsl.co.uk
Newsgroups: comp.arch
Subject: Re: Def  of a workstation (a lark)
Date: 11 Jan 93 18:52:13 GMT
Organization: Laser-Scan Ltd., Cambridge

In article <C0o5Jq.3nM@dscomsa.desy.de>, hallam@zeus02.desy.de (Phill Hallam-Baker) writes:
> 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...;-)

Looks like the Atari-ST bites the dust (I have one, but I don't think I would
call it one either), but it also looks like the Atari 030 Falcon might bite
the dust also, depite running UNIX and X (if you want). I'm not quite sure of
it's specs, I'd love one for my sequencer...
-- 
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.
Newsgroups: comp.arch
From: prener@watson.ibm.com (Dan Prener)
Subject: Re: Swap byte instruction - how high is the win?
Date: Fri, 8 Jan 1993 04:35:25 GMT
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
Organization: IBM T.J. Watson Research Center, Hawthorne, New York

In article <1993Jan7.074052.19620@qb.rhein-main.de> 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.
--
                                   Dan Prener (prener@watson.ibm.com)
From: edb@hpgrla.gr.hp.com (Ed Beshore)
Date: Tue, 5 Jan 1993 00:14:46 GMT
Subject: DIS 13346 Conformance Testing Meeting
Organization: Hewlett-Packard, Greeley, CO
From: jtien@venice.eng.uci.edu (Joe Tien)
Subject: Harvard architecture
Newsgroups: comp.arch
Reply-To: jtien@venice.eng.uci.edu (Joe Tien)
Organization: University of California, Irvine
Date: 11 Jan 93 20:19:46 GMT


Could someone direct me to a good definition of the harvard architecture? Is it
dual memory port (each with own set of address and data bus) or is it just dual
bus (separate address and data bus used for both instruction and data.)

If possible, I'd prefer some type of reference I can use in my paper, not that
I don't trust the infinite wisdom of the net. :-)

Thanks,

Joe Tien
jtien@balboa.eng.uci.edu
Newsgroups: comp.arch
From: bickford@netcom.com (Peter Bickford)
Subject: Re: Def of a workstation (a lark)
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
Date: Wed, 6 Jan 1993 13:55:05 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).  
>
>
work-sta-tion (werk'sta shen), n. 1. the place where a person stands while
  on duty.

-- 
	Peter Bickford		bickford@netcom.com	(415) 962-0768
From: carlton@scws8.harvard.edu (david carlton)
Newsgroups: comp.arch
Subject: Re: big + little endian (was: Comparison of Alpha, MIPS ..)
Date: 11 Jan 93 23:02:12 GMT
Article-I.D.: scws8.CARLTON.93Jan11150212
Organization: Citizens for Boysenberry Jam
In-reply-to: vhs@rhein-main.de's message of Mon, 11 Jan 93 15:30:13 GMT

In article <1993Jan11.153013.716@qb.rhein-main.de>, vhs@rhein-main.de
(Volker Herminghaus-Shirai) writes: 
>In article <CARLTON.93Jan7171924@scws1.harvard.edu> carlton@scws1.harvard.edu 
>(david carlton) writes:
>> In article <FY.93Jan7111925@hardwick.lucid.com>, fy@lucid.com
>> (Frank Yellin) writes:

>>> Of course, how were numbers done in ancient Greek.  It was written in
>>> boustrophedon:  the lines alternated left-to-right and right-to-left.

>> Some rather old writings were written boustrophedon, but I wouldn't
>> present it as the norm.

> Why not? 

Because it's not true.  It's very simple, really - I could be
mistaken, but I'm fairly sure that the vast majority of writings in
Ancient Greek were not written boustrophedon.  Therefore, it is false
to say that they were.

Not that this has much to do with computer architecture, mind you...

david carlton
carlton@husc.harvard.edu

       ..  I feel..  JUGULAR..
Newsgroups: comp.arch.bus.vmebus
From: sdavis@laforge.ksc.nasa.gov (Steve Davis)
Subject: Dual VMEbus adapters
Organization: NASA
Date: Mon, 4 Jan 1993 19:39:48 GMT


Greetings...

  We are looking for a means of implementing a system with dual independent VME  
buses; i.e., where the only signals that pass through the adapter are those  
with source and destination addresses on separate buses.  DMA support is a  
must.  We are currently experimenting with a two-card bridge adapter from Bit3,  
but we're wondering if there are any comparable products on the market.  Any  
information on this would be greatly appreciated.

Thanks in advance,

Steve
--
+----------------------------------------------------------------+
| Steve Davis                      | sdavis@laforge.ksc.nasa.gov |
| NASA, DL-DSD-32                  |    (NeXT Mail OK)           |
| Kennedy Space Center, FL  32899  | HSSC Mail:  RDAVIS          |
| (407)867-7582  fax:(407)867-2173 | #include <disclaimer.h>     |
+----------------------------------------------------------------+
From: peanuts@dist.dist.unige.it (Baudino Alberto Bruzzone Gabriele Durante Antonio)
Newsgroups: comp.arch.bus.vmebus
Subject: WANTED : info about VMEXEC & interrupts
Keywords: vmexec, interrupts
Date: 4 Jan 93 09:24:45 GMT
Reply-To: peanuts@dist.dist.unige.it (Baudino Alberto Bruzzone Gabriele Durante Antonio)
Organization: DIST - Universita` di Genova, Italy
NNTP-Posting-Host: dist.dist.unige.it

We are two italian students on engineering at Genoa University and we need informations
about VMEXEC and interrupts on VME BUS (e.g. how generate an interrupt from C language, 
how catch the interrupt, ...).
Our project is an implementation of software for robot control with VME167 and DSP 
boards.
Exist any ftp site where retrieve informations about previous arguments ?
Thanks.

                              Paolo Bianchetti Gabriele Bruzzone

E-mail address:
gaggero@dist.unige.it
peanuts@dist.unige.it
Newsgroups: comp.arch.bus.vmebus
From: charles@phx.mcd.mot.com (Charles Wolff)
Subject: Re: WANTED : info about VMEXEC & interrupts
Keywords: vmexec, interrupts
Organization: Motorola Computer Group, Tempe, Az.
Date: Tue, 5 Jan 1993 19:48:17 GMT

In article <1i8votINN2ro@sgi.iunet.it> peanuts@dist.dist.unige.it (Baudino Alberto Bruzzone Gabriele Durante Antonio) writes:
> we need informations
> about VMEXEC and interrupts on VME BUS
> (e.g. how generate an interrupt from C language, 
> how catch the interrupt, ...).

I am passing on the following from Mike Duh, duh@phx.mcd.mot.com.
Please contact him by email if you have further questions.

VMEexec  easily  supports  handling  interrupts   from   "C"
language.   Under  VMEexec, you would create a src/task (for
non-SVIDlib tasks) or src/ctask (for  SVIDlib  tasks).   The
task  issues the claimvct System Service call which connects
an interrupt to a routine contained in the  task.   Assuming
VMEexec 2.0 or later is used, documentation for tasks can be
found in chapter 3 of the VMEexec  User's  Guide  (ADDING  A
TASK).   The  claimvct  service is documented in the VMEexec
System Services User's Manual.

Your specific application requested information on  handling
VMEbus interrupts on the MVME167 so there is some additional
code which must be written.  All of  the  VMEbus  interrupts
are handled by the VMEchip2 on the MVME167.  The VMEchip2 is
initialized     by     VMEexec      in      the      module:
src/board/68040/vme167/mvme167.c.   It  is  likely  that the
specific interrupt needed for your application  is  disabled
by  default.  However, since the source for the above module
is  supplied  with  VMEexec,  this  default  action  may  be
changed.   Refer  to  the MVME167/187 Programmer's Reference
Manual  to  locate  the  specific  VMEchip2  register  which
controls  the  interrupt  needed for your application.  Then
edit the default VMEchip2 initialization code  in  mvme167.c
to  enable  the  interrupt  and program it to interrupt on a
level and vector  of  your  choice.   The  vector  must  not
overlap with any other vectors already used.
Newsgroups: comp.arch.bus.vmebus
From: michael@chg.mcd.mot.com (Michael Bodine)
Subject: Re: VME vs other bus architecture
Organization: Motorola Computer Group, Schaumburg, IL
Date: Mon, 4 Jan 1993 19:47:27 GMT

nickgill@doc.bmd.trw.com writes:
>Can anyone give me a breakdown on the different buses?
>Specifically, the VME, STD, Cybermotion, MPL
>I understand that the:
>VME is for Motorola
>STD is for Intel
>Cybermotion is for Cybermotion robots
>MPL is for Motorola with emphasis on motion, moving, jarring, etc
First, you're asking an awful lot of someone to spend quite a bit of time
writing a paper describing all the differences among the most popular
buses.  I used to give two hour presentations comparing several of the
major architectures, and that was just an overview.

Second, you've only mentioned two of those in common use, VME and STD.
I've never heard of the other two.  What about STE, Multibus, Multibus II,
VXI, Futurebus+, NuBus?  Not to mention the PC buses in use.  The high end
stuff.  PLC buses.  The list gets rather long!

Third, VME is NOT for Motorola.  You'll find 68K and 88K Motorola
processors co-residing with Sparc, VAX-chips, ix86s, AMDs, MIPS, various
math processors, DSPs, and semi-custom chips.  And that's the short list.
Similarly, STD has been around a long time, and just about everything in
the low to mid performance ranges has been put on an STD board.

I'd recommend a search thru the technical literature if you'd like to find
articles comparing the various bus architectures.  Maybe someone has one
already in machine readable form!  Decisions made about bus architecture,
however, are mostly made on issues like availability, price, and maybe
scalability and performace.  Lots of other considerations come to play --
probably the biggest hurdle for most new projects is overcoming the
inertia of what was used yesterday.  I could spend a lot of time talking
about advantages of one over the other, but i'm pretty obviously
prejudiced, so i'll leave that part of the discussion to other, more
disinterested parties.
-- 
[  Michael Bodine, michael@chg.mcd.mot.com, Dial: (708) 576-7840, FAX: x8875  ]
[  Motorola TSD; Loc IL38; 1100 Woodfield; Suite 334;  Schaumburg, Il  60173  ]
From: nickgill@doc.bmd.trw.com
Newsgroups: comp.arch.bus.vmebus
Subject: VME vs other bus architecture
Date: 24 Dec 92 15:22:19 MST

Hello,

Can anyone give me a breakdown on the different buses?
Specifically, the VME, STD, Cybermotion, MPL

I understand that the:

VME is for Motorola
STD is for Intel
Cybermotion is for Cybermotion robots
MPL is for Motorola with emphasis on motion, moving, jarring, etc

Thanks,
Nick
Newsgroups: comp.arch
From: cn0cu8ah@triton.unm.edu (The Realist)
Subject: Any dealers of RISC systems in Computer Shopper?
Date: Mon, 04 Jan 93 05:38:34 GMT
Organization: University of New Mexico, Albuquerque
Summary: Computer Shopper vendors and RISC systems
Distribution: usa
Keywords: RISC, Computer Shopper

  Hello:

  Does anybody know which dealers/vendors advertising in Computer
  Shopper offer/sell computers based on RISC cpus? If so, can you
  provide me with their names? I know that Compuadd offers a RISC
  system(s) and I would like to know if anybody else sells these
  things. Thanks for your time and response.

  Regards,

  Alex (cn0cu8ah@triton.unm.edu)


   


Newsgroups: comp.arch
From: willmore@iastate.edu (David Willmore)
Subject: Re: A theory for Big & Little Endian's origin
Organization: Iowa State University, Ames IA
Date: Fri, 8 Jan 1993 16:41:32 GMT

From the understanding that I have, (nice open statment) here is
how I see the two alignments having come about.

To store a byte, there are no choices, 8 bits arranged any way
at one location is a byte.  With 16 bits there are two choices.
You can store the most signifigant byte first or the least.
The intuitive way would be to put the biggest byte at the labeled
address, for example, 0 and the least signifigant byte at address
1.  This would be read from address 0 as high byte low byte--just
as it should sound.

The other way fixes the load problem.  Say you want to read an 8
bit value starting at address 0.  The first byte read goes in the
low order part of the register, the rest is cleared.  To load a
16 bit value, address 0 is placed in the low byte of the register
and the next byte at address 1 is placed in the next higher byte
of the register.  That way, a 32 bit or more number can be at a
fixed location and you can optionally load 8 bits, 16 bits, or the
full 32 bits without having to adjust your address register.

The only reason to have used one over the other, as I see it, is
by how far you were looking ahead.  The x86 family came about
bit by bit (sorry about that pun) and get backed into a corner
because they didn't think ahead.  The 68k family was designed 
from scratch and these load issues were solved before they 
committed themselves to a particular format.

This is a very common theme in computer archetecture.  If you don't 
look ahead and plan for it, you can get backed into some nasty
corners.

---------------------------------------------------------------------------
willmore@iastate.edu | "Death before dishonor" | "Better dead than greek" | 
David Willmore  | "Ever noticed how much they look like orchids? Lovely!" | 
---------------------------------------------------------------------------
Newsgroups: comp.arch
From: dnl@convex.is.macsch.com (David Lombard)
Subject: Re: A theory for Big & Little Endian's origin
Organization: MacNeal-Schwendler Corp.
Date: Wed, 13 Jan 93 01:47:01 GMT

In article <C0JnLq.K2x@uceng.uc.edu> jpenix@uceng.uc.edu (John Penix) writes:
>
>I remember reading (and I'll hunt down the title if you'd like) that
>IBM's endedness came from a mechanical memory device that was something

Gee, I thought IBM processors were big endian, but maybe I'm confusing
them with   I N T E L   ( N O T   I B M )   processors?

Silly me...

Regards,
DNL

                 MY_COMMENTS, MY_OPINIONS, NOBODY_ELSES.

David N. Lombard    The first thing we do,         The MacNeal-Schwendler Corp
dnl@macsch.com      Let's kill all the lawyers.    815 Colorado Blvd
(213) 259-4911      II Henry VI, IV.ii             Los Angeles, CA  90041
Newsgroups: comp.arch
From: nagle@netcom.com (John Nagle)
Subject: Re: PCMCIA bus info?
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Distribution: na
Date: Sat, 9 Jan 1993 17:41:28 GMT

paulk@kpc.com (Paul Kalapathy) writes:
>Where can I find some technical information on the PCMCIA interface?
>By technical I mean pinout, timing, protocols, etc.  

     BYTE, December 1992, pp. 237-244.  Good detailed overview; not
enough to design a board.

						John Nagle
Newsgroups: comp.arch
From: awolfe@moo.Princeton.EDU (Andrew Wolfe)
Subject: How does an R4000-style cache work?
Originator: news@nimaster
Keywords: Write-back Cache
Organization: Princeton Univ.
Date: Wed, 6 Jan 1993 23:54:55 GMT

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
Newsgroups: comp.arch