HDTenEightyP/NetNews huggingface dataset:
From: sog@craycos.com (Steve Gombosi)
Newsgroups: comp.arch
Subject: Re: PFLOP cooling reqs WAS Re: Cray Soap Opera
Keywords: Alpha, Gallium Arsenide
Date: 11 Apr 92 14:31:05 GMT
Organization: Cray Computer Corporation

In article <1992Apr8.213325.27578@nas.nasa.gov> rcarter@gaudi.nas.nasa.gov (Russell L. Carter) writes:
>In article <1992Apr8.143114.1926@craycos.com> sog@craycos.com (Steve Gombosi) writes:
>>In article <1992Apr8.042130.23242@athena.mit.edu> solman@athena.mit.edu (Jason W Solinsky) writes:
>>>In article <1992Apr06.174145.10353@skynet.uucp>, ice@skynet.uucp (Ice) writes:
>>>|> Cray 2 was the hottest
>>>|> thing back then; all of 1 billion MFLOPS at peak. 
>>>                             ^^^^^^^^^^^^^^
>>>That's pretty good. I wonder why the MITSF switched to an XMP if they had a
>>>machine doing 1000 TFLOPS? :-)
>>
>>It was a health hazard. With the clock rate needed to achieve that FP
>>performance, the damned thing was radiating UV like crazy ;-).
>>
>>Steve Gombosi
>>sog@craycos.com
>
>Just think of how many houses you could heat with it, though. ;-)

NAAAAAAAH...just open a tanning salon next door...

Steve Gombosi
sog@craycos.com
Xref: sparky comp.arch:4910 comp.lang.lisp:1355
From: gumby@Cygnus.COM (David V. Wallace)
Newsgroups: comp.arch,comp.lang.lisp
Subject: Ideas for new LISP Machines
Date: 7 Apr 92 21:07:02 GMT
Article-I.D.: Cygnus.GUMBY.92Apr7160702
	<TK.92Apr6120907@wheat-chex.ai.mit.edu>
	<ku3vg8INNcsp@estoril.cs.utexas.edu>
