HDTenEightyP/NetNews huggingface dataset:
From: firth@sei.cmu.edu (Robert Firth)
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Organization: Software Engineering Institute
Distribution: na
Date: Fri, 4 Sep 1992 15:01:11 GMT

In article <Bu08uF.HBC@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:

>This is not brain-dead, but it is certainly brain-damaged.  Inlining of
>stuff from libraries has to be done at compile time, or at most at assemble
>time, as at least the compiler needs to know how much space the inlined
>code will take.  If every addition, etc., required a subroutine call,
>the computer would run very much slower.

I agree.  Our present views on how to make languages extensible is
very primitive.  As long as a "library" is presented to the compiler
as a list of signatures, we are trapped in the model that everything
is a function call and anything better is some heavy-duty optimisation.

Better, I think, is to present the compiler with a list of specifications.
Here's an example; the notation is invented but I hope self explanatory:

	op "+" (p : Ref Thing; i : Integer) : Ref Thing =
	(
	   (p#Integer{p'Size} + i*Thing'Size)#Ref Thing
	)

[Translation: choose an integer type at least as big as the size of p.
 Cast p to that type.  Add the product of i and the size of a thing.
 Cast the result back to a pointer to thing.  Note that "Thing" is
 a free variable bound at the point of use to the type pointed to by
 the real left operand.  All done at compile time.]

This is, close enough, the definition of "pointer+integer" in C.  It is
as general and portable as the equivalent C feature, and doesn't require
much optimisation to implement.  In the appropriate language, it could
be written by a user, as part of a library of pointer operations.  And,
since it is a specification written at the static semantic level of
the programming language, it can be read and understood by the compiler
with no difficulty.
Newsgroups: comp.arch
From: wong@rkna50.riken.go.jp (Wong Weng Fai)
Subject: ALPHA : Single Transistor Clocking
Organization: Institute of Physical & Chemical Research (RIKEN) Saitama,Japan
Date: Thu, 3 Sep 1992 00:47:32 GMT

Hi,

	I don't know if this has been brought up before or not but ...
According to what I know, right dead center of the ALPHA chip is a single,
huge transistor that is used for clock distribution. Can anyone provide
further details on this ? What are the advantages and disadvantages ? Is it
the way to go for distribution of high frequency clocks ?

	Thank You !

W.F. Wong.
From: richard@aiai.ed.ac.uk (Richard Tobin)
Newsgroups: comp.arch
Subject: Re: Indexing in microprocessors
Date: 4 Sep 92 16:40:53 GMT
Organization: AIAI, University of Edinburgh, Scotland

In article <JBS.92Sep3133125@sun1.Congruent.COM> jbs@Congruent.COM (Jeffrey Siegal) writes:
>Certainly, the PDP10 had this capability.  You could even place a
>small loop in the registers and jump to it!

Fast memory for the registers was an optional extra on the PDP10, so
it might not do you much good.

-- Richard
-- 
Richard Tobin,
AI Applications Institute,                                R.Tobin@ed.ac.uk
Edinburgh University.
From: jbs@Congruent.COM (Jeffrey Siegal)
Newsgroups: comp.arch
Subject: Re: Indexing in microprocessors
Date: 3 Sep 92 17:31:25 GMT
Organization: Congruent Corporation; New York, NY
In-reply-to: feustel@netcom.com's message of 2 Sep 92 00:43:30 GMT

In article <08jn8-q.feustel@netcom.com> feustel@netcom.com (David Feustel) writes:

   I think several pdp computers (including the pdp11) had this
   capability as the registers could be addresses as memory locations.

Certainly, the PDP10 had this capability.  You could even place a
small loop in the registers and jump to it!

Jeffrey Siegal
From: lucas@WATSON.IBM.COM ("Bruce Lucas")
Newsgroups: comp.arch
Subject: pdp-10
Date: 3 Sep 92 18:11:11 GMT

> Certainly, the PDP10 had this capability.  You could even place a
> small loop in the registers and jump to it!

Indeed, if you wanted, you could place a NOP instruction in register 0
with the indirect adress bit set specifying address 0, and voila, a
very fast non-terminating NOP instruction.

We now return you to your regularly scheduled debate about whether
physicists are better programmers or programmers better physicists.

Bruce Lucas
From: lindsay+@cs.cmu.edu (Donald Lindsay)
Newsgroups: comp.arch
Subject: Re: Interrupts vs Polling---WAS: cooling
Date: 27 Aug 92 01:31:34 GMT
Article-I.D.: cs.BtMC8n.B6H.2
Organization: School of Computer Science, Carnegie Mellon

In article <BtIDsH.8x3@exnet.co.uk> dhd@exnet.co.uk (Damon) writes:
>>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.
>Let's not use interrupts for this sort of thing.  Just how quickly is the
>temperature going to change.  A once per second poll should be more than
>enough. B^>/2.

Traditionally, power fail was reported via interrupt, since many
power supplies could only hold the system up for milliseconds. Big
systems (which have had computerized monitoring for decades)
typically were controlled from maintenance processors, which is why
you don't see maintenance features in the mainframe's architecture
spec. (Actually, at one time the biggest "feature" was a microfiche
reader for the schematics.)

It *is* sometimes important to get fast notice of cooling failure.
Some systems, stopped abruptly, get hot enough to damage themselves.
Their power-fail sequence tries to have residual power, not for the
CPU or disks, but for the fans/pumps.

>PS. If I replace /dev/heatsink with a plain file can I cool the system by
>    dumping the file across the net?  B^>

No, but pizzas that you FTP in will arrive hot.
-- 
Don		D.C.Lindsay 	Carnegie Mellon Computer Science
Xref: sparky comp.arch:9087 alt.folklore.computers:13286
From: aabdalla@pollux.usc.edu (Ahmed Abd-Allah)
Newsgroups: comp.arch,alt.folklore.computers
Subject: Research Topic/Instruction Set Design
Date: 28 Aug 1992 15:08:54 -0700
Organization: University of Southern California, Los Angeles, CA
NNTP-Posting-Host: pollux.usc.edu

I am a beginning Ph.D. student in search of a research topic in computer
architecture (CA).  What are some largely unexplored areas in CA that
have lots of possibilities?  I was thinking of looking into the design
of instruction sets: what combination of instructions is the "optimum"
set for a particular application - and how does the choice of application
affect the final result?

If anyone has some starting references, I'd appreciate the help as I
search through the university library...

Also, I haven't really decided on instruction set design, so any ideas
as I said above, would be really appreciated.

Email or post, and many thanks!

Ahmed A. Abd-Allah

PS  Does it get any easier after the topic is finally found???? :-)

