HDTenEightyP/NetNews huggingface dataset:
From: kak1@cray.com (Kevin Kramer)
Subject: Re: Does a 487sx shut down the 486sx??
Organization: Cray Research, Inc.
Date: 19 Aug 92 15:48:15 CDT

In article <1992Aug19.155448.18248@ilinx.wimsey.bc.ca> brian@ilinx.wimsey.bc.ca (Brian J. Murrell") writes:
>ks3l+@andrew.cmu.edu (Kenton Shaver) writes:
>
>>Could anyone clear this up for me?
>>I read it in some magazine, but my ECE
>>friend is credulous.  Will my 487sx
>>just shut the 486sx down and take over?
>
>That's what I heard.  IMHO the 486sx is a *big scam*.
>
>To get your 486sx you buy a chip which is a functional 486dx with the 
>co-pro disabled (yes more work than a regular 486dx - yet cheaper!).
>At some point in the future you need the co-pro, so you buy a 487sx, which
>is just the regular 486dx with a 487sx stamp on it, which shuts down the
>486sx crippled chip and takes over the machine running it like the 486dx
>it should have been!!
>
>The above is all rumour I've heard from many sources, and read in a trade
>rag.  It is not the gospel!!
>

I don't think it involves more work to make the 486sx chips, they are probably
rejected chips because of a fault in the math coprocessor part.  So they just
disable that section of the chip and now they can use what once was a bad
chip.  It is a big scam IMHO, I can't see why anyone would buy one of these.

Kevin
Newsgroups: comp.arch
From: jan@pallas.neuroinformatik.ruhr-uni-bochum.de (Jan Vorbrueggen)
Subject: Re: question on computer systems using Alpha ... (cooling)
In-reply-to: martin@minster.york.ac.uk's message of 13 Aug 92 10:58:50 GMT
Organization: Inst. f. Neuroinformatik, Ruhr-Universitaet Bochum, FRG
	<DOCONNOR.92Aug11133018@potato.sedona.intel.com>
	<1992Aug12.121427.10251@dscomsf.desy.de>
	<713703530.11137@minster.york.ac.uk>
Date: 14 Aug 92 13:59:36

   Why doesn't anyone (to my knowledge!) use heat pipes, and/or stirling
   engines for cooling big chips like the alpha?

Look at the design of the GC machines from parsytec. They (will) put
8 T9000 plus memory and assorted glue onto a Eurocardsize board,
cloak the noncomponent side with machined aluminum, put two of these
boards facetoface, and insert heat pipes into the aluminum grooves.
I've calculated from their numbers for a big machine that they expect
about 26W per processor (of which a max of 8W is from the T9000). So
one 16processor sandwich will dissipate 416W.

Actually, cooling shouldn't be much of a problem  provided you can
actually make good enough contact with your silicon to keep the 
equilibrium down. For a 16k processor GC machine, parsytec expects it
to dissipate about 430kW. Sounds like a lot? Now look at a 400 horse
power truck motor. 400 hp is roughly equivalent to 300kW, and the motor
dissipates at least twice that in heat (efficiemcy is around 30%).
No problem, all you need is a nice 60 km/h air flow into your computer
room...

 Jan Vorbrueggen, jan@neuroinformatik.ruhrunibochum.de
Newsgroups: comp.arch
Newsgroups: comp.arch,alt.folklore.computers
From: hugh@cs.toronto.edu ("D. Hugh Redelmeier")
Subject: Re: Babbage books (was: Proposal: Computer History Project)
Organization: Department of Computer Science, University of Toronto
Date: 13 Aug 92 04:01:49 GMT

me@grmbl.saar.de (Martin Emmerich) writes:
| He also didn't use asynchronous counters (I mean that the force,
| you use to turn in the lowest number wheel gets used to turn the
| whole bank of wheels if you have a carry which propagates from
| the lowest to the highest decimal). This gets important if you
| have a very big number of decimals (his universal machine had
| about fifty). All tolerances add together and the wheels get
| stuck.

