HDTenEightyP/NetNews huggingface dataset:
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.arch
Subject: Re: CACHE MISS PENALTY FOR 386/486??
Date: 19 Aug 92 17:36:40 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <PCG.92Aug19114950@aberdb.aber.ac.uk>, pcg@aber.ac.uk (Piercarlo Grandi) writes:

| Probably you are assuming a bit too much. I have seen dozens of types of
| AT style systems, and none was 'typical'. Actually I doubt that a
| 'typical' AT style system exists.

  Most of the decent 486 board seem to have either Nx9 SIMMs in groups
of four, usually with no interleave even if you have two banks, or Nx36
SIMMs with or without interleave. Interestingly some of the cheap boards
have 2 and 4 way if you populate them.

-- 
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: pcg@aber.ac.uk (Piercarlo Grandi)
Newsgroups: comp.arch
Subject: Re: Summary of responses [was: What would you like from a debugger?]
Date: 17 Aug 92 15:35:02 GMT
	<BEVAN.92Aug14130951@jaguar.cs.man.ac.uk>
Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
Followup-To: comp.arch
Organization: Prifysgol Cymru, Aberystwyth

On 14 Aug 92 12:09:51 GMT, bevan@cs.man.ac.uk (Stephen J Bevan) said:
Followup-To: comp.arch

bevan> (Peter da Silva) writes:
bevan> (Bryan O'Sullivan) writes:

Silva> I haven't decided yet what constitutes the smallest debugger I
Silva> can get away with, but such things as printing data structures
Silva> and their contents on the fly are out of the question.

Bryan> Embed an interpreted language in the debugger (drive it from
Bryan> TCL?).

bevan> You mean like Norman Ramsey's use of PostScript as the "little
bevan> language" with which to drive his debugger "ldb"?  Check out PLDI
bevan> '92 pp 22-31

There is also this incredible X-based debugger from the University of
Kent at Canterbury, which is also (still?) free sw, that contains as
extension language C itself. Really! It is a debugger that incorporates
as one component a C compiler and interpreter.
--
Piercarlo Grandi                   | JNET: pcg@uk.ac.aber
Dept of CS, University of Wales    | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk
From: lindsay+@cs.cmu.edu (Donald Lindsay)
Newsgroups: comp.arch
Subject: Re: trapping speculative ops
Date: 23 Aug 92 02:18:55 GMT
Article-I.D.: cs.BtEzrK.Jso.2
Organization: School of Computer Science, Carnegie Mellon


chased@rbbb.Eng.Sun.COM (David Chase) writes:
>...being able to read zeros from page zero.  
>This lets you do a slightly better job of pipelining loops
>of the form
>
>   while (p != 0 && p -> data != K) p = p -> next;

>>Don't you want the user code to trap?
>No, not if it makes the code run significantly slower.

I agree that an invalid zero page stops you from pulling this
specific optimization. However, the invalid page trick has several
virtues: it has no impact on hardware cost or speed, and it can
detect bugs _after_ debugging is thought to be over.

But this is just a specific optimization. The broader question is,
waht about traps while executing speculatively? There seem to be two
answers:

1) Let the hardware do all the speculative execution. This puts it on
the hardware's head to not trap until it knows it really should have.

2) Allow compiled code a way to postpone consequences until it
wants to know. This covers e.g.

	if( b != 0 ) c = a/b;

and an assortment of other cases.

The problem with (1) is that it makes for complex hardware. The
problem with (2) is that instruction sets are generally not set
up to allow such leeway.
-- 
Don		D.C.Lindsay 	Carnegie Mellon Computer Science
From: engp1186@nuscc.nus.sg (Won-Soon Lau)
Newsgroups: comp.arch
Subject: Microprocessors Report Subscription Info Wanted
Date: 20 Aug 92 03:42:34 GMT
Reply-To: engp1186@nuscc.nus.sg
Organization: Dept. EE, National Univ. of Singapore

Can someone please email me the detail of subscribing to the "Microprocessors
Report" magazine.  Thanks in advance.