Organization: Cygnus Support, Palo Alto, California


   Date: 7 Apr 92 19:54:48 GMT
   From: wilson@cs.utexas.edu (Paul Wilson)
							 (I think most
   of the costs of floats are the compiler's problem, not the hardware's;
   with good inlining, dataflow analysis, etc., most floats can be raw
   untagged values on the stack or in registers.

This makes scavenging the stack painful if you're doing realtime gc in
another execution thread.
Newsgroups: comp.arch,comp.sys.m68k
From: aboulang@bbn.com (Albert Boulanger)
Newsgroups: comp.arch
Subject: Re: Ideas for new LISP Machines or "How to Lie with Statistics Using RISC"
Followup-To: comp.arch
Date: 16 Apr 92 13:19:11
Organization: BBN, Cambridge MA
	<GUMBY.92Apr14021204@Cygnus.COM> <45512@mentor.cc.purdue.edu>
Reply-To: aboulanger@bbn.com
NNTP-Posting-Host: pilsner.bbn.com
In-reply-to: hrubin@pop.stat.purdue.edu's message of 15 Apr 92 14:46:10 GMT

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

   The idea of making things easy for the compiler rather than efficient is a 
   clear indication that the language/compiler combination used is bad, not
   allowing a programmer to do intelligent things.  This then results in the
   present approaches to making sure that the programmer does not know of the
   machine capabilities, and then the machine designer leaves them out because
   "nobody" uses them, etc.

This has always troubled me about the RISC methodology -- it can get
into self-fulfilling-prophecy loops. Someone needs to write a book
titled like: "How to Lie with Statistics Using RISC".


Life is sometimes RISCy business -- let's play tag,
Albert Boulanger
aboulanger@bbn.com
Newsgroups: comp.arch
From: david@kessner.denver.co.us (David Kessner)
Subject: 8032/52 I/O Pins...
Organization: Kessner, Inc.
Date: Sat, 11 Apr 1992 06:54:02 GMT

Ok, here is a simple question...  I've been reading the data book on the
Intel 8032/8052/etc chips.  These chips have many I/O lines, some of which
can be multiplexed with the address/data lines to access more memory than 
the internal 'limit'.  In addition, the pins can operate as Input or Output
lines.  

After reading the Intel docs, I am totally confused.  Granted, I'm not the best
at electronics, but this shouldn't be that hard.

Question #1:  There is no 'status bit' which determins if a pin is input or
output.  How is this configured?

Question #2:  Near as I can tell, the closest thing to a High-Z state you
can get on the output is more like a High-Z with a small/weak pullup.  Is
this correct?

Thanks in advance...  Replies via e-mail are prefered.

-- 
David Kessner - david@kessner.denver.co.us              Reunite Pangea!
I'm lost in Aurora, Colorado!  (303) 745-6577
do { ... } while( jones);
Newsgroups: comp.arch
From: vu0208@bingvaxu.cc.binghamton.edu (!)
Subject: Re: Generic Top Secret Microprocessor Development Plan
Organization: State University of New York at Binghamton
Date: Thu, 9 Apr 1992 18:41:17 GMT

In article <1992Apr9.132601.11541@decuac.dec.com> mjr@hussar.dco.dec.com (Marcus J. "will do TCP/IP for food" Ranum) writes:
>dow@nova2.stanford.edu (Keith Dow) writes:
>
>>Please feel free to comment.
>
>1993 Position new architecture as "the machine that everyone will run in
>	every platform from mainframes to toasters"
>1994 Scratch heads over lack of toaster-based applications, and the fact
>	that the unit cost is still too high to compete, which makes it
>	hard to convince people to base toasters on a $1800 chip
>
>>1999 Add to the MCM a massively parallel neural network implemented
>>2005 in subthreshold logic to save power.
>
>2006 Company goes out of business, while Microsoft DOS10.0-running Intel
>	based machines continue to dominate the market

2006.5 Company bounces back with new architecture and financial funds
       from Japanese companies to compete with Microsoft & Intel
 


>
>
>mjr.
>-- 
>When they say "GNU's not UNIX" they mean they have abandoned the UNIX
>tenets of "simplicity, elegance, and ease of use."	- rcd
From: robin@lsl.co.uk (Robin Fairbairns)
Newsgroups: comp.arch
Subject: Re: Condition Codes and RISC arch.
Date: 6 Apr 92 09:37:46 GMT
Distribution: comp
Organization: Laser-Scan Ltd., Cambridge

In article <1992Apr4.213933.54194@cc.usu.edu>, ivie@cc.usu.edu (CP/M lives!) writes:
> In article <1992Apr4.173725.11509@vax5.cit.cornell.edu>, r4ty@vax5.cit.cornell.edu writes:
>> Here's a question that's been puzzling me for a while.  Why don't the latest 
>> RISC processors (or any microprocessors) have conditional codes inbedded in
>> every instruction?  
> 
> The Acorn RISC Machine does this.

Which is perfectly right: ARM architecture comes from Cambridge, where
_everyone_ (of a certain age - like me ;-) is influenced by the
Titan(Atlas) architecture. 

... Which was fundamentally RISC before all of today's hype, and which 
did indeed have this sort of operation.

However, the only (serious) compiler-writer I ever spoke to about the 
matter - Martin Richards, the author of BCPL - didn't much care for the 
Titan instruction set.  But then, compiler-writing has come along a bit
since the mid-70s, when I last spoke to him about it... 
-- 
Robin Fairbairns, Senior Consultant, postmaster and general dogsbody
Laser-Scan Ltd., Science Park, Milton Rd., Cambridge CB4 4FY, UK
Email: robin@lsl.co.uk  --or--  rf@cl.cam.ac.uk
Xref: sparky comp.arch:4929 comp.lang.lisp:1366
From: moss@cs.umass.edu (Eliot Moss)
Newsgroups: comp.arch,comp.lang.lisp
Subject: Re: Ideas for new LISP Machines
Date: 11 Apr 92 13:46:40 GMT
	<GUMBY.92Apr7160702@Cygnus.COM> <kuc3nlINN46s@boogie.cs.utexas.edu>
Reply-To: moss@cs.umass.edu
Followup-To: comp.arch
Organization: Dept of Comp and Info Sci, Univ of Mass (Amherst)
In-reply-to: wilson@cs.utexas.edu's message of 11 Apr 92 00:36:05 GMT

>>>>> On 11 Apr 92 00:36:05 GMT, wilson@cs.utexas.edu (Paul Wilson) said:
Paul> NNTP-Posting-Host: boogie.cs.utexas.edu

Paul> In article <GUMBY.92Apr7160702@Cygnus.COM> gumby@Cygnus.COM (David V.
Paul> Wallace) writes:
>							 (I think most
>   of the costs of floats are the compiler's problem, not the hardware's;
>   with good inlining, dataflow analysis, etc., most floats can be raw
>   untagged values on the stack or in registers.
>
>This makes scavenging the stack painful if you're doing realtime gc in
>another execution thread.

[ ... stuff deleted ... ]

Paul> The ``right'' way to do it is to have the compiler record what's where,
Paul> and in what format, at what point in the code.  (For compactness, that
Paul> might involve defaults so that you only record the (relatively few)
Paul> exceptions explicitly.)

See our paper in the SIGPLAN 1992 conference. We have implemented this, and
solved the problems of compiler optimizations that screw around with pointer
values in fairly general ways, and have it working (the stack decoding, that
is; the heap gc has not quite been plugged in yet, but is the easy part) in
our forthcoming Modula-3 compiler (gcc modified to compile M3 rather than C).
We have the table sizes compressed down to 16% of optimized code size on the
VAX (we might be able to do a little better, but this seems to be the general
ball park), and estimate the time overhead of stack decoding to be a small
percentage of total gc time. Quality gc for optimized, non-tagged languages is
on its way!
--

		J. Eliot B. Moss, Assistant Professor
		Department of Computer Science
		Lederle Graduate Research Center
		University of Massachusetts
		Amherst, MA  01003
		(413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu
Newsgroups: comp.arch,comp.lang.lisp
From: gumby@Cygnus.COM (David V. Wallace)
Subject: Ideas for new LISP Machines
	<GUMBY.92Apr7160702@Cygnus.COM> <kuc3nlINN46s@boogie.cs.utexas.edu>
	<GUMBY.92Apr14021204@Cygnus.COM> <WAYNE.92Apr14080035@backbone.uucp>
Organization: Cygnus Support, Palo Alto, California
Date: 16 Apr 92 12:18:14

   Date: 14 Apr 92 14:00:35 GMT
   From: wayne@backbone.uucp (Wayne Schlitt)

   In article <GUMBY.92Apr14021204@Cygnus.COM> gumby@Cygnus.COM (David V. Wallace) writes:
   >  o - on a register-poor architecture (such as the sparc) the cost of
   >      untagging may still be lower than the cost of all the reloads
   >      you'll have to do because you don't have enough free registers of
   >      the proper type. [ ... ]

   umm, pardon my ignorance, but in what way is the sparc a
   "register-poor" architecture?  I thought it had 32 registers, split
   between calling, current and called functions.  Isnt this enough?

You're excused.  If you look at the calling convention you have only 8
general-purpose local registers.  The others are eaten up by the
calling convention.  If you start partitioning them by type you
quickly run out.

If you change the calling convention you can use a lot more, of
course, but then you can't intercall with functions written in other
languages.
Newsgroups: comp.arch
From: preston@dawn.cs.rice.edu (Preston Briggs)
Subject: Re: multiplies by constants
Organization: Rice University, Houston
Date: Sun, 12 Apr 1992 16:51:28 GMT


>    For multiplies by constants, you could let the compiler detect the special
>    case and have some mechanism for letting the processor know this.  For
>    example, you could have a "constant multiply" instruction that takes
>    a pair of bit masks.

and glew@pdx007.intel.com (Andy Glew) writes:
>Many processor implementations have early outs for multiply and divide.
>Theoretically a compiler could schedule for these when it knows the
>constant value.

Absolutely.  Actually, this (multiply by constant) is one of the
things that can be done pretty well.  But we don't need special
instructions; just use shift, add, and subtract.  If the chain costs
more than the hardware multiply, then use the multiply instead.
And there's always the hope of reusing partial products, though this
may not occur much in real programs.

Of course, if an induction variable is being multiplied by a constant,
then it can be stength-reduced to a single addition.

Preston Briggs
From: abaum@armltd.uucp (Allen Baum)
Newsgroups: comp.arch
Subject: Re: Microcoded processors?
Date: 14 Apr 92 09:06:43 GMT
Organization: Advanced RISC Machines Ltd

borasky@ogicse.ogi.edu (M. Edward Borasky) writes:

>>In article <1992Apr10.214150.5525@cs.tu-berlin.de> tolk@opal.cs.tu-berlin.de (Robert Tolksdorf) writes:
>> > are there or have there been microcoded microprocessors on which the
>> > microprogram could be changed during runtime thus changing the
>> > semantics of assembly-code??
>This idea was implemented at least once in the 1960s.  I forget the
>name of the vendor but they built a microprogrammed machine that could 
>emulate the popular 36-bit machines of the day -- IBM 7040/7090, UNIVAC 
>1106/1108, etc.  I believe someone more recently built a chip-slice
>machine (AMD parts, I think) that emulated either a PDP-11 or Intel
>8086, depending on the microcode.

My notes are 6000 miles away, and my memory hazy, but this is what I remember:

The were several processors that could do this. One of the first that
I heard of was Standard Computer Corp., of southern Calif. Their machine
was a 36 bitter, with features to facilitate operating on different
word sizes and different parts of words. I think the intent was IBM 7090
emulation, though others were possible.

The Digital Scientific Meta series were very fast ECL, and designed primarily
for IBM 1130 emulation, I think.

The was a company in Buffalo, NY, Nanodata, that sold the QM1, which
had two levels of microprogramming, vertical and horizontal. It was
designed to emulate just about anything- the vertical microcode was
108 bits. The coined they term nanocode for the horizontal level.

As was mentioned in the newsgroup recently, the Burroughs 1700 series was
designed to change microcode on the fly, and had a different set for each
higher level language; the Xerox research machines (Alto, Dorado, etc)
did something similar, I believe.

Various, more mundane machines had writable control stores that could be
changed on the fly to accelerate different languages, but where generally
for 'thesis' applications more than real life (generally- some real life 
examples have been mentioned, and more will be after I post, I'm sure!).
Xref: sparky comp.arch:4994 alt.folklore.computers:6389
From: mmcg@molly.cs.monash.edu.au (Mike  Mc Gaughey)
Newsgroups: comp.arch,alt.folklore.computers
Subject: Re: chip-on-chip technology
Date: 14 Apr 92 05:44:38 GMT

liam@durie.amigans.gen.nz (Liam Greenwood) writes:

>In article <id.D1PO.B0K@ferranti.com> peter@ferranti.com (Peter da Silva) writes:
>>In article <1223@eouk15.abcl.co.uk> pcockere@abcl.co.uk (Pete Cockerell) writes:
>>> #define
>>
>>> is pronounced `pound-define' (not `hash-define')
>>
>>No, it's pronounced `number-define'. :->

>'hash-define' in these parts.

Depends what you're smoking...




--
Mike McGaughey			AARNET:	mmcg@cs.monash.edu.au

"Head stompin', ass kickin', finger lickin' nastiness."
From: johnl@iecc.cambridge.ma.us (John R. Levine)
Newsgroups: comp.arch
Subject: Re: Microcoded processors?
Date: 12 Apr 92 18:33:59 GMT
Article-I.D.: iecc.9204121433.AA11491
Organization: I.E.C.C.

In article <1992Apr10.214150.5525@cs.tu-berlin.de> you write:
>are there or have there been microcoded microprocessors on which the
>microprogram could be changed during runtime thus changing the
>semantics of assembly-code??

The Burroughs B1700 and B1800 series of micros had a heavily microcoded
design with a different interpreter for each language, swapped on the fly.
This made the job of the compiler easier, and allowed some great diagnostics,
but was horribly slow.  Many of the IBM 360 and 370 models have had loadable
microcode, although typically it was only changed at boot time.  In fact,
the first use of floppy disks was to load the microcode in the 370/145.

Back when ROMs were a lot faster than RAMs, it made sense to microcode,
since you could run several ROM instructions in the time it took for one
RAM access.  These days, there's no great difference in speed and it makes
more sense to compile directly to microcode, one of the ideas behind RISC.

Regards,
John Levine, johnl@iecc.cambridge.ma.us, {spdcc|ima|world}!iecc!johnl
Newsgroups: comp.arch
From: rcain@netcom.com (Robert Cain)
Subject: Re: Microcoded processors?
Date: Sat, 11 Apr 92 04:35:12 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 

The IBM System\370 Model 145/148 had a writeable control store.  This
proved real nice for loading up an APL interpreter kernel that boosted
performance almost 100 x.
-- 
Bob Cain    rcain@netcom.com   408-358-2007

"There are some strings.  They're just not attached."
                                                    Victoria Roberts
From: mjr@hussar.dco.dec.com (Marcus J. "will do TCP/IP for food" Ranum)
Newsgroups: comp.arch
Subject: Re: Generic Top Secret Microprocessor Development Plan
Date: 9 Apr 92 13:26:01 GMT
Organization: Digital Equipment Corporation, Washington ULTRIX Resource Center

dow@nova2.stanford.edu (Keith Dow) writes:

>Please feel free to comment.

1993 Position new architecture as "the machine that everyone will run in
	every platform from mainframes to toasters"
1994 Scratch heads over lack of toaster-based applications, and the fact
	that the unit cost is still too high to compete, which makes it
	hard to convince people to base toasters on a $1800 chip

>1999 Add to the MCM a massively parallel neural network implemented
>2005 in subthreshold logic to save power.

2006 Company goes out of business, while Microsoft DOS10.0-running Intel
	based machines continue to dominate the market


mjr.
-- 
When they say "GNU's not UNIX" they mean they have abandoned the UNIX
tenets of "simplicity, elegance, and ease of use."	- rcd
Newsgroups: comp.arch
From: glew@pdx007.intel.com (Andy Glew)
Subject: Re: 88K family computers?
Organization: Intel Corp., Hillsboro, Oregon
	<4drS=mu00awU06U357@andrew.cmu.edu> <1992Apr9.162035.24485@wolves.uucp>
Distribution: usa
Date: Fri, 10 Apr 1992 05:23:00 GMT

jpab+@andrew.cmu.edu (Josh N. Pritikin) writes:
>> Aydin Contols (Real-Time Workstation line)
>> CETIA (Cetia line)
>> Data General (Aviion line)
>> Dolphin Server Technology (Triton lin)
>> Encore Computer (Encore 91, Encore 93, Infinity 90)
>> Harris (Night Hawk line)
>> IPC Corp (IPC Serve 88000)
>> McDonnell Douglas (Series X line)
>> Modcomp (Real/Star Modcomp line)
>> Motorola (Delta Series 8000 line and MPC line)
>> OMRON (Luna-88k)
>> Sanyo Icon (SI line)
>> Unisys (S/8400)
>
>So which of these are actually making workstations or minicomputers?


Motorola MCD (Micro Computer Division) makes 88K based VME boards.

These can be used to create a variety of systems. Workstations,
upto servers that quite comfortably handled 20-40 workstations
on several ethernets.

When I was there, these ranged from a uniprocessor single board
computer, to a thick, three VME slot with mezzanine bus, 4 processor
system with significant cache on board. They may have 8 processors or
more now.

You can outfit these with the usual fairly wide variety of VME I/O
systems. The VME bus does become a bottleneck when maxxed out on
procesors, cache, and I/O (sometimes much before that).

I recall that MCD really only flogged a small subset of the possible
system configurations. 


What's this!?! An Intelloid saying nice things about Motorolan
products?  Ah, well, nostalgia - plus, Motorola's really not in the
running any more...

:-) (Asbestos suit on)


--

Andy Glew, glew@ichips.intel.com
Intel Corp., M/S JF1-19, 5200 NE Elam Young Pkwy, 
Hillsboro, Oregon 97124-6497

This is a private posting; it does not indicate opinions or positions
of Intel Corp.

Intel Inside (tm)
From: mash@mips.com (John Mashey)
Newsgroups: comp.arch
Subject: Re: Who will have the next killer micro?
Date: 7 Apr 1992 04:49:17 GMT
Organization: MIPS Computer Systems, Inc.
NNTP-Posting-Host: winchester.mips.com

In article <ABRAHAM.92Apr1042957@loke.iesd.auc.dk> abraham@iesd.auc.dk (Per Abrahamsen) writes:

>I thought Sun wanted the CPU manufacturers competing among themselves
>with many different designs and implementations.  Sun would then just
>pick the best.

It's not clear that this is exactly the way it works ... *most* (not all)
commercially significant SPARC implementations' architecture and
logic were done by Sun in partnership with some semiconductor vendor.

Maybe somebody can confirm or deny the following:
	I'd swear that I saw someplace in the last month or so a
	quote from someone at Sun saying that Sun had invested $150M so
	far in Viking.
However, I can't find this, which is not surprising [given the amount of
information and semi-information that flows thru my office :-)], so it's
possible I misread this.  So:

1) Has anyone else seen this, and if so, can you post the quote and
where it was printed? and who said it?

