HDTenEightyP/NetNews huggingface dataset:
From: morris@aspen.NSA.HP.COM (Dale Morris)
Newsgroups: comp.arch
Subject: Re: Caches and Hashing
Date: 19 Aug 92 17:41:07 GMT
Organization: HP Networked Systems Architecture - Cupertino, CA

Preston Briggs writes:

> I don't understand what is people are suggesting here.  Are we talking
> about scrambling addresses so that sequential accesses aren't
> necessarily mapped sequentially to cache?  Is it some kind of
> permutation or can to nearby items (where near is less than cache
> size) ever collide?  Does stride 1 access still pay off?
> 
> Back in the good ol' days (before I heard of this idea, anyway), we
> all had a rule we could live by:
> 
> 	Elements in a vector don't interfere with each other
> 	(as long as the vector is smaller than cache).
> 
> This even held for direct-mapped caches, primitive beasts though they
> are.  Of course, for a 4-way set-associative cache, we could plan on
> keeping 4 vectors in cache, with no interference at all (as long as we
> block the vectors to 1/4 the cache size).  And more ways of
> associativity would allow even more complex applications to be
> handled without problems.
> 
> Even with a direct-mapped cache, we can take advantage of the rule and
> copy many randomly placed chunks of data into locations that are safe
> (that is, we copy many things into a single vector).

The hash that HP uses does not disturb stride 1 access.  These are
still the good old days for your rule.  I think you're right in
thinking that breaking this rule would be a bad idea.

The function used hashes in bits that are not part of the 32-bit
address space that the user sees.  Generally speaking, these bits are
constant for each user process.  The hash serves only to randomize
cache placement for one process' references versus anothers'.

------------------------------------------------------------------------------
Dale Morris	    |  Now is the time, and now is the record...
morris@nsa.hp.com   |          of the time.
------------------------------------------------------------------------------
From: robert@cs.anu.edu.au (Robert Cohen)
Subject: Re: 32 => 64 Transition
Organization: Computer Science Dept., Australian National University
Date: Fri, 14 Aug 1992 06:18:10 GMT

peter@ferranti.com (peter da silva) writes:

>What size would *you* make an int? 64 bits? What do you do for a 32-bit
>data type? Short? Then what do you do for a 16-bit data type? Create another
>abomination "short short" or "long char"? "long long" is bad enough.

The perfect solution: int= 64, long =128 (for real men's numbers),
short = 32, char = 8, long char= 16, short short = 24,
long short = 48 and short long = 96.
If we need more precision we can start using short short long and
long short long etc.
In case anyone hasn't realised yet :-) :-) :-)

More seriously, I belive that we need a way to machine independently
specify the precision such as int:32.
When I write a program I usually know what sort of range I expect
a variable to have to hold. I dont care if its an int or a long or a short
on different machines, I want a number about that big.

Who uses 16 bit variables anymore anyway, memory's cheap, right :-)

Robert

-- 
Robert Cohen		email: robert@cs.anu.edu.au
PhD Student,  Dept of Computer Science
Australian National University
Neuron not responding, still meditating.  - "BrainOS" error message
Newsgroups: comp.arch
From: panter@micor.ocunix.on.ca (Bill Panter)
Subject: Re: Die aspect ratio.
Organization: M.B. Cormier INC., Orleans (Ont)
Date: Fri, 14 Aug 1992 16:22:35 GMT

In article <16edveINN7or@agate.berkeley.edu> krste@ICSI.Berkeley.EDU (Krste Asanovic) writes:
>
>I've a few questions for the VLSI hackers out in industry.
>
>Rectangular die give more perimeter per unit area if a design is pad
>limited. What's the largest sensible/known aspect ratio? (We've done
>one processor die with an aspect ratio of 2.3:1).
>
For that matter, a triangle (say a bisected square) can give a better
perimeter than that.  The bisected square gives a perimeter/area ratio
of 6.88/sq, while the 2.3:1 rectangle gives only 2.87/sq.  Can the
fab people out there tell us if its practical to cut a square die corner
to corner?