Won-Soon Lau
-- 
Dept of Electrical Engineering         \  Internet: engp1186@nuscc.nus.sg
National University of Singapore        \  Phone:  (+65) 772 6319       
10, Kent Ridge Crescent. Singapore 0511. \______________________________
From: pcg@aber.ac.uk (Piercarlo Grandi)
Newsgroups: comp.arch
Subject: Re: CACHE MISS PENALTY FOR 386/486??
Date: 19 Aug 92 11:49:50 GMT
Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
Organization: Prifysgol Cymru, Aberystwyth

On 19 Aug 92 04:23:18 GMT, eletanjm@nuscc.nus.sg (TAN JIN MENG) said:

eletanjm> Just what is a typical cache miss penalty on (1) a 386 system
eletanjm> with external cache (2) a 486 system with only internal cache
eletanjm> (3) a 486 system with internal cache and external secondary
eletanjm> cache

I think it is about something percent. :-)

More seriously, the cache miss penalty depends on several parameters,
just like memory accesses, including for example how the memory is
organized, the bus transactions used to access memory, and so on. The
range of variation is quite large.  In some boards the way the memory
works depends on how much memory you put in, for example.

eletanjm> I'm assuming an typical AT style system.

Probably you are assuming a bit too much. I have seen dozens of types of
AT style systems, and none was 'typical'. Actually I doubt that a
'typical' AT style system exists.

eletanjm> Just how do you determine the miss penalty anyway?

You ask the designer of the board, if s/he has got any clue (which may
or may not be the case), or you use a suitable analyzer (a fast storage
oscilloscope may be enough) hooked to the relevant pins.
--
Piercarlo Grandi                   | JNET: pcg@uk.ac.aber
Dept of CS, University of Wales    | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk
Newsgroups: comp.arch
From: mat@mole-end.matawan.nj.us
Subject: Re: A Little History
Summary: On History
Organization: :
Date: Sun, 23 Aug 1992 06:48:54 GMT

In article <1478@seqp4.sequoia.com>, jcooley@seqp4.sequoia.com (John Cooley) writes:
> > From: jesup@cbmvax.commodore.com (Randell Jesup)

> > ...  What I'm proposing is to split comp.arch, in an attempt to move
> > the discussions of computer architecture history into a seperate group.

> >       There have been recurrent long discussions/reminiscences of ancient
> > general volume level is increasing with the internet population, in any case
> > it has become a problem IMHO).
 
> There seems to have been an almost Stalinist approach to writing
> most college textbooks on physics, programing and electronics with the
> goal of purging practically all references to the people who did the original
> research.  ...
 
> ... electrical engineer, I never even heard ... the stories and legal
> battles the inventors of AM and later FM radio went through ... until a
> recent ... show on PBS called "Empire of the Air".  Why wasn't I taught
> this somewhere in school?  ...

This is one of my hot buttons.  Who the blazes cares who signed the
treaty of Utrech, or how many parts Gaul was divided into?  I want to
read about Coulomb and Galva and Paracelsius and Edison and Zworykin.

_That's_ why history is so boring!  Because it's all about stuff that
none of cares about.  Now, the inventor of the Smith Chart?  Who was
he?  What became of his first name?  What _was_ his first name?  Tell
me about Mr. Smith!

I'm ranting a bit, of course.  And I want to know about Metternich as
well as about Mr. Smith.  But I have a viewgraph with 26 names on it.
Each of the 26 people named thereupon made a significant and particular
contribution to the world in which we live.  Most made their contributions
in electrotechnology, but not all.