Newsgroups: comp.arch
From: bob@tera.com (Bob Alverson)
Subject: Re: trapping speculative ops
Reply-To: bob@tera.com
Organization: Tera Computer Company, Seattle, WA
Date: Thu, 27 Aug 1992 01:58:42 GMT

In article 92Aug26084159@medea.rice.edu, cliffc@rice.edu (Cliff Click) writes:
> Let every register have some extra "trap" bits.
> A read of the register with it's trap bits set, causes the exception.
> A write to the register sets the trap bits according to the success of
> the operation.
> 
Let's see.  You'll also probably want special loads and stores that preserve
those trap bits.  That way the register allocator and context switch code can
safely save and restore potentially poisoned registers.  You might also want
a register to register move that propagates poison, so the register allocator
can shuffle values around with wild abandon.

Speaking of context switch, make sure you can restore the poison on *all* the
registers or have some that you know aren't poisoned (like the one holding the
stack pointer).

Oh, and those folks with conditional moves or conditional operations may want to
have the poison only conditional "tasted," to keep jackpot cases from obfuscating
compiler transformation decisions.

Bob
From: johnl@iecc.cambridge.ma.us (John R. Levine)
Newsgroups: comp.arch
Subject: Re: OS/MFT and Macintosh (was: ..History)
Date: 3 Sep 92 14:44:36 GMT
Organization: I.E.C.C.