Bill Panter
(panter@micor.ocunix.on.ca)


Newsgroups: comp.arch
From: martin@math.rwth-aachen.de (  Martin Schoenert)
Subject: Re: Threaded Code
Organization: Rechnerbetrieb Informatik  /  RWTH Aachen
Date: 13 Aug 92 10:36:07 GMT

Ulrich Graef writes:

    [about whether or not a compiler must generate a range check for
     'switch ( unsigned-char-var ) { }']

    The problem is, a char value and an enumeration type value 
    is internally used like an integer (see the function call).
    That is the reason why I mentioned the extension to 2^16 or 2^32
    addresses (the domain of an integer).

    I want to make clear the conseqeuences: At every position in the
    statements a char value is converted to an integer. To generate code
    without range check with sources like your example you must change this
    for the switch statement.

Well the compiler must generate code that behaves as if the following
happens for a switch:

    The switch expression is evaluated.
    The value is converted to an integer.
    The integer value is compared with the values of the case labels
        (of which only one may compare equal)
    If one value compares equal,
        control is transferred to this label.
    If no value compares equal and there is a default label,
        control is transferred to the default label.
    If no value compares equal and there is no default label,
        control is transferred to the statement following the switch.

However the important thing is that the code only has to behave as if
this happens.  That means that a compiler may use any information he can
gather statically to implement a switch statement efficiently.  For
example the following statement sequence

    i = 1;
    switch ( i ) {
    case 2: <do-something>;
    case 3: <do-something-else>;
    default i++;
    } 

could well be implemented as

    load-immediate      $i,2

by a compiler (provided 'i' is not declared 'volatile').  No need for a
conversion, a range check, or a jump table.

Likewise, for the following switch statement

    unsigned char       * pc;

    switch ( *++pc ) {
    ...
    }

the compiler can simply use a jump table with 256 entries.  There is no
need for a range check because the compiler can detect that, even after
the conversion, the value of the switch expression can only be one of 256
possible values.

Martin.

--
Martin Sch"onert,   Martin.Schoenert@Math.RWTH-Aachen.DE,  +49 241 804551
Lehrstuhl D f"ur Mathematik, Templergraben 64, RWTH, D 51 Aachen, Germany
From: chased@rbbb.Eng.Sun.COM (David Chase)
Newsgroups: comp.arch
Subject: Re: 32 => 64 Transition
Date: 12 Aug 92 21:32:04 GMT
Organization: Sun Microsystems, Mt. View, Ca.
NNTP-Posting-Host: rbbb

chased@rbbb.Eng.Sun.COM (David Chase) writes:

>>Howsabout the *debuggers* do it [map page zero not readable],
>>not the OS?  (I don't see anyone clamoring to have the OS check
>>all array indices for validity.  What's the difference?)
>>There are some completely dandy optimizations that
>>rely on being able to read zeros from page zero.  

schow@bqneh3.bnr.ca (Stanley T.H. Chow) writes:

>Is there a language standard that specifies this (zeros from page zero)?
>Seems like a rather curious spec.

No, it's not a language spec, it's an implementation technique.  Sort
of like have an "add" instruction on your machine -- helpful, but not
required.  This lets you do a slightly better job of pipelining loops
of the form

   while (p != 0 && p -> data != K) p = p -> next;

Again, see the paper by Hendren and Hummel in this year's PLDI.

>Even if you specify that only the compiler is allowed to make this
>assumption, how do you prevent user code from doing this? 

You don't.  Compilers compile all manner of stupid buggy programs
without complaint -- why should an exception be made for this bug?

>How about user code that inadverdently do this?

You don't.  See above.

>Don't you want the user code to trap?

No, not if it makes the code run significantly slower.  Again, compare
this with array indexing tests (which, by-the-way, can often be nicely
optimized in the compiler to reduce their cost).  If I want tests, I
ask for them, and I expect them to be done.  If I want speed, I ask
for it, and I expect to get it.  If I want both, I expect to get some
compromise.  In practice, most of the programs that I run don't
indirect through zero, so I'd rather that they ran faster.  Even when
they do indirect through zero, my first reaction is not

      "Wow, I'm sure glad my window-system fell over."

(Yes, I'm aware of the dangers of continuing to run in a damaged
state.  Which is, of course, why we all write programs in C, right?
:-) Checking is important, but we have clearly chosen to compromise
some amount of checking for speed and convenience.)

