HDTenEightyP/NetNews huggingface dataset:
From: bevan@cs.man.ac.uk (Stephen J Bevan)
Newsgroups: comp.arch,comp.lang.c,comp.programming,comp.unix.programmer
Subject: Re: Summary of responses [was: What would you like from a debugger?]
Date: 14 Aug 92 12:09:51 GMT
Followup-To: comp.arch
Organization: Department of Computer Science, University of Manchester
In-reply-to: peter@ferranti.com's message of 13 Aug 92 15:24:31 GMT

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"?
Check out PLDI '92 pp 22-31

Note it also mentions TCL and FORTH as possible language, but notes
that: "The latter [TCL and FORTH] two offer too few datatypes"
Make of that what you will.

bevan
Xref: sparky comp.arch:8947 comp.lsi:548
From: inyup@python.icsl.ucla.edu (Ian Knight)
Newsgroups: comp.arch,comp.lsi
Subject: DELAY LINE?
Keywords: timing
Date: 18 Aug 92 22:27:03 GMT
Followup-To: comp.arch
Organization: UCLA Integrated Circuits & Systems Laboratory

Hi, folks.

Is there anybody who designed a delay line(DL, continuous time, digital) 
using CMOS ?

Its specifications are as follows:

1. the output is delayed version of input.
2. it's desirable to have the symmetric delay
   (that is, rising propagation delay == falling propagation delay)
3. the delay must be controllable from "0.5ns" to "10ns"
   using only circuit parameter(let's say, using gate cap. or ratio...)
4. the total area of the DL must be minimal.
   (it can be included inside the usual Digital VLSI,
	in quantity of 10 or more)
....

I think somebody in the DRAM business might be using DL 
as a control signal for the RAS/CAS,
my application is totally different, though.

Any hints really will be appreciated.

- Ian Knight
--


 - Inyup Kang
Newsgroups: comp.arch
From: shahin@eastrg1.cray.com (Shahin Khan.)
Subject: Re: Call for Opinion: Viking or i860
Organization: Cray Research, Inc.
Date: 21 Aug 92 19:43:07 CDT

In article <1992Aug2.034815.15178@csrd.uiuc.edu> s-mehrotra@uiuc.edu writes:
>You should also consider the recently announced Cray S-MP from 
>Cray Research Superservers, Inc. (don't know if it's shipping yet
>though) that uses SPARCs for scalar processing, custom vector chips,
>and between 4 and 168 i860s in a unit called the Attached Parallel
>Processor (APP). The APP is supported by a parallelizing Fortran-77 
>compiler. The machine binary compatible with Sun SPARC workstations. 
>
>Cray Research Superservers Inc., 3601 SW Murray Blvd., Beaverton, OR 97005
>Ph: (503) 641-3151 		FAX: (503) 641-4497

(Obvious bias: I work for Cray Research Superservers (CRS).)
(Disclaimer: Personal views follow.)

The CRAY S-MP and the CRAY APP are both shipping.  
The CRAY APP is a (flat) shared memory parallel processing system.
In addition to being part of the S-MP platform, the APP can also live as a
networked compute server in a SPARC network.  (This, of course, reduces the 
external bandwidth to VME levels, but also reduces the costs, in case you don't
need the bandwidth.)

There are several examples of codes (including complete "real" ones) that
sustain over 1 GFlop.)  The last Linpack report refers to the CRAY APP as
the CRAY S-MP/MCP with a Linpack 1000 of 742 MFlops on 84 processors.

On the CRAY S-MP, the choice among multiple SPARCs (up to 8 at 67 MHz), Vectors,
or APPs is also a result of the particular algorithm and the size of the data
set and your present and expected requirements in terms of 3rd party software.
Needless to say, there is a much larger set of 3rd party codes available for
SPARC.  It is in fact possible to have a single executable that runs optimally
on either of the three components.

Send me e-mail if you'd like more information.
If you think you might in fact buy one, contact your local Cray Research
sales office.

Speaking for me,
Shahin Khan.
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.arch
Subject: Re: PALcode instructions vs TRAP instructions
Date: 16 Aug 92 21:55:59 GMT
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Organization: Commodore, West Chester, PA