I happened to be in the Science Museum in London last week, looking
at bits of Babbage engines.  I didn't know that there would be a
quiz, so I paid insufficient attention.  Here is what I think I
remember:
- the carry-outs were stored in a per-digit register
- a subsequent step did the carry-in
- the whole set of carry-in operations were done with one rotation
  of a shaft.
- BUT the carry-ins were not processed simultaneously -- they were
  staggered, taking a certain number of degrees of the rotation.
  Clearly, the low-order carry-ins were handled first.
- It would seem that this would limit the number of digits in a
  register -- how many degrees were needed for each operation?
  50 digit registers seemed to work, if I remember correctly.

There was a whole display about this.  It claimed that Babbage was
proud of this particular structure.  I would have been too.

On another point, it seemed as Babbage's mechanic was important.  I
don't remember the details precisely, but:
- he could build *very* well
- he could draught well
- few people had both of these skills
- he charged a lot, but was worth it (details of a suit with another employer)
- he broke with Babbage something like ten years into their work

Hugh Redelmeier
hugh@mimosa.com or {utcsri, yunexus, utzoo, scocan}!redvax!hugh
When all else fails: hugh@csri.toronto.edu
+1 416 482-8253
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.arch
Subject: Re: Threaded Code
Date: 16 Aug 92 21:20:42 GMT
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Organization: Commodore, West Chester, PA

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.

	The various forms of threading have been heavily explored in Forth
literature and implementations over the years.  If you're really interested
in efficient interpretation, I advise reading some of the Forth literature
(FORML proceedings, Rochester forth proceedings, even old Byte and Dr. Dobbs
issues, etc).

-- 
"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: peter@ferranti.com (peter da silva)
Subject: Re: Summary of responses [was: What would you like from a debugger?]
Organization: Xenix Support, FICC
Date: Mon, 17 Aug 1992 16:56:45 GMT

In article <BEVAN.92Aug14130951@jaguar.cs.man.ac.uk> bevan@cs.man.ac.uk (Stephen J Bevan) writes:
> You mean like Norman Ramsey's use of PostScript as the "little
> language" with which to drive his debugger "ldb"?

A PostScript subset, I assume? No rendering?

> Check out PLDI '92 pp 22-31

PLDI?

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

I can buy that. I'd love an embeddable PostScript subset for general
hacking. Been looking for one for a while. Know where I can get one?
What's Norman's address?
-- 
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
Newsgroups: comp.arch
From: kmodiri@cs.ruu.nl (Kambiz Modiri)
Subject: kamer gezocht
Summary: kambiz
Date: Tue, 18 Aug 1992 09:35:42 GMT
Organization: Utrecht University, Dept. of Computer Science
Keywords: @#LN*

 Ik ben heen en weer reizen zat .Wie helpt mij aan een kamer in Utrecht
 of omstreken?
 Tel: 033- 728157
From: eletanjm@nuscc.nus.sg (TAN JIN MENG)
Subject: CACHE MISS PENALTY FOR 386/486??
Organization: National University of Singapore
Date: Wed, 19 Aug 1992 04:23:18 GMT

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

I'm assuming an typical AT style system.

Just how do you determine the miss penalty anyway?
Newsgroups: comp.arch,comp.lang.c,comp.programming,comp.unix.programmer
From: peter@ferranti.com (Peter da Silva)
Subject: Re: Summary of responses [was: What would you like from a debugger?]
Keywords: summary,debugging
Organization: Xenix Support, FICC
Date: Thu, 13 Aug 1992 15:24:31 GMT

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

Then write a program to generate a routine for printing a structure based on
the structure contents, and bind it to a data type.

Stick these in a file so the debugger can find them on demand.

This is sort of like "ctags": you don't have the editor grubbing through a
bunch of files every time you want to find a tag. It's also a more useful and
general tool than having too many smarts hardcoded into the debugger.

If you drive the debugger from TCL, someone else can write the object browser
in TK.

I don't think I want the debugger command language to be C. C isn't really
well suited to the job. Actually, I'd kind of like a Postscript type language,
but then I'm a Forth nut.