I'd much rather that the people writing the program use better tools
and take more care; after that, I'm not really interested in
discovering their bugs.

David Chase
Sun
From: lindsay+@cs.cmu.edu (Donald Lindsay)
Newsgroups: comp.arch
Subject: Re: cooling
Date: 23 Aug 92 01:43:48 GMT
Article-I.D.: cs.BtEy50.Ix4.2
Organization: School of Computer Science, Carnegie Mellon


In article <BtED7C.5II@exnet.co.uk> dhd@exnet.co.uk (Damon) writes:
>Well, I think we should add a new UNIX character-special device,
>/dev/heatsink.

Close to the truth. High-reliability systems (and high priced
systems) can justify computer monitoring to detect e.g. a failed fan.
Aha, /dev/muffin! - well, actually, it's more likely an interrupt
flavor. The DECWRL heat pipe requires a vertical-orientation sensor
(and power cutoff).  I remember line printers with humidity sensors
(and power cutoff). If one of these trips, you'd really like to be
told which one it was, rather than having to guess.
-- 
Don		D.C.Lindsay 	Carnegie Mellon Computer Science
Newsgroups: comp.arch
From: puri@enel.ucalgary.ca (Ruchir Puri)
Subject: Experiments with Horizaontal Microcode Compaction @ Univ. of SouthWestern Lousiana.
Date: Thu, 13 Aug 92 00:29:52 GMT
Organization: ECE Department, U. of Calgary, Calgary, Alberta, Canada
Keywords: Local compaction, Microprogramming, Horizontal Machines.

Hi there!
	I am working on Local Microcode compaction and want to test
my algorithms with large microcodes. Last week, I found a research paper
in Transactions on computers July 1981 issue, about: Compaction Experiments 
on large microcodes. The paper is :

Title = Some Experiments on Local Microcode Compaction for Horizaontal Machines.
Authors = Scott Davidson, David Landskov, Bruce D. Shriver, Patrick W. Mallett.
Address = Univ. of SouthWestern Lousiana. 
Publication = Trans. on Computers, July'81, page 460-477.

This is the only paper I could lay my hands on which describes experiments
with large microcodes. The first author i.e.,  Dr. Scott Davidson was a 
member research staff with Western Electric Engg. Research Center, Princeton, NJ

I will really appreciate if anybody (from Univ. of SW Lousiana or elsewhere)
can give me any pointers to obtaining these large examples. 

Thanks a lot....

Best Regards,
--Ruchir
  (puri@enel.ucalgary.ca)



-- 
Ruchir Puri                    VLSI Gp., Dept. of Elect. & Computer Engg.
puri@vlsi.enel.UCalgary.CA     The University of Calgary, CANADA - T2N1N4
403-220-4870 (Dept Ph.)        403-284-5825 (Home Ph.), 403-282-6855 (Dept FAX)
Newsgroups: comp.arch
From: willmore@iastate.edu (David Willmore)
Subject: Re: Die aspect ratio.
Organization: Iowa State University, Ames IA
Date: Fri, 14 Aug 1992 21:41:55 GMT

panter@micor.ocunix.on.ca (Bill Panter) writes:
>krste@ICSI.Berkeley.EDU (Krste Asanovic) writes:
>>
>>I've a few questions for the VLSI hackers out in industry.
>>
>>Rectangular die give more perimeter per unit area if a design is pad
>>limited. What's the largest sensible/known aspect ratio? (We've done
>>one processor die with an aspect ratio of 2.3:1).
>>
>For that matter, a triangle (say a bisected square) can give a better
>perimeter than that.  The bisected square gives a perimeter/area ratio
>of 6.88/sq, while the 2.3:1 rectangle gives only 2.87/sq.  Can the
>fab people out there tell us if its practical to cut a square die corner
>to corner?