ivie@cc.usu.edu (CP/M lives!) writes:
>In article <1992Aug12.094231.1767@uklirb.informatik.uni-kl.de>, kirchner@uklira.informatik.uni-kl.de (Reinhard Kirchner) writes:
>> 
>> Access, and change of it, by system software might be possible by catching
>> requests of page table changes and preventing write access to those pages.
>> But doesn't this slow down the system? Every access to the page tables,
>> which happens quite frequently, has to checked.
>> 
>Not really. The OS will believe the console code about how much memory is
>available. The console reports the memory size as smaller than physical by
>the amount of memory needed for the PALcode and the console. The OS will not
>try to use the memory thus reserved for PALcode.

	This would seem to be dangerous, because of wild pointers.  Just
because the OS doesn't know about the memory doesn't mean that there won't
be a write to those locations.  I do hope that PALcode fetches are checked
for illegal accesses.

-- 
"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.
Newsgroups: comp.arch
From: haddad@pa.dec.com (Ramsey Haddad)
Subject: Re: question on computer systems using Alpha ... (cooling)
Organization: DEC Western Research Lab, Palo Alto, CA
Date: Thu, 13 Aug 92 16:52:30 GMT

In article <713703530.11137@minster.york.ac.uk> martin@minster.york.ac.uk writes:
>Why doesn't anyone (to my knowledge!) use heat pipes, and/or stirling engines
>for cooling big chips like the alpha?
>Both technologies can move vast amounts of heat, and have been around for many
>years - certainly longer than there have been chips to cool!

In "Packaging a 150W Bipolar ECL Microprocessor", William Hamburgen and
John Fitch describe the use of a "thermosiphon" (which is "essentially a
wickless heatpipe") for just such a purpose.

It was presented at the "42nd Electronic Components and Technology
Conference", San Diego, California, May 18-20, 1992.  It is also available
as Research Report 92/1 from the DEC Western Research Lab.

To get a postscript version e-mailed to you, send electronic mail with the
subject line containing the command "send postscript 92/1" to
"WRL-Techreports@decwrl.dec.com".

The photos in the report won't come out that way, so if you want a hard
copy version, use the command "order 92/1" instead.  Your mailing address
needs to be somewhere in the header or body of the message.

If you are having problems, use the "help" command.

-- 
Ramsey Haddad <haddad@decwrl.dec.com>
speaking for myself.
From: bhandarkar@wrksys.enet.dec.com (Dileep Bhandarkar)
Newsgroups: comp.arch
Subject: Re: question on computer systems using Alpha ...
Date: 12 Aug 92 17:27:05 GMT
Organization: Digital Equipment Corporation


In article <DOCONNOR.92Aug11133018@potato.sedona.intel.com>, doconnor@sedona.intel.com (Dennis O'Connor) writes...
> 
>bhandarkar@wrksys.enet.dec.com (Dileep Bhandarkar) writes:
>] [...] The [ Alpha 21064 ] CPU does need 3.3V. [...] You can derive the 3.3V
>] from a standard 5V supply by using a DC to DC regulator on your circuit board.
> 
>Yes, I'm sure you can, but what does a 10-amp 5V-to-3.3V DC-to-DC
>converter look like, how big is it, does it need a fan, and how
>much does it cost ? :-)
> 
>Seriously, is such a beefy DC-to-DC converter really avaialble ?
>--
>Dennis O'Connor			doconnor@sedona.intel.com

Linear Technology Corporation of Milpitas, CA makes some. They are typically in
TO-3 packages that are about a square inch. A heat sink is needed. The same fan
that cools the microprocessor can cool the regulator. 

/d
Newsgroups: comp.arch,comp.arch.storage
From: rschnapp@metaflow.com (Russ Schnapp)
Subject: Re: Memory Hierarchy Questions
Organization: Metaflow Technologies Inc.
Date: Sat, 22 Aug 1992 01:39:29 GMT

In article <1992Aug21.071534.3737@newsroom.bsc.no>, izahi@bsc.no (Raul Izahi Lopez Hernandez) writes:
|> In article <y6#nqyb.ken@netcom.com> ken@netcom.com (Ken Kofman) writes:
|> >Hi,
|> > 
|> >I have a few questions, and I hope this is the right place to post them.
|> > 
|> >Along these lines, I have also developed an interest in learning about
|> >the kinds of memory hierarchies being designed into real-world larger
|> >systems.  The Patterson/Hennessey book was a good start, but I'm also
|> >interested in actual data.  How does doubling main memory from 200Meg to
|> >400Meg, from 0.5Gig to 1Gig, or from 1Gig to 2 impact the miss rate?  
|> 
|>    It will not affect the miss rate.
|>    The miss rate of such a system is solely determined by the cache so
|> increasing main memory will only decrease the miss penalty since the pager
|> has to go to disk less often.
|>    In the real world of large environmental simulations it DOES help to
|> increase main memory of workstations to 256-512MB+ levels.