2) If this is indeed the correct quote, can anybody say *what* this
includes [2 chips? systems designs? software?].  I assume this doesn't
include semiconductor process development.  
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	 mash@mips.com OR {ames,decwrl,prls,pyramid}!mips!mash 
DDD:  	408-524-7015, 524-8253 or (main number) 408-720-1700
USPS:	MIPS Computer Systems M/S 5-03, 950 DeGuigne, Sunnyvale, CA 94086-3650
Newsgroups: comp.arch
From: preston@dawn.cs.rice.edu (Preston Briggs)
Subject: Re: Condition Codes and RISC arch.
Organization: Rice University, Houston
Date: Fri, 17 Apr 1992 03:07:20 GMT


I asked about usefullness of optionally nullified branches
in real code, with real compilers.

morris@aspen.IAG.HP.COM (Dale Morris) writes:

>Here is some data I've collected on the usefulness of
>predication/nullification in PA-RISC.

followed by a small paper I would have enjoyed at any ASPLOS.
Thanks for taking the time.

Preston Briggs
From: supnik@human.enet.dec.com (Bob Supnik)
Newsgroups: comp.arch
Subject: Microprogrammed processors (PDP-11 and VAX)
Summary: PDP-11's, VAX's with WCS
Keywords: microprogrammed, WCS
Date: 13 Apr 92 01:27:16 GMT
Organization: Digital Equipment Corporation