As for finding C source, I'd like a couple of related features:

	1. An interactive mode, where if it can't find a file it asks
	   you where it is.

	2. A tags file, containing the location of functions, that you
	   can build with an external tool.

In fact, having an option that puts you into an editor on the tags file
when it can't find a source file would be a good thing.

A TCL autoload file could be used for this and for the structure display
stuff, above.

> 1) a programmable interface - the human debugger should be able to
>    write some debugger script for things such as step-by-step every C
>    instruction until such condition". The debugger language should
>    absolutely be programmable. Perhaps a public domain small lisp
>    interpreter -such as Emacs lisp or Xlisp- is a good starting point.

That would also be good... though I think TCL is a better command language
than Lisp, Lisp tends to be faster. The biggest problem with lisp is the
baroque set of basic routines.

>    The window interface to the debugger should also be programmable.

TK? WINTERP?

> Ok.  I'd like a complete programming environment as a debugger (say in
> scheme or tcl or something).

Another vote for a command language!

Of course if you design an API for the debugger and it's clean enough this
would become a peice of cake. DON'T forget callbacks on breakpoints!
-- 
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
Newsgroups: comp.arch
From: bhandarkar@wrksys.enet.dec.com (Dileep Bhandarkar)
Subject: Re: Microprocessors Report Subscription Info Wanted
Organization: Digital Equipment Corporation
Date: 20 AUG 92 16:26:03    


In article <1992Aug20.034234.28600@nuscc.nus.sg>, engp1186@nuscc.nus.sg (Won-Soon Lau) writes...
>Can someone please email me the detail of subscribing to the "Microprocessors
>Report" magazine.  Thanks in advance.
> 
One year costs $575 outside US and Canada. Additional copies @ $195.
Address: Microprocessor Report, 874 Gravenstein HWY So, Suite 14, Sebastopol,
CA 95472, USA.

Tel: (707)823-4004
FAX: (707)823-0504

They do accept Visa, Mastercard, and AmEx.
From: S_JUFFA@iravcl.ira.uka.de (|S| Norbert Juffa)
Newsgroups: comp.arch
Subject: No more email request for fp bibliography, please!
Date: 21 Aug 1992 10:59:36 GMT
Organization: University of Karlsruhe (FRG) - Informatik Rechnerabt.
Distribution: world
NNTP-Posting-Host: irav1.ira.uka.de
X-News-Reader: VMS NEWS 1.23

Dear netters:

Yesterday I offered a bibliography on floating-point arithmetic. Since then
I have gotten > 40 mails requesting the bibliography. I didn't expect that
there was that much interest in the topic. Before I get inudated with even
more email request, I will post the bibliography to this newsgroup. So please
refrain from sending email requests from now. Thanks!

Norbert
------------------------------------------------------------------------------
Norbert Juffa        email: S_JUFFA@IRAVCL.IRA.UKA.DE       Live and let live!

Newsgroups: comp.arch,alt.folklore.computers,comp.benchmarks
From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879)
Subject: Re: HP-97 Calculator
Date: Wed, 12 Aug 1992 15:03:33 GMT
Organization: University of Iowa, Iowa City, IA, USA

From article <11AUG199221494044@erin.caltech.edu>,
by shoppa@erin.caltech.edu (TIM SHOPPA):
>                                                 ... 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.
> Looking in the innards of the unit, it was fairly clear that there were
> at least two tracks on the card.  (The innards are neat too.  A motherboard
> with some sort of diode matrix (microcode??  vectors for the CRT display??)
> and several cards that plug in.)

You have a classic antique desktop computer, one of the first two
programmable calculators ever marketed!  Save it and care well for it,
because it'll be a museum piece someday.

The diode matrix contains low level microcode that runs on a digit serial
processor and that emulates a digit-parallel architecture for use by the
higher level microcode.  The middle layer in the architecture consists of
microcode that is stored in a braided wire memory; this runs on the digit
parallel architecture provided by the low level microcode, and it
implements the stack architecture, the fancy operations like trig
functions, keyboard management, and interpretation of programs from core
and mag cards.