Remember that a virtual memory heirarchy includes the page fault rate.  

The page fault rate will be extremely dependent upon the application
mix, the processor, etc.  I have no data for you.
-- 

...Russ Schnapp
BIX: rschnapp           Email: uunet!metaflow!rschnapp or rschnapp@metaflow.com
Metaflow Technologies   Voice: 619/452-6608x230;  FAX: 619/452-0401
La Jolla, CA  92037     Unless otw specified, I`m speaking only for myself!
From: ddr@dcs.ed.ac.uk (Douglas Rogers)
Newsgroups: comp.arch
Subject: Re: Crossbar switching chips - info needed
Date: 21 Aug 92 19:08:34 GMT
Organization: Department of Computer Science, University of Edinburgh


Sorry I don't have the original posting so cannot e-mail my reply.

We have developed here a 4*4 crossbar switch with the intention of developing
a 16*16 or bigger brute if we can persuade some funding body to come up with
the cash. Paper on this to be presentied to IFIP92 in Madrid this Summer.
Mail me for more information.

Douglas
-- 
=============================================================================
Douglas Rogers  MAIL: ddr@uk.ac.ed.dcs  Tel: +44 (0)31-650 5172 (direct dial)
                                        Fax: +44 (0)31-667 7209
=============== So long and thanks for all the fish =========================
Newsgroups: comp.arch
From: preston@dawn.cs.rice.edu (Preston Briggs)
Subject: Re: Caches and Hashing
Organization: Rice University, Houston
Distribution: usa
Date: Wed, 19 Aug 1992 02:03:49 GMT

john@netnews.jhuapl.edu (John Hayes) writes:
>
>> There was an interesting idea in a recent article in Microprocessor
>> Report.  The article was describing HP's PA-RISC.  Here is what caught
>> my eye:
>>         "The caches are direct mapped to eliminate the performance
>>         impact of multiplexers that would be required with set-
>>         associativity.  To reduce the cache miss rates, the addresses
>>         are hashed before they drive the cache SRAMS."*
>> 1) How much does hashing improve the miss rate of a direct-mapped
>> cache?

mitch@sparhawk.com (Mitch Alsup) writes:
>As usual, your milage may vary due to: Application, O/S, cache size.
>With 65KByte sized caches, many applications see only 5% miss rate
>(and with a 10 cycle miss penalty they achieve only 50% machine
>peak performance).  With 1MByte sized caches one could expect ~1%
>miss rate and therefore greater than 90% machine peak performance.
>
>Excellent Hashing can be expected to achieve 40% improvement (max--
>Moyers rule of SQRT(2)-1 for performance gains).  This could allow
>the 65KB cache to achieve 3% miss rates and 70% peak performance;
>or the 1MB cache to achieve 94% machine performance.  Considerable
>gains in the first case and useful in the second.  The 65KB cache 
>PROBABLY would benefit LESS than the larger cache because it is
>operating closed to its intrinsic COMPUSOLRY miss rate (it is smaller)
>while the 1MB cache could benefit more IF the WORKING SET of the
>applicationS fit in the cache.  Also note that the difference in the
>miss rate for the larger cache in direct mapped configruation to
>a set associative configuration is considerably smaller than that
>of the smaller cache.

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

Wondering what the world is coming to,
Preston Briggs
Newsgroups: comp.arch,comp.lang.misc
From: peter@ferranti.com (Peter da Silva)
Subject: PL/1 non-local goto versus setjmp/longjmp
	Re: CISC Microcode
Followup-To: comp.lang.misc
Organization: Xenix Support, FICC
Date: Thu, 13 Aug 1992 14:50:06 GMT

In article <1992Aug12.073130.1@zodiac.rutgers.edu> leichter@zodiac.rutgers.edu writes:
> So now C has TWO distinct
> label constructs:  foo: for "local" labels, setjmp for potentially non-local
> ones.  And you can "assign" the latter, but not the former.  GCC, with its
> label addresses, could at least have unified the two - but, no.

I will be the last to claim that C is perfect, but I think this is an important
distinction. It's bad enough having a label and trying to figure out how it got
there, but if you have to look for gotos in all the subroutines as well...?

Personally, I'd prefer if C had no goto at all, but an organized system of
contexts, so you could perform setjmp/longjmp operations within a routine.

That, and switch, would cover virtually all use of goto while reasonably
restricting its scope. It would also force compiler writers to optimise
switch and longjmp instead of inventing clever hacks of limited utility.
-- 
Peter da Silva                                               `-_-'
$ EDIT/TECO LOVE                                              'U` 
%TECO-W-OLDJOKE Not war?                        Have you hugged your wolf today?
Ferranti Intl. Ctls. Corp.      Sugar Land, TX  77487-5012       +1 713 274 5180
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.arch
Subject: Re: 32 => 64 Transition
Date: 23 Aug 92 01:57:11 GMT
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Organization: Commodore, West Chester, PA