I presented this, just after lunch, to four different classes, each filled
with practicing EE's and software developers.  And not one of the classes
was able to identify half the names.  (And yes, some appeared in `Empire
of the Air.')

I'm appalled.

One more paragraph before I let this newsgroup go back to its charter:
I offer a copy of these names by electronic mail, and a second mailing,
if it is needed, with the `answers.'  This offer is open to all.  Try
it, test yourself!

(For that matter, what about Messrs. Quine and McCluskey?  Have I
got those names right?  The prof I had for that class was known as
The Babbling Blonde Buffoon.)
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
Xref: sparky comp.arch:8941 alt.folklore.computers:12689
From: hgz@cs5.informatik.uni-stuttgart.de (Hans-Georg Zipperer)
Newsgroups: comp.arch,alt.folklore.computers
Subject: Re: Babbage books (was: Proposal: Computer History Project)
Date: 18 Aug 92 07:44:34 GMT
Organization: Informatik, Uni Stuttgart, W. Germany

In article <1992Aug13.181353.22013@imax.imax.com> dave@imax.imax.com (Dave Martindale) writes:
>In article <1992Aug11.134401.26906@grmbl.saar.de> me@grmbl.saar.de writes:
...
>>[about the adding mechanism of the Babbage engines]
...
>This is not true of the Difference Engine, at least.  The basic addition
>is done with all digits in parallel, but that's a relatively constant load.
>Any carries generated just result in a little lever being moved to a
>new position (Babbage called it "warned"), but no carry propagation happens
>at this stage.
>
>Then, when the main addition is done, another piece of mechanism comes
>into play to handle carry propagation, and that is done serially.
>Each digit wheel is rotated one place if a carry is pending in that
>position, and any "carry in" that creates a "carry out" at this stage
>simply sets the "carry in" lever for the next higher digit, before the
>carry happens in that place.  So the more digits you have the longer the
>carry process takes, but at any given time there are at most two or three
>pieces of hardware moving.
>
>I don't know what the Analytical Engine did for addition, though.
>
>	Dave

The Difference Engine indeed used the carry mechanism described above.
Babbage needed 10 'time steps' for the main addition and spent a lot
of time to speed up the following carry propagation. He used his
'mechanical notation' (a formal language for the description of
mechanical motions) to reason about this and found a way to do the
carry propagation for his 20 or 30 digits in 10 time steps. Babbage then
used some kind of pipelining in the Difference Engine. One basic cycle
of the engine was divided in 4 subcycles. In the first subcycle, the
even-numbered columns (registers) were added to the odd-numbered columns.
In the second subcycle, the carry propagation for this additions was
done. In the third and fourth subcycles, the odd-numbered columns were
added to the even-numbered columns in the same fashion.

For the Analytic Engine, Babbage wanted 50 decimal places. This would
make the carry propagation slower than the main addition and would slow
down the whole system. In 1834, he invented the 'anticipating carriage'
(look-ahead carry), which solved the problem. The new adder still needed
10 time steps to do the main addition, but the carry propagation for an
unlimited number of digits could be done in a single time step afterwards.

-- 
  Hans-Georg Zipperer     Universit"at Stuttgart, Institut f"ur Informatik
  Tel. (0711) 7816-405    e-mail: zipperer@ifi.informatik.uni-stuttgart.de
Newsgroups: comp.arch,alt.folklore.computers,comp.benchmarks
Newsgroups: comp.arch
Subject: DSP music/sound processing
From: bell2@lincoln.ac.nz
Date: 14 Aug 92 09:24:45 +1200

I have been considering a hardware project for digital audio (home/hobby),
I am technically competent with basic u/Processor systems design, What I
am interested in is maybe using a DSP processor, I believe many computers
with music/sound processing capabilities are using the DSP56001,

What are the capabilities of DSP processors,

What advantages/disadvantages to they have over microprocessors?

Could someone give a brief technical summary of the DSP56001

Any ideas for real cool hardware for sound processing.

-- 

Stephen Bell                                          -----
c/- A.V.S.G.                                            |
Lincoln University                     \---------------(*)---------------/
Canterbury
New Zealand                                     NIMBUS II - Driver

Email: S.Bell@ono.lincoln.ac.nz
Newsgroups: comp.arch
From: zrepachol@cc.curtin.edu.au (Paul Repacholi)
Subject: Re: PALcode instructions vs TRAP instructions
Organization: Curtin University of Technology
Date: Mon, 17 Aug 1992 15:45:01 GMT

In article <34303@cbmvax.commodore.com>, jesup@cbmvax.commodore.com (Randell Jesup) writes:
> 
> 	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.
> 

If you are worried about wild pointers at this level, it's 'fat owl' time
any way.

What would set up the checks for the PAL code? Note that on a EV-4 the initial
PALcode executes with NO acess to memory till it sets up the secondary
cache control registers, BIU control ect. The only thing you can do at this
level of do-do is dump as much info as possible in a safe place, and quit
before you make things worse.

~Paul

Newsgroups: comp.arch,alt.folklore.computers,comp.benchmarks
From: rschnapp@metaflow.com (Russ Schnapp)
Subject: Re: HP-97 Calculator
Organization: Metaflow Technologies Inc.
Date: Wed, 12 Aug 1992 23:14:08 GMT

In article <11AUG199221494044@erin.caltech.edu>, shoppa@erin.caltech.edu (TIM SHOPPA) writes:

|> both writing and reading.  I tried making cards for my HP calculator (an
|> old desktop unit, whose model number I can't recall right now, that has
|> a four-line vector CRT display and magnetic core, which means that it 
|> doesn't forget when the power is turned off) and was similarly unsuccesful.

Holy moly!  I remember that model.  It was the first programmable
calculator I ever encountered.  My high school math teacher got me to
program a simple (2-D) discrete simulation of orbital motion on that
baby.  We're talking 1972, here...
-- 

...Russ Schnapp
BIX: rschnapp           Email: uunet!metaflow!rschnapp or rschnapp@metaflow.com
Metaflow Technologies   Voice: 619/452-6608x230;  FAX: 619/452-0401
La Jolla, California    Unless otw specified, I`m speaking only for myself!
Newsgroups: comp.arch
From: graef@rs5.hrz.th-darmstadt.de (Ulrich Graef)
Subject: Re: Threaded Code
Date: Mon, 17 Aug 1992 13:59:55 GMT
Organization: TU Darmstadt

In article <34301@cbmvax.commodore.com>, jesup@cbmvax.commodore.com (Randell Jesup) writes:
> martin@math.rwth-aachen.de (  Martin Schoenert) writes:
> >Subroutine threading (sub.c):
> >    For each instruction there is a (C) function which implements this
> >    instruction.  The instructions are encoded with the addresses of
> >    those functions.  Each function returns after it has done its work,
> >    and there is a central dispatcher in 'main', which looks as follows
> >    'while (1) (**pc++)();'
> 
> 	This is not what I would call "subroutine threading".  Subroutine
> threading (at least from my perspective of having written a subroutine-
> threaded forth) means that you do not have an array of function addresses,
> you have an array of "jsr <address>".  On top of that, the code that
> generates the instructions can inline when appropriate (a big win in forth
> on modern processors, since many simple operations are smaller than an
> instruction or even an address).
> 
> 	I'm not sure what I'd call your method.  It's big problem is that
> it requires an explicit "interpret" instruction to call an instruction
> written from instructions instead of as a pre-existing C routine.  If I had
> to name it I would call it an "explicit-threaded interpreter", since the
> thing that compiles the code must know to generate "interpret" instructions
> to execute words that need interpretation, while all standard methods of
> threading do not need to know.

I think, you both are right. Martin calls a method `subroutine threading'
which is used in interpreters which are written in C.
The `subroutine threading' of Randell, which is often used in Forth
interpreters is the `indirect threading' of Martin.

The interpreters of Martin are intended to test the method.
Therefore they are small and have not the ability to compile 
code like an Forth-interpreter.


Uli

-- 
Ulrich Graef        |  analog (phone) :  +49 6155 62493           
Lichtenbergweg 11   |  digital (Email): graef@hrz.th-darmstadt.de 
D-W-6103 Griesheim  +--------------------------------------------
Germany             |  Nothing is real, look into your mirror!
Newsgroups: comp.arch
From: bhandarkar@wrksys.enet.dec.com (Dileep Bhandarkar)
Subject: Re: question on computer systems using Alpha ... (cooling)
Organization: Digital Equipment Corporation
Date: 13 AUG 92 10:44:26    


In article <713703530.11137@minster.york.ac.uk>, martin@minster.york.ac.uk writes...
>hallam@zws010.enet.dec.com says:
>> Perhaps this will supur the developmen of some non standard cooling
>> methods. My favorite suggestion is to use the heat sink to keep the
>> coffee warm...
> 
>Perhaps this is time to ask something I've often wondered....
> 
>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!
> 

We have been doing research on heat pipes for "bacon sizzling" 100+ watt chips.
30 watts can be handled with more conventionial heat sinks with moderate amounts
(<200 linear feet per minute) of air flow.

Dileep
From: krste@ICSI.Berkeley.EDU (Krste Asanovic)
Newsgroups: comp.arch
Subject: Die aspect ratio.
Date: 13 Aug 1992 19:42:38 GMT
Organization: International Computer Science Institute, Berkeley, CA, U.S.A.
Distribution: world
NNTP-Posting-Host: icsib43.icsi.berkeley.edu


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.

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

Thanks.
-- 
Krste Asanovic,                 Computer Science Division, 
email: krste@cs.berkeley.edu    571 Evans Hall
phone: +1 (510) 643-8733        University of California at Berkeley
fax:   +1 (510) 643-7684        CA 94720, USA
From: nmodi@klinzhai.rutgers.edu (Nirav Modi)
Newsgroups: comp.arch
Subject: Graphics board(VGA), Reading material
Date: 13 Aug 92 21:50:57 GMT
Organization: Rutgers Univ., New Brunswick, N.J.


Hello
	I have request for IBM PC Hardware Gurus.

	Right now I am working on a hardware project. For my project
work, I am designing a graphics board which connects two VGA cards
(8 bits outputs , speed 36.5 MHz) and selects one of VGA card output.
I have controller to select VGA  card output. 

	I am storing output in static RAM and providing it to another
VGA card.

	I am looking reference material -related books, papers with
graphics board.

	Can you be kind enough to guide me?
	
	I will be very much thankful to you.
	
	Thank you very much and Have a nice day.

-Nirav Modi
nmodi@klinzhai.rutgers.edu
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Nirav B. Modi
(908)699-1124(Home)
(908)932-4786(School)
email address: nmodi@klinzhai.rutgers.edu
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Newsgroups: comp.arch
From: schow@bqneh3.bnr.ca (Stanley T.H. Chow)
Subject: Re: 32 => 64 Transition
Organization: Bell Northern Research Ltd, Ottawa
Date: Wed, 12 Aug 1992 15:53:17 GMT

In article <l8gi9jINNaad@exodus.Eng.Sun.COM> chased@rbbb.Eng.Sun.COM (David Chase) writes:
>Howsabout the *debuggers* do it, 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.  

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

Even if you specify that only the compiler is allowed to make this
assumption, how do you prevent user code from doing this? How about
user code that inadverdently do this? Don't you want the user code
to trap?

--
Stanley Chow            InterNet: schow@BNR.CA
Bell Northern Research  UUCP:     ..!uunet!bnrgate!bqneh3!schow
(613) 763-2831
Me? Represent other people? Don't make them laugh so hard.
From: leichter@zodiac.rutgers.edu
Newsgroups: comp.arch
Subject: Re: CISC Microcode
Date: 12 Aug 92 11:31:30 GMT
Organization: Rutgers University Computing Services

In article <1992Aug05.203238.141042@cs.cmu.edu>, lindsay+@cs.cmu.edu
(Donald Lindsay) writes:
| 
| hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
||[Describes FORTRAN assigned goto's]
| 
| If people think that that led to ugly code, then imagine PL/I, where
| the recursion level was also placed in variable K. When you did the
| GOTO, the call stack and "display" would be unwound until you had
| returned to the level known from variable K.
| 
| One of the Great Bad Ideas.

Just what is the difference between this and setjmp/longjmp?  Oh, I know,
the label names for such computed gotos were at least statically determin-
able - since they were syntactically distinct labels - while a jmpbuf can
be filled dynamically, potentially at any function call.  Except, of course,
in ANSI C, which, because of implementations that have to really unwind the
stack, required that setjmp be a macro, so that the compiler can again
determine where the possible "labels" are.  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.

My how computer science advances, throwing out the Great Bad Ideas, bring in
the new ones!  :-)
							-- Jerry
Newsgroups: comp.sys.apple,comp.sys.apple2