The above description is from memory; the machine is described in one of
the chapters of Computer Architecture, Readings and Examples, by Bell and
Newell, and I used one in 1971 or so when it was the newest calculator in
the modern physics lab at Carnegie Mellon University.

					Doug Jones
					jones@cs.uiowa.edu
From: hojungc@cs.man.ac.uk (Hojung Cha)
Newsgroups: comp.arch
Subject: Crossbar switching chips - info needed
Date: 12 Aug 92 14:34:45 GMT
Reply-To: hojungc@cs.man.ac.uk (Hojung Cha)
Organization: Department of Computer Science, University of Manchester UK

Apology if this is much out-of-date question.

As part of our multiprocessing hardware project, we are looking 
for some commercially available bit-parallel crossbar switching 
chips. So far we've found a couple of such chips; for instance, 
AMD's Am29C983 Multiple Bus Exchange chip and TI's 74ACT8841 
(I heard that the TI chip is now obsolete). Are there other such 
chips available in the market (or in the research lab) ?  
Any response will be much appreciated.

Regards,
Hojung Cha

--
-------------------------------------------------------------------
Hojung Cha
Dept. of Computer Science          Phone    : +44 61 275 6255
University of Manchester           Fax      : +44 61 275 6236
Manchester M13 9PL, U.K.           E-mail   : hojungc@cs.man.ac.uk
-------------------------------------------------------------------
Xref: sparky comp.arch:8969 comp.sys.ibm.pc.hardware:22260
From: ahaley@eoe.co.uk (Andrew Haley)
Newsgroups: comp.arch,comp.sys.ibm.pc.hardware
Subject: Re: Does a 487sx shut down the 486sx??
Date: 20 Aug 92 09:44:21 GMT
Organization: EO Europe Limited, Cambridge, UK
X-Newsreader: Tin 1.1 PL3