zstern@adobe.com (Zalman Stern) writes:
>In the DEC  
>model where int is 32 bits and long and pointers are 64 bits, size_t should  
>be typedef'ed to unsigned long. That way you can allocate and manipulate  
>arrays larger than 2^32 bytes in size. At MIPS, the counter argument to this  
>was that little code out there actually conforms to the ANSI standard and  
>people use int variables to index arrays all the time. Hence if you want to  
>compile dusty decks and have them use arrays bigger than 2^32 bytes, you  
>want int to be 64 bits...

	But wouldn't most dusty decks be unlikely to want (or handle) arrays
larger than 2^32 bytes?  I'm sure some do, but I would think that 90+% 
(probably 99+%) of dusty decks could care less about such large objects.

	I'd have to side with DEC here, I'm afraid.  I think more and more
software will comply with the standard, and most programs won't be hard to
fix (some will, but those would also be the programs that are hard to maintain
at all).

-- 
"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.
Newsgroups: comp.arch
From: jsnow@moons.sim.es.com (John Snow)
Subject: Re: 32 => 64 Transition
Organization: Evans & Sutherland Computer Corporation
Date: Thu, 13 Aug 1992 21:08:55 GMT

mcvey@mpr.ca (Iain McVey) writes:

>Hmm, perhaps I have my wires crossed here, but I thought that int was
>supposed to be processor defined, and that tiny, short and long were
>of standard size.  ie.

>		16 bit	32 bit	64 bit
>tiny		8	8	8
>short		16	16	16
>long		32	32	32
>long long	(64)	(64)	64

>int		16	32	64

>with pointers implementation dependent.

>no?

>- Iain -
>-- 
>Iain McVey (mcvey@mpr.ca)    | Kodachrome, gives us those nice, bright colours,
>Software Designer            | Gives the greens of summers,
>MPR Teltech Ltd.             | Makes you think all the world's a sunny day.
>8999 Nelson Way, Burnaby, BC | - Paul Simon


According to Harbison & Steele's "C: A Reference Manual":

  "The type int may not be shorter than short and long may not be
shorter int."                                     ---------------
-----------

  "A good rule of thumb is that long is the largest supported integer
size, while int is the largest efficient integer size. If efficiency
is much more important that portability, then the int type may be the
better one to use."

They go on to say that if portability is a goal, then it is best to
define your own data types like INT64, INT32, INT16, INT8. These type
definitions could reside in hardware specific .h files. Only this .h
file needs to change for each hardware implementation and the rest of
the source code stays the same.

--John

--
-----------------------------------------------------------------------------
John F. Snow                         INET:           jsnow@moons.sim.es.com
Evans & Sutherland Computer Corp.    
Salt Lake City, Utah                 America Online: JohnSnow  GEnie: J.SNOW2
Newsgroups: comp.arch,alt.folklore.computers
From: zrepachol@cc.curtin.edu.au (Paul Repacholi)
Subject: Re: Babbage books (was: Proposal: Computer History Project)
Organization: Curtin University of Technology
Date: Wed, 12 Aug 1992 16:49:27 GMT

In article <phillips.713439392@infs4>, phillips@swanee.ee.uwa.oz.au (Christopher Phillips) writes:
> samw@bucket.rain.com (Sam Warden) writes:
>> 
>>I'm amazed that educated, technical people can perpetuate the
>>myth that Babbage failed due to `limited technology'.  Clockwork
>>was a thoroughly mature art and certainly `computationally
>>universal', and Babbage himself was one of the founders of
>>modern machine tooling, as someone has mentioned.  I'm as