Not claiming to be a fab person (yet), but I would think that the triangular
QPFP, PGA and PLCC carriers would be awfully hard to design with. :)

--David Willmore
willmore@iastate.edu
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.arch
Subject: Re: Summary of responses [was: What would you like from a debugger?]
Date: 16 Aug 92 22:04:33 GMT
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Organization: Commodore, West Chester, PA

bevan@cs.man.ac.uk (Stephen J Bevan) writes:
>In article <id.SKBS.RIL@ferranti.com> peter@ferranti.com (Peter da Silva) writes:
>   In article <bosullvn.713613694@unix1.tcd.ie> bosullvn@unix1.tcd.ie (Bryan O'Sullivan) writes:
>   > I haven't decided yet what constitutes the smallest
>   > debugger I can get away with, but such things as printing data
>   > structures and their contents on the fly are out of the question.
>
>   Embed an interpreted language in the debugger (drive it from TCL?).
>
>You mean like Norman Ramsey's use of PostScript as the "little
>language" with which to drive his debugger "ldb"?

>Note it also mentions TCL and FORTH as possible language, but notes
>that: "The latter [TCL and FORTH] two offer too few datatypes"

	Amiga debuggers have used Lisp-like extension languages (Wack), and
newer debuggers have been using Rexx (which is pretty powerful, very easy
to use interactively, and provides exceedingly easy interapplication 
communication, since it was designed as a macro language to be used by multiple
applications).  Rexx is being standardized by ANSI currently, and is the
standard macro language on the Amiga now.

-- 
"Rev on the redline, you're on your own; seems like a lifetime, but soon it's
 gone..."  Foreigner
-
Randell Jesup, Jack-of-quite-a-few-trades, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com  BIX: rjesup  
Disclaimer: Nothing I say is anything other than my personal opinion.
From: weaver@jetsun.weitek.COM (Michael Gordon Weaver)
Newsgroups: comp.arch
Subject: Re: Die aspect ratio.
Date: 14 Aug 92 21:28:29 GMT
Organization: WEITEK Corporation, Sunnyvale CA

In article <16edveINN7or@agate.berkeley.edu> krste@ICSI.Berkeley.EDU (Krste Asanovic) writes:
>
>I've a few questions for the VLSI hackers out in industry.
>
>Sun in particular with the Viking, the cache controller, and the
>SPARC90, have produced many exactly square die recently. Also, there
>were quite a few other chips at this year's Hot Chips that were
>exactly square (or at least to the nearest 0.1mm).
>
>It seems unlikely that an irregular design such as a processor or
>cache controller would map naturally to a square die floorplan.  Is
>there some inherent yield or manufacturability advantage to having a
>square die?  I can think of reticle size and maybe efficient wafer
>tiling as two reasons.
>
The chips you mentioned are full (or near-full) reticle chips. To get
the maximum area they are made square. On the other hand, they are not
pad limited and are packaged in industry standard packages which are
square. A chip like Viking is made of a lot of sub-parts, so it has no
natural shape.

>Rectangular die give more perimeter per unit area if a design is pad
>limited. What's the largest sensible/known aspect ratio? (We've done
>one processor die with an aspect ratio of 2.3:1).
>
Usually, in full custom design, minimizing the maximum distance
is more important than maximizing the perimeter. Maximum distance
affects things like inductance, capacitance and mechanical stress.
Most of the chips I have worked on have been within 10% of being
square. On the other hand, I have seen DRAMs that look about 4:1. This
is to use all the area available in the cavity of a DIP package.

Michael.
Newsgroups: comp.arch,comp.benchmarks
From: ludemann@quintus.com (Peter Ludemann)
Subject: Re: MIPS ratings go up; faith in Dhrystone persists.
Organization: Quintus Corporation, Palo Alto, CA
Date: Wed, 12 Aug 1992 23:15:34 GMT