kak1@cray.com (Kevin Kramer) writes:
: In article <1992Aug19.155448.18248@ilinx.wimsey.bc.ca> brian@ilinx.wimsey.bc.ca (Brian J. Murrell") writes:
: >ks3l+@andrew.cmu.edu (Kenton Shaver) writes:
: >
: >>Could anyone clear this up for me?
: >>I read it in some magazine, but my ECE
: >>friend is credulous.  Will my 487sx
: >>just shut the 486sx down and take over?
: >
: >That's what I heard.  IMHO the 486sx is a *big scam*.
: >
: >To get your 486sx you buy a chip which is a functional 486dx with the 
: >co-pro disabled (yes more work than a regular 486dx - yet cheaper!).
: >At some point in the future you need the co-pro, so you buy a 487sx, which
: >is just the regular 486dx with a 487sx stamp on it, which shuts down the
: >486sx crippled chip and takes over the machine running it like the 486dx
: >it should have been!!
: >
: >The above is all rumour I've heard from many sources, and read in a trade
: >rag.  It is not the gospel!!
: >
: 
: I don't think it involves more work to make the 486sx chips, they are probably
: rejected chips because of a fault in the math coprocessor part.  So they just
: disable that section of the chip and now they can use what once was a bad
: chip.  It is a big scam IMHO, I can't see why anyone would buy one of these.
: 
: Kevin

No, you've got out of date info.  Originally the 486sx _was_ a 486
with the FPU disabled.  AFAIK, Intel now have a 486sx die without the
FPU, which is much cheaper to produce because it is much smaller.
Intel get up my nose too, but this isn't really a scam.  I wouldn't
buy one, though.

Andrew.
From: hallam@zws010.enet.dec.com
Newsgroups: comp.arch
Subject: Re: question on computer systems using Alpha ...
Date: 12 Aug 92 12:14:27 GMT
Reply-To: hallam@zws010.enet.dec.com ()
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 ?

Leafing through the data sheet I've just pulled off gatekeeper.dec.com,
the chip itself can drop 36 watts, I think the problems cooling the chip
will be challenging enough without getting hung up about power suplies.
Adding a power rail is probably trivial comapred to the other changes
you are likely to need.

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

Phill
From: dhd@exnet.co.uk (Damon)
Newsgroups: comp.arch
Subject: Re: Why would you like a debugger (Was: What would you like in a debugger?
Date: 15 Aug 92 20:02:51 GMT
Organization: ExNet Systems Ltd Public Access News, London, UK

In article <1992Aug13.144226.8391@yrloc.ipsa.reuter.COM> rbe@yrloc.ipsa.reuter.COM (Robert Bernecky) writes:
>In article <id.8J9S.1P4@ferranti.com> peter@ferranti.com (Peter da Silva) writes:
>>In article <343@moene.indiv.nluug.nl> toon@moene.indiv.nluug.nl (Toon Moene) writes:
>>> OK, but I only explained why *I* wouldn't use a debugger. Note: here's my  
>>> silent assumption: Debuggers are slow: they've a steep learning curve,  
>>> load slowly, take their time to reach the breakpoint you think will tell  
>>> you what's going wrong (I often watch my colleagues using one - it's so  
>>> much fun :-)
>>
>>What, slower than recompiling the program with appropriate printfs?

Yes, if you have to re-compile with optimisation off.

>>I don't use debuggers often, and if I had a fast enough interactive compiler
>>I wouldn't use them at all, but they're a hell of a lot faster than "make"
>>when you get down to the last bit of troubleshooting.
>
>
>Ah, perhaps I'm missing something here, but I personally do NOT like
>the idea of modifying ANY code in order to debug it. That is, insertion
>of printfs is harmful to maintainability. 

No worse than switching from optimised to non-optimised compilation; I've even
had bugs where the non-optimised, debugging version hasn't worked when the
normal copy has.  I still think my code was OK...

>It's easy to get in a situation where you THINK you have changed something,
>or maybe you haven't, but you went and had coffee, then the phone rang...

I use SCCS extensively on programs consisting of hundreds of modules, and for
me this isn't *often* a problem.  B^>  Besides, I don't drink coffee.  B^>  B^>

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: dhd@exnet.co.uk (Damon)
Newsgroups: comp.arch
Subject: Re: question on computer systems using Alpha ...
Date: 13 Aug 92 14:18:23 GMT
Organization: ExNet Systems Ltd Public Access News, London, UK

In article <1992Aug12.172556.91192@cs.cmu.edu> lindsay+@cs.cmu.edu (Donald Lindsay) writes:
>
>hallam@zws010.enet.dec.com () writes:
>>the chip itself can drop 36 watts, I think the problems cooling the chip
>>will be challenging enough without getting hung up about power suplies.
>
>What problems?
>
>I've held an Alpha (+heatsink) in my hand, and I have no trouble
>believing DEC when they say they can put it in a (quiet) desktop
>unit. In fact, the original demo was just that.

Ah, but did it have power applied?  B^>

>The bottom line is, in a world that can cool Crays, a lightbulb's
>worth of power isn't the end of the world.

Yes, but not every user can pay Cray cooling costs...

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.
Newsgroups: comp.arch,comp.sys.dec,comp.unix.ultrix,comp.os.vms,comp.org.decus
From: stewart@crl.dec.com (Larry Stewart)
Subject: instruction scheduler for DEC Alpha
Organization: DEC Cambridge Research Lab
Date: Tue, 18 Aug 1992 17:10:45 GMT


instr-sched.c has been added to the DEC/Alpha archives on
gatekeeper.dec.com and crl.dec.com. (gatekeeper is on the West
Coast and crl in on the East coast.)  Look in ~ftp/pub/DEC/Alpha.

instr-sched.c is a basic block instruction scheduler for the
Digital Alpha  21064-AA microprocessor.

It's purpose is to rewrite a basic block of alpha instructions
in such a way as to minimize stalls and maximize the number
of multiple issue slots kept full.

This scheduler would be useful, for example, in a compiler
back-end or optimizer.

A main program is attached which illustrates the operation of
the scheduling subroutine.

Larry Stewart
Cambridge Research Laboratory
Digital Equipment Corporation
-- 
Digital Equipment Corporation
Cambridge Research Laboratory
Xref: sparky comp.arch:8909 comp.lang.c:12354 comp.programming:2329 comp.unix.programmer:4312