His workshop foreman for some years was a gent by the name of Wittworth, the
1/2"x13tpi curse of mechanics for centuries. The Babbage workshop was the 1800's
equivelent of the MIT nano-tech group. The problems were more organizational and
the lack of any other extant example of 'abstract' machines for the mugs in
Whitehall and the houses of parlement to have a 'mind feel' for what could be
done. Who was it in the 60s who was ridiculed for saying that games would be one
of the most important uses of computers?

~Paul

Newsgroups: comp.arch
From: smith@sctc.com (Rick Smith)
Subject: Re: A Little History
Organization: SCTC
Date: Fri, 21 Aug 1992 19:58:58 GMT

I agree with the opinions at the beginning of this thread. I missed the
original post that suggested there's "too much" history being thrown
about here and I'd like to further disabuse the notion.

While it's nice to have history provide the personal touch
(associating a person with a concept) history is especially
significant in computer architecture because many of the concepts
don't really become obsolete.  It's amazing how much of it is
independent of the implementation technology. In other words, things
that worked in tube machines are still being used in VLSI. Sometimes
the only published example of a technique is a historic example, since
today's vendors don't always describe things in as much detail as we
might need. In other cases, "everybody" knows about various classic
examples (Illiac IV for multiprocessing, Cray for vector registers,
B5000 for "thunks") and the peculiarities of the implementation point
the rest of us in particular directions as a result.

What goes around comes around. So it's good to know what's coming.

As for the purely historical things (i.e. how fast were the dinosaurs)
I haven't noticed that much traffic in proportion to everything else.
Besides, alt.folklore.computers carries most of that stuff.

Rick.
smith@sctc.com            arden hills, minnesota
Newsgroups: comp.arch
From: blair@snogum.enet.dec.com (Blair Phillips - Digital)
Subject: Re: 32 => 64 Transition
Reply-To: Blair.Phillips@cao.mts.dec.com
Organization: Digital Equipment Corporation
Date: Thu, 13 Aug 1992 23:06:47 GMT


In article <1992Aug13.182851.18305@mprgate.mpr.ca>, mcvey@mpr.ca (Iain McVey) writes:
>Hmm, perhaps I have my wires crossed here, but I thought that int was
>supposed to be processor defined, and that tiny, short and long were
>of standard size.  ie.
>
>		16 bit	32 bit	64 bit
>tiny		8	8	8
>short		16	16	16
>long		32	32	32
>long long	(64)	(64)	64
>
>int		16	32	64
>
>with pointers implementation dependent.
>
>no?
>
NO!

The only guarantees are that

     long >= int >= short >= char

(I haven't seen a definition of "long long" -ugh! but I think it is safe to 
assume that 
     long long >= long)

After all where would your definitions leave computers with word lengths of
24, 36, 48 or 60 bits? Or character lengths of 6, 7, 9, 12, or 15?
I've had to deal with all of these at one stage or another.

And it isn't all ancient history, either. Windows-NT uses Unicode as its native
character set, requiring 16 bit characters.

This is a language problem rather than an implementation one. Sensible
languages let you declare the range of values you need, and let the compiler
work out how many bits that needs.
--
----------
Blair Phillips					Blair.Phillips@cao.mts.dec.com
Digital Equipment Corp (Aust) P/L		Phone: (+61 6) 2754874
7-11 Barry Drive, Turner, ACT 2601 AUSTRALIA	FAX  : (+61 6) 2473654

Newsgroups: comp.arch
From: lindsay+@cs.cmu.edu (Donald Lindsay)
Subject: Re: PA-RISC Virt Addr > 32 bits
Organization: School of Computer Science, Carnegie Mellon
Date: Sat, 22 Aug 1992 22:38:27 GMT


haw30@macaw.ccc.amdahl.com (Henry A Worth) writes:
>   Is the >32 bit virtual addressing strictly limited to the OS, or is 
>it possible for user processes to map multiple address spaces and use
>"far pointers"?  If not, is there any announced intent to provide 
>such features in future OS's?

I believe that there is non-privileged access, and that HP has
allowed non-OS code to use the feature.

They may live to regret this fact. HP's niche is higher-priced
systems, which (after supercomputing) will be the first niche to feel
market pressure for true 64 bit addressing. HP will have a
compatibility problem which is different (and worse) from the one the
R4000 presents.
-- 
Don		D.C.Lindsay 	Carnegie Mellon Computer Science
Newsgroups: comp.arch