In article <1992Aug10.165958.16152@sinix.UUCP>, weicker@sinix.UUCP (Reinhold Weicker) writes:
> 
> Also, I must add that Dhrystone version 2.1 is not fool-proof either:
> If a compiler compiles both compilation units together (not intended
> for Dhrystone, but some compilers have such a switch), and does
> excessive constant propagation (between procedures), it can determine
> the whole flow of computation at compile time, and pre-compute the
> output.

Indeed; I was caught by this when I tried comparing the gcc v2 compiler
versus IBM's xlc on the RS/6000.  At first, it seemed that gcc was faster,
but then it turned out that IBM's compiler was optimizing away the dummy
timing loops, so the correction factor for loop overhead was coming out
wrong.  I have heard of "hardened Dhrystones" to avoid such problems, but
I suspect that each new optimizing compiler will require re-hardening.
If we could somehow go through all the ftp sites and blow away all old
Dhrystone sources, we might find a bit more truth in advertising ...

-- 
	Peter Ludemann  +1-415-813-3800  ludemann@quintus.com
Xref: sparky comp.arch:9004 comp.arch.storage:598
From: mjacob@kpc.COM (Matt Jacob)
Newsgroups: comp.arch,comp.arch.storage
Subject: Re: Memory Hierarchy Questions
Date: 21 Aug 92 20:32:52 GMT
Reply-To: mjacob@kpc.COM (Matt Jacob)
Organization: Kubota Pacific Computer, Inc.

|>  
|> I also am curious about the software overhead of a disk access, which
|> does not seem to be discussed very often, since seek time and rotational
|> latency tend to dominate disk transactions.
|>  

The software overhead tends to be quite high these days, to the point
of being significant. If you spend around 2ms in the top end of a driver
getting a transfer set up for a device with a 12msec seek time and
a rotational latency of near zero (say, for SCSI disk with Write Cache
enable set), the software overhead would be significant (IMHO).

The software overhead was high enough for managing the the ESP (Emulex SCSI processor) and its 8-10 interrupts/SCSI command on the Sun systems I worked
on that it was more than worth the effort to try and cluster operations
together into a single read or write operation (in order to match the
2 mb/s rotation data rate).

-matt
From: dhd@exnet.co.uk (Damon)
Newsgroups: comp.arch
Subject: Re: Die aspect ratio.
Date: 15 Aug 92 20:07:26 GMT
Organization: ExNet Systems Ltd Public Access News, London, UK

In article <16edveINN7or@agate.berkeley.edu> krste@ICSI.Berkeley.EDU (Krste Asanovic) writes:
>
>I've a few questions for the VLSI hackers out in industry.
>
>Sun in particular with the Viking, the cache controller, and the
>SPARC90, have produced many exactly square die recently. Also, there
>were quite a few other chips at this year's Hot Chips that were
>exactly square (or at least to the nearest 0.1mm).
>
>It seems unlikely that an irregular design such as a processor or
>cache controller would map naturally to a square die floorplan.  Is
>there some inherent yield or manufacturability advantage to having a
>square die?  I can think of reticle size and maybe efficient wafer
>tiling as two reasons.

Connections will, on average, be shorter.  Routing might be easier.
The mfr might not need all the space for contact pads.  Heat transfer
might be better.

>Rectangular die give more perimeter per unit area if a design is pad
>limited. What's the largest sensible/known aspect ratio? (We've done
>one processor die with an aspect ratio of 2.3:1).

I guess a long thin chip can suit some types of routing (river
routing?), but may make the die more prone to thermal stresses from
temperature gradients.

Please someone correct my wild and untrained thoughts here...

Damon
-- 
Damon Hart-Davis | Tel/Fax: +44 81 755 0077 |1.22|| ALL MAIL FREE.
Internet: dhd@exnet.co.uk | Also: Damon@ed.ac.uk || US hotrod motor groups.
--------------------------+----------------------++ >12 mail&news polls / day.
Public access UNIX (Suns), news and mail for #5 per month.  FIRST MONTH FREE.
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.arch
Subject: Re: Die aspect ratio.
Date: 17 Aug 92 15:38:41 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <1992Aug14.212829.15104@jetsun.weitek.COM>, weaver@jetsun.weitek.COM (Michael Gordon Weaver) writes:

| square. A chip like Viking is made of a lot of sub-parts, so it has no
| natural shape.

  Boy, is that a freudian slip.
-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
    I admit that when I was in school I wrote COBOL. But I didn't compile.
From: terashim@mtecv2.mty.itesm.mx (Ing. Hugo Terashima Marin)
Newsgroups: comp.arch
Subject: benchmarks for diff. architectures
Keywords: benchmarks
Date: 13 Aug 92 00:30:29 GMT
Organization: I.T.E.S.M. Campus Monterrey


 I would like to get information about benchmarks for different
architectures. Also about parameters, methods for measuring performance
and simulation. I appreciate your attention. Please send information to
terashim@mtecv2.mty.itesm.mx.
Hugo Terashima-Marin :wq

Newsgroups: comp.arch.storage
From: dale@convex.com (Dale Lancaster)
Subject: UniTree User Group Meeting
Summary: World-wide UniTree User Group and Symposia
Keywords: unitree, mass storage, user group
Organization: CONVEX Computer Corporation, Richardson, Tx., USA
Date: Wed, 12 Aug 1992 23:01:05 GMT
X-Disclaimer: This message was written by a user at CONVEX Computer
              Corp. The opinions expressed are those of the user and
              not necessarily those of CONVEX.

From smkelly@somnet.sandia.gov Tue Aug 11 18:07:38 1992
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Received: from somnet.sandia.gov by convex1.convex.com (5.64/1.28)
	id AA19846; Tue, 11 Aug 92 18:07:16 -0500
Received: by somnet.Sandia.GOV 
	(5.59/SNLA-3.2.1) id AA26693; Tue, 11 Aug 92 17:05:20 MDT
Message-Id: <9208112305.AA26693@somnet.Sandia.GOV>
From: smkelly@somnet.sandia.gov (Suzanne M Kelly)
Subject: Invitation to UniTree Users' Group Meeting and Symposia
Date: Tue, 11 Aug 92 17:05:20 MDT

This is an invitation to a UniTree User's Group Meeting & Symposia.  
All interested parties are welcome to attend.  It will be Thursday 
and Friday, September 17-18, 1992 at The Hyatt Regency Baltimore on the 
Inner Harbor.  If you need overnight accommodations, call the hotel 
directly.  Indicate that you are attending the UniTree Users' Group
Meeting to take advantage of the group rate of $115 for single (or $125
for double) occupancy.  The hotel's address is 300 Light Street,
Baltimore, MD 21202.  Their phone number is 301-528-1234.

There is no registration fee for the meeting itself.  (CONVEX has 
volunteered to host this meeting.)  Seating is limited, so if you plan 
to attend, send email to uug@sandia.gov by September 4, 1992.  Indicate 
if you will be giving a site presentation and/or if you're interested 
in giving any other presentation.
 
A proposed agenda is:
 
Thursday, September 17, 1992
 
* Status Presentation by each represented site (strongly requested if
  you are currently running UniTree)
 
* Vendor/Developer Presentations (any volunteers?)
 
Friday, September 18, 1992
 
* Prepared Presentations on a UniTree-Related Topic (any volunteers?)
  (e.g. I am volunteering to present our CFS to UniTree Transition 
  Experiences)
 
* Discussion of Issues
 
* Business Section (How should a users' group be formalized?)
 
* Adjourn 4:00 p.m.

Sue Kelly
Sandia National Laboratories
Organization 1957
Albuquerque, NM   87185-5800
505-845-9770
505-844-2067 (fax)
smkelly@sandia.gov (e-mail)


--
===========================================================================
Dale M. Lancaster, Mass Storage Marketing Manager, Convex Computer Corp.
(Work) 214-497-4581     (Fax) 214-497-4848     (Internet) dale@convex.com
===========================================================================