>smith> OS/MFT provided a "flat" file system.
>
>Really? That's news.

It's true, mostly.  Recall that each disk had a VTOC which kept the actual
name, position, and type of a file (excuse me, data set) and there was a
global catalog which optionally recorded what on disk or tape a file resided.

The VTOC on each disk was entirely flat.  You could use any 44 characters
in the name that you wanted.  It was set up so the name was the key in each
VTOC record so the OS could use the channel's "search for equal key" to run
down the VTOC and find an entry.

The catalog, on the other hand, was indeed tree structured so if you wanted
to catalog a file, its name had to consist of dot-separated components each
of no more than 8 characters, and no name could be a component-wise prefix
of another.  But it appears that in most installations, people were very
sloppy about using the catalog ("but if I catalog this file, I have to check
with every other programmer to make sure he's not using the same name on
another disk pack!") and there were a lot of strange flat names.

Regards,
John Levine, johnl@iecc.cambridge.ma.us, {spdcc|ima|world}!iecc!johnl

PS:  Followups to comp.arch.history, if it ever exists.
From: schow@bqneh23.bnr.ca (Stanley T.H. Chow)
Subject: Re: trapping speculative ops (LONG)
Organization: Bell Northern Research Ltd, Ottawa
Date: Wed, 2 Sep 1992 14:55:33 GMT

In article <1992Sep1.152044.12253@tera.com> bob@tera.com writes:
>To quote William Kahan:
>
>	Exceptions are not errors.
>	Unless they are handled badly.
>
>In other words, if you think you can roll over and die when you take an exception,
>you are severely restricting hardware and software.  In many cases, some fix up
>is desired followed by a return from the exception.  Continuing in this way can
>be quite challenging if you have gone too far forward.  Values that were around
>may no longer be anywhere to be found.  However, an architectural way to guarantee
>that no traps from an operation will occur in the future is nice.  DEC's Alpha
>has the sledge-hammer-like trap barrier.  Being able to selectively touch off
>traps gives the compiler more control and may allow better pipeline usage.

Isn't that the whole point of the trap-bit scheme?

The compiler chooses when to trap, and the timing can be different for each
potential trap! Instead of a sledge hammer, the compiler get to use the data-
flow and register allocation information. As I see it, DEC Alpha forces a barrier
per basic block since the trap handler doesn't know which instruction caused the
trap and the multiple incoming path could all generate the same type of trap.
In the trap-bit scheme, the compiler chooses which traps to handle and when to
handle them. So if an operation written to R15 traps, the flow of control could
meander through any number of basic blocks before the trap detection (as long as
the compiler knows that R15 is not touched).

In what way is fix up prevented?


--
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.
Newsgroups: comp.arch,comp.sys.ibm.pc.hardware
From: keith@ksmith.uucp (Keith Smith)
Subject: Re: Does a 487sx shut down the 486sx??
Organization: Keith's Computer, Hope Mills, NC
Date: Tue, 25 Aug 92 15:00:26 GMT

In article <1370@eouk9.eoe.co.uk> ahaley@eoe.co.uk (Andrew Haley) writes:
>kak1@cray.com (Kevin Kramer) writes:
>: In article <1992Aug19.155448.18248@ilinx.wimsey.bc.ca> brian@ilinx.wimsey.bc.ca (Brian J. Murrell") writes:
[ ... ]
>: >
>: >That's what I heard.  IMHO the 486sx is a *big scam*.
>: >
[ 486sx + 487 shuts off sx ... ]
>: 
[ 486sx a faulty dx ... ]
>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.

Ah, acurate.  SCAM, no, not really, you are buying the technology, not
the plastic & silicon.  It CAN make good sense.  Instead of paying $300
for a full blown 486DX now, buy the $90 SX part, then plug in the 487
when the prices for the 487 come down to a more reasonable level, say
$50 or so in a couple of years.  If you don't really need the
Coprocessor horepower now, why not reap the benifits of on-chip cache
and improved instruction execution time vs a similarly priced 386?

Heck,  I'm still running a 386.  I can't seem to justify the purchase of
a 486xX when I'd never use it.
-- 
Keith Smith          uunet!ksmith!keith            5719 Archer Rd.
Digital Designs      BBS 1-919-423-4216            Hope Mills, NC 28348-2201
Somewhere in the Styx of North Carolina ...
From: prener@watson.ibm.com (Dan Prener)
Subject: Re: Configurable/Switchable Endianess
Date: Fri, 28 Aug 1992 00:40:52 GMT
Distribution: comp
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
Organization: IBM T.J. Watson Research Center, Hawthorne, New York

In article <5752@armltd.uucp> djaggar@armltd.uucp (Dave Jaggar) writes:

>I am interested in microprocessors that are able to execute code, or
>process data in either endianness, and how they achieve this.  For
>instance the ARM6 family of CPUs have a pin or a bit in a system
>register (depending on the model), which sets the endianness of the
>processor, by determining which byte is selected off the data bus for
>byte load/store operations.  The MIPS R3000 has a pin that you set at
>reset, but what does this do internally (affect byte ops or word ops) ?
>Is it the same on R6000, R4000xx ? The ATT Hobbit has switchable data
>endianness (how do you switch ?), does this mean that the endianess of
>code is fixed ? Does anyone implement a "load data of the other
>endianness instruction" ?

The IBM RS/6000 is a big-endian machine which has little-endian load/store
ops.
--
                                   Dan Prener (prener@watson.ibm.com)
Newsgroups: comp.arch
From: brent@uwovax.uwo.ca (Brent Sterner)
Subject: alpha and vector processing...
Organization: University of Western Ont, London
Date: Fri, 4 Sep 1992 16:05:03 GMT

   Not sure why this crossed my mind, but I'm curious about how well
the alpha architecture might support vector processing.  I'm familiar
with the vector processing concepts as implemented for VAX 6000 and
9000 systems, as well as the implementation on the Cyber 2000.  Can
anyone comment on alpha futures in this direction?  Thanks,  b.
--
Brent Sterner                       Manager, Academic Technical Support
Fast:       <BRENT@uwo.ca>          <129.100.2.13>
Telephone:  (519)661-2151 x 6036    Fax:   (519)661-3486
Slow:  Computing & Communications Services, Natural Sciences Building
       The University of Western Ontario, London, Ontario, Canada  N6A 5B7
Newsgroups: comp.arch,comp.sys.ibm.pc.hardware
From: larsen@unislc.uucp (Steve Larsen)
Subject: Re: Does a 487sx shut down the 486sx??
X-Newsreader: Tin 1.1 PL5
Organization: Unisys Corporation SLC
Date: Wed, 26 Aug 1992 17:31:54 GMT

Kevin Kramer (kak1@cray.com) wrote:
: 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

Because right now, they are 1/3 the price of DX chips, and if you look
around, you can find motherboards with the extra pin socket so that upgrading
to the DX down the road is as simple as changing the CPU (and possibly the
oscillator, depending on whether or not you change MHz, and whether your
motherboard supports multiple oscillator frequencies).

Xref: sparky comp.arch:9146 sci.math:10828 comp.lang.misc:2875 comp.lang.fortran:3359 comp.edu:1469
From: preston@helena.cs.rice.edu (Preston Briggs)
Subject: Re: Multi threaded CPUs
Organization: Rice University, Houston
Date: Wed, 2 Sep 1992 02:39:22 GMT

stripes@pix.com (Josh Osborne) writes:

>A little while ago I read about a RISC CPU (SPARC I think) that some
>researchers had designed.  It had a cache of threads (I got the impresion
>that that includes registers, and posabble MMU state as well), four in
>the current chip, and when there was a pipe stall the execution would just
>switch to another thread.

Anant Agarwal, at MIT, was working on a modification of the SPARC,
called Sparcle, to be used as a node in a large-scale multiprocessor
called Alewife.  He gave a talk on the project last year at a workshop
during Supercomputing '91.  Unfortunately, I have only a brief
abstract here.

My memory from the talk was that they used each set of registers in
the SPARC's register windows to support a different thread.  Can
switch threads in 11 cycles.  Probably use the multithreaded behaviour
to hide communication latency.

There have been other multithreaded machines in the past, and new ones
are still being built.  In some cases, they switch to enable a greater
degree of pipelining (ala the Denelcor HEP).  Modern machines seem to
use multithreading to hide the latency of memory access (ala the Tera
machine) or communication.

Authors to look for include Agarwal, Arvind, and Burton Smith.

Preston Briggs
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Newsgroups: comp.arch
Subject: Re: trapping speculative ops
Date: 26 Aug 92 12:56:20 GMT
Organization: Purdue University Statistics Department

I seem to have missed the original article by Mr. Lindsay.  But this has
been a major problem since the possibility of any parallelism has occurred.


>    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

The real problem is that if (1) is done, then the hardware may have to
handle a large number of branches, and spend most of its resources on
managing the large variety of cases.  I believe that the attempts to 
do so have not been too successful. 

But it often is necessary to put in blocks even when this is not the case;
I recall the following example:

	x = a/b;
	if(y<0) x=z;

where the division takes long enough that the result of the first statement
is produced after the result of the second.  Whatever the hardware protocol
or the rearrangement of instructions, considerable inefficiency can occur.
This means that alternative (2) causes slow execution.  With the way division
is these days relative to other operations, doing the division first
essentially puts it in the background, so it does not take up much time.
But delaying the issuance of branches does not help, either.

I see no simple solution.  In many cases, compiler-programmer interaction may
help, but often not even this.  If the code is necessarily branching, in many
cases a VCISC approach may achieve much, as some types of branches are very
fast in hardware.

One place where this is extremely important is SIMD, where a fairly simple
instruction, with the simple branches taken in hardware, gets to be a major
problem in turning processors on and off.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@pop.stat.purdue.edu (Internet, bitnet)  
{purdue,pur-ee}!pop.stat!hrubin(UUCP)
From: rtrauben@jayuya.Eng.Sun.COM (Richard Trauben)
Newsgroups: comp.arch
Subject: Re: Error Correcting Memory
Date: 4 Sep 1992 13:43:06 GMT
Organization: Sun Microsystems, Mt. View, Ca.
NNTP-Posting-Host: jayuya

>In article <Sep03.210730.68303@yuma.ACNS.ColoState.EDU> shafer@CS.ColoState.EDU (spencer shafer) writes:
>>I'm interested in learning about the difference in reliabili

Its been a while. I think the difference in apparent FIT rate to the
application programmer circa '86 was 2-5 orders of base 10 magnitude
smaller for ecc w/ scrubbing.

Regards,
-Richard Trauben
--
From: lus@ucs.orst.edu (Shih-Lien Lu)
Newsgroups: comp.arch
Subject: Question: book on computer system performance evaluation
Keywords: MIPS, MFLOPS, queuing models, analytical models
Date: 31 Aug 92 21:57:36 GMT
Organization: University Computing Services - OSU

Is there any good book which covers the performance measurement/modeling
of computer systems? Thanks.

Shih-Lien
Newsgroups: comp.arch
From: hamilton@robin.rtp.dg.com (Eric Hamilton)
Subject: RS/6000 instruction set
Date: Mon, 31 Aug 92 13:54:27 GMT
Organization: Data General Corporation, Research Triangle Park, NC

What documentation on the architecture and instruction set of the RS/6000 is
available?  An IBM order number would be nice if you have it.
Replies by email, of course.  Thanks.

-- 
----------------------------------------------------------------------
Eric Hamilton				+1 919 248 6172
Data General Corporation		hamilton@dg-rtp.rtp.dg.com
62 Alexander Drive			...!mcnc!rti!xyzzy!hamilton
Research Triangle Park, NC  27709, USA