In the PDP-11 family, the PDP-11/60 had a writeable control store.  It was
used to implement, among other things, a PDP-8 emulator.  All other PDP-11's
had fixed control stores.

The LSI-11 had a writeable control store option, and a full set of
programming tools, for general use.  Subsequent chips used a non-writeable
mixed PLA/ROM structure for microprogram storage.

In the TTL/ECL VAX's, the 11/730, 8600, 8800, and 9000 implemented all
microprogram memory as writeable control store.  On the 8800, this
capability was used to produce one of the very first implementations
of the Alpha instruction set, embedded as an emulator within the VAX
instruction set.

The VAX 11/780, V-11 chip set (8200), and NVAX chip (6000-600 and others)
had or have patchable control stores.  The patch capability was
intended primarily to correct errors but has also been used to add
dynamic performance monitoring capabilities.  For example, with the V-11
patch capability it has been possible to get full address traces of
VAX systems, including system and users, across multiple processes.

Bob Supnik	>Supnik@human.enet.dec.com
		>All opinions expressed are those of a hardline microcoder
		>and do not reflect those of Digital Equipment Corporation
From: dow@idtg.UUCP (Keith Dow)
Newsgroups: comp.arch
Subject: Re: Generic Top Secret Microprocessor Development Plan
Date: 13 Apr 92 22:41:05 GMT
Organization: Integrated Device Technology, Santa Clara

>I'm not sure there is going to be much money in the intelligent toaster market.

The television show " Red Dwarf" had an intelligent toaster.  Of course the
main character on the show wanted to destroy it. (With good reason.)

I don't think we have to worry much about the price of semiconductors coming
down.   Low power 64-bit versions of Mips, Sparc, Alpha etc. should
be out sometime next year.  Packaging will be a problem as you stated. However
it probably will be overcome.  
Newsgroups: comp.arch,comp.os.misc