HDTenEightyP/NetNews huggingface dataset:
From: lindsay+@cs.cmu.edu (Donald Lindsay)
Subject: Re: Ideas for new LISP Machines
Date: Thu, 16 Apr 92 17:33:09 GMT
Organization: School of Computer Science, Carnegie Mellon


In article <45512@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
>>   The easy way to do this is to partition the register set into pointer
>>   registers and nonpointer registers, as is done in Yale's T compiler.
>Most architectures are register-poor.  Partitioning the registers
>into pointer registers and non-pointer registers, or having separate
>floating-point registers, makes for problems of all kinds.  

Partitioning int/FP makes sense when the widths are, say, 64 and 80.
It mostly makes sense anyway, since using int instructions on FP
values leads to programs which e.g. incorrectly think that two NANs
are equal.

The 68K's int/pointer partition made it harder to write an optimizing
compiler.
-- 
Don		D.C.Lindsay 	Carnegie Mellon Computer Science
Newsgroups: comp.arch
From: wayne@backbone.uucp (Wayne Schlitt)
Subject: Re: Who will have the next killer micro?
Organization: The Backbone Cabal
Date: Mon, 13 Apr 1992 14:34:03 GMT

In article <32580102@hpcuhe.cup.hp.com> linley@hpcuhe.cup.hp.com (Linley Gwennap) writes:
> Today's HP 730 workstation achieves 66 MFLOPS peak, and systems using the
> PA7100 chip will ship this year providing 200 MFLOPS peak.  

hmm...  I thought that the PA7100 would run at 100MHz and execute one
integer and one floating point instruction every cycle.  That would
mean that the peak FLOPS would be "only" 100 MFLOPS.  I would think
you could come much closer to this peak on the PA7100 than on the 730
though... 


-wayne

Newsgroups: comp.arch
From: mmm@icon.com (Mark Muhlestein)
Subject: Re: 88K family computers?
Organization: Icon International, Inc., Orem, Utah
Date: Sat, 11 Apr 1992 20:50:05 GMT


Well!  We go off the internet for a couple of days, and naturally, after
years of obscurity there is a mention of Sanyo Icon in comp.arch!

Yes, there is still a company here, and yes, we have hundreds of happy
customers of our 88K-based products.

Gregory Woodbury writes:
>I could NOT get a response from Sanyo/Icon about their products.

I don't know how you attempted to get a response, but if it was via
the internet, as I mentioned, we were off for a few days.

In any case, we have two main product thrusts:  intelligent disk subsystems
and Pick with Unix.  Both of these products use the 88K as the primary
processor.

Originally, we were targeting our product at the general Unix marketplace,
but we later focussed on providing Pick and Unix interoperability.  Our
Unix is 88-open compliant, but we have primarily been working on making
a fast, feature-rich Pick implementation.  (Pick, for those who don't
know, is a database/application development environment that in the
past has run as the resident OS on the host platform.)

Stacy Son writes:
>Sanyo/Icon makes (or did make) mini multiuser servers that runs UNIX.
>We have some of their outdated 68020 based models stored in our
>computer junk room.  They where going to give us one the 88K based
>models but they run into money problems.  I believe they are still
>around but most of their good engineers have left the company.

The equipment mentioned is over five years old; I don't know where
you heard the story about a plan to donate an 88K-based machine to BYU,
but I have never heard anything about it.  With Sanyo as our backer,
we have weathered our market's financial ups and downs, and I feel good
about our current position.

As to our engineers, all of them were and are good!  I consider it a
privilege to have worked with some truly exceptional people.  Most
of the folks that have left did so as a consequence of the de-emphasis of
Unix and the emphasis on Pick, but we are still fully capable of supporting
our current development, which is very challenging and interesting work.

Our current primary development focus is on our intelligent disk subsystems.
In the next few months we will be announcing some further 88K-based products
that we hope to make a bit of a splash with.  Stacy, why don't you come
up the road and I'll show you around the place so that next time
anyone asks you will have the straight stuff to pass on!
-- 

   Mark Muhlestein @ Sanyo Icon

mmm@icon.com
From: doconnor@pima.inews.intel.com (Dennis O'Connor)
Newsgroups: comp.arch
Subject: Re: Generic Top Secret Microprocessor Development Plan
Date: 13 Apr 92 05:33:46 GMT
	<1992Apr9.132601.11541@decuac.dec.com> <411@idtg.UUCP>
Organization: /eng/eng25/doconnor/.organization
In-reply-to: dow@idtg.UUCP's message of 9 Apr 92 19:27:51 GMT


dow@idtg.UUCP (Keith Dow) writes:
] >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
]
] The 64-bit microprocessors can be down-sized easily.  Typically two
] years after a microprocessor has been introduced, the package costs
] more than the die. 

Especially if the package has 800 pins, with a diamond substrate and 
freon channels to duct away the 200 watts of power the chip dissipates ! :-)

Seriously: Yes, large-pin-count high-speed hi-power packages cost big bucks.

But getting into the "toaster" market requires you to package into a small,
cheap, plastic package with maybe 84 pins and maybe the abilty to dissipate
2 watt. I don't think anyone's new top-end workstation/mini/PC processor die
will cost less than THAT package two years after introduction.

Most of them wouldn't fit into it's cavity anyway. And most need more pins.
And most draw to much power per delivered "equivalent VAX MIPS".

And there is less glamour and fame there, anyway ;-)

--
Dennis O'Connor			doconnor@sedona.intel.com
Xref: sparky comp.arch:4789 comp.lang.lisp:1323
From: kend@data.rain.com (Ken Dickey)
Newsgroups: comp.arch,comp.lang.lisp
Subject: Re^2: Ideas for new LISP Machines
Date: 7 Apr 92 16:44:53 GMT
Organization: Microtek DSD, Hillsboro, OR

meissner@osf.org (Michael Meissner) writes:

>For integer constants, and stack frame addresses, I agree that signed
>offsets is generally more desirable than unsigned offsets.  However,
>for things like loading up a global/static variable, it is less
>desirable.

On the other hand, a common OO approach is to point to the `center' of
a data object, using negative offsets to access `instance' variables
and positive offsets to access local `method' procedures (or their
jump table slots).

[I know.  Harvard believes that code and data are not the same.]

-Ken Dickey				kend@data.rain.com
Newsgroups: comp.arch,alt.folklore.computers
From: peterk@public.sub.org (Peter Kittel)
Subject: Re: chip-on-chip technology
Organization: Public News & Mailserver, Commodore Germany PM UNIX, Frankfurt
Date: Wed, 15 Apr 92 06:14:05 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.

And as we here don't know this funny character at all, we say
"Doppelkreuz-define", that would be "double cross" in English.

-- 
Best regards, Dr. Peter Kittel  // E-Mail to  \\  Only my personal opinions... 
Commodore Frankfurt, Germany  \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
                                   or  peterk@public.sub.org
From: ivie@cc.usu.edu (CP/M lives!)
Newsgroups: comp.arch
Subject: Re: Chip timing issues
Date: 9 Apr 92 20:08:22 GMT
Article-I.D.: cc.1992Apr9.140822.54343
Organization: Utah State University

In article <s1uqsINNqht@cs.widener.edu>, YOUNG@tattoo.cs.widener.edu (Rob Young) writes:
> With that intro... I have been pondering a statement one of the
> Alpha architects (Dick Sites) made:
> 	" We did a number of design/philosophy things up front.
> 	There are almost no magic numbers in the architecture-
> 	you know, 20 microseconds or something - because every
> 	time we've seen an architecture with magic numbers 
> 	written into it, 10 years later those numbers look absurd."
> 			Digital News 1/6/92
> Speculating... does any current architecture come to mind that Dick
> may be referring to?  

I just naturally assumed he was talking about PDP-11s with their 
10 microsecond UNIBUS timeout. Admittedly not an _architectural_ magic
number (you can have PDP-11s without having UNIBUS), but a common magic
number in PDP-11 implementations.

Roger Ivie
ivie@cc.usu.edu
From: mfriedel@monolith.rmnug.org
Newsgroups: comp.arch
Subject: 88110
Date: 14 Apr 92 23:23:40 GMT
Reply-To: mfriedel@monolith.rmnug.org
Organization: Colorado School of Mines

Where can I find some extensive information on the motorola 88110 ? Ultimately  
I would like to see the spec sheets.

Mike
-- 
Bob Ware, System Administrator 
Computing and Networking, Colorado School of Mines, Golden, Co 80401, USA
(303) 273-3987
bware@mines.colorado.edu bware@mines.bitnet
Xref: sparky comp.arch:5054 comp.ai:2009
From: tj@alliant.com (Tom Jaskiewicz)
Newsgroups: comp.arch,comp.ai
Subject: Re: Voice Recog. on Desktop
Date: 15 Apr 92 17:25:28 GMT
Article-I.D.: alliant.1992Apr15.172528.30412
Organization: Alliant Computer Systems Corp.

In article <GLEW.92Apr14153132@pdx007.intel.com>, glew@pdx007.intel.com (Andy Glew) writes:
|> Give me voice for entering mass quantities of text.

In article <sfu1jINNjc6@agate.berkeley.edu> jbuck@forney.berkeley.edu (Joe Buck) writes:
>  I don't think that voice is a reasonable
>way to enter mass quantities of text except maybe to use a telephone when
>you're away from your machine.  Speech is a low-bandwidth way of communicating
>lots of text.

Yabut . . .

I don't need (or want) voice recognition on my desktop.  But I want voice
recognition:

I have an hour of "dead" time every working day.  It's called commuting.
I want a computer I can use while driving a car.  I don't see any alternative
to a totally audio interface.

The first company with the hardware/software to allow a driver to "write"
memoes is going to make a lot of money.
-- 
##########################################################################
# The doctrine of nonresistance against arbitrary power, and oppression is
# absurd, slavish, and destructive of the good and happiness of mankind.
#   -- Article 10, Part First, Constitution of New Hampshire
Newsgroups: comp.arch
From: payne@theory.TC.Cornell.EDU (Andrew Payne)
Subject: Re: Voice Recog. on Desktop
Organization: Cornell Theory Center
Date: Wed, 15 Apr 1992 01:12:01 GMT

In article <sfu1jINNjc6@agate.berkeley.edu> jbuck@forney.berkeley.edu (Joe Buck) writes:
>Really?  I type almost as fast as I talk and I don't have to worry about
>the ums, ers, and changes of mind.  I don't think that voice is a reasonable
>way to enter mass quantities of text except maybe to use a telephone when
>you're away from your machine.  Speech is a low-bandwidth way of communicating
>lots of text.

Huh?  You must talk very slowly or type very quickly.  I type and talk
quickly, but I still talk much faster than I type.  Try talking along as you
type--you'll see how slow it really is.

I'll be really happy when I'll be able to dictate to my computer.  I wonder
if it will become practical in my lifetime...

-- 
=  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =
Andrew C. Payne, N8KEI        UUCP:  ...!cornell!batcomputer!payne
                          INTERNET:  payne@tc.cornell.edu

Newsgroups: comp.arch
From: renglish@cello.hpl.hp.com (Bob English)
Subject: Re: Condition Codes and RISC arch.
Date: Tue, 14 Apr 1992 18:03:42 GMT
Organization: Hewlett Packard Labs

preston@dawn.cs.rice.edu (Preston Briggs) writes:
> Can the compiler find either of these [optimal] solutions from the source
> code?

Someone else has already posted the answer to this question, but there
is a variation of that question that is also interesting:

int func(int a,int b,int c,int d)
{
  if(a==b)
     return c - 1;
  else
     return d + 10;
}

yields the code:

func:           combf,=,n       arg0,arg1,func+0xC
func+4:         bv      r0(rp)
func+8:         ldo     -1(arg2),ret0		; in the return delay slot
func+0xC:       bv      r0(rp)
func+10:        ldo     0xA(arg3),ret0		; in the return delay slot

Note that in this case, the three statement nullification solution would
be the wrong thing to do, since the subroutine return requires an
additional two cycles.  By using the conditional branch, the compiler
saves two instructions for the a==b case.

--bob--
From: firth@sei.cmu.edu (Robert Firth)
Newsgroups: comp.arch
Subject: Re: Ideas for new LISP Machines
Date: 15 Apr 92 14:37:54 GMT
Organization: Software Engineering Institute

In article <kumaeoINNpkv@estoril.cs.utexas.edu> wilson@cs.utexas.edu (Paul Wilson) writes:

>I'm not sure if the SPARC qualifies as a register-poor architecture
>in this respect.  It does in another respect, though.  It's got
>tons o' registers, but very few GLOBAL registers you can play with
>in an application-specific way.  In particular, I'd like special
>global registers for values I need to reference often in my
>system...

Paul, I had the same requirment, but found the Sparc to be a pleasant,
clean, register rich architecture.  It gives you seven volatile registers,
called for some strange reason g1 to g7, and twenty-two nonvolatile
registers, that you can use as environment pointers, global base
pointers, and all kinds of other good things.  You have enough left
over to pass integer arguments in registers, and enough FP registers
to pass floating arguments in FP registers.

In case you haven't guessed it, the trick is very simple: get rid of
those stupid register windows.  You also have the satisfaction of
knowing that 40% of your memory traffic isn't being wasted in saving
and restoring empty registers.
Newsgroups: comp.arch
From: hblim@iti.gov.sg (Hock-Beng Lim)
Subject: Query on i860 processor boards.
Organization: Information Technology Institute, National Computer Board, Singapore.
Date: Thu, 9 Apr 1992 11:20:43 GMT


I would like to find out the vendors which offer i860 processor boards for
the Sun SPARCstation (or other workstations). For those of you who have used
it before, can you please comment on your experiences with using the board.
I am interested to know the performance which can be obtained on either
benchmarks or real applications. I would also like to know what are the
optimizing compilers and numerical libraries which you have used for the i860
board.

Thanks in advance !

HB
-- 
-----------------------------------------------------------------------------
Hock-Beng Lim					| hblim@csrd.uiuc.edu
Center for Supercomputing R&D, UIUC. (on leave)	| hblim@iti.gov.sg 
Information Technology Institute, Singapore.	| tel : (65)772-7205,772-7273
Newsgroups: comp.arch
From: bgoffe@seas.smu.edu (Bill Goffe x3806)
Subject: Article on Future Computer Performance?
Organization: School of Engineering and Applied Science
Date: Fri, 10 Apr 1992 01:14:03 GMT


I'm finishing up a paper and I'd really like to include a reference
to predictions of future computing power on the desktop. I've been
been using Gordon Bell's article in the Communications of the ACM,
September, 1989, but it is becoming dated. To be precise, the last 
date he made a prediction for is 1992 (on the Linpack 100x100, double
precision, he predicted 20mflops standard, 200mflops w/ vector unit).

Can anybody point me to something later that covers the mid to late
1990s?

Bill Goffe
bgoffe@zebra.seas.smu.edu
From: walters@id.com (Chris Walters)
Newsgroups: comp.arch
Subject: Re: 88K family computers?
Date: 8 Apr 92 20:06:18 GMT
Reply-To: walters@id.com
Organization: Intrinsic Development Corporation

> |> In article <1992Apr1.173908.10271@digi.lonestar.org>  
jgay@digi.lonestar.org  
> |> (john gay) writes:
> |> > Could someone tell me what computers out now (or even rumored) use
> |> > the Moto 88K family.
> |> 
> |> I believe Data General (Aviion?) has some machines out.
> |> 
> |> There is a romour of a NeXT Risc Workstation coming out at the end of  
this year  
> |> with dual-88110s.
> 
Omron has a dual 88k box.  I saw it a couple of years ago at Xhibition in  
San Jose.

Sorry, that's about all I know.
-- 
Chris Walters			10600 Arrowhead Dr., Suite 350
RDR, Inc.			Oakton, VA 22030
walters@rdr.com			(703)591-8713,(703)273-8170 FAX
 ------------------------- Hack Naked --------------------------
Newsgroups: comp.arch
From: sysmgr@king.eng.umd.edu (Doug Mohney)
Subject: Re: Cyrix 486
Date: Mon, 06 Apr 92 18:25:55 GMT
Organization: Computer Aided Design Lab, U. of Maryland College Park
Reply-To: sysmgr@king.eng.umd.edu

In article <mch.702540303@regent.e-technik.tu-muenchen.de>, mch@regent.e-technik.tu-muenchen.dbp.de (Michael Hermann) writes:

>>I take it to mean that you can plug it right into an existing 386sx motherboard?
>>If so, how much faster will it be than the old 386sx was?
>
>Has ANYONE a 386sx-board with a socket for the processor??
>To my understanding the main idea of the 386sx is to bring 
>386-functionality at the 286 price because at that time noone
>besides intel made 386xyz-devices. A socket for a qfp-package
>is by no means cheap. 
[....]
>I bet, you'll forget about this replacement rather quickly.

Ok, in quantity, you're talking $119 for the part. Say under $200 for a
swappable motherboard. Or, if you've gotten into the CPU-daughterboard game, as
most of the CCW (Commercial Clone World: AST, ALR, Compaq (?)) has, you
come out with another board to swap. 

It makes for some interesting third-party playing, no doubt...altho' a 
castrated big horse and a castrated little horse still gives you a castrated
horse.

  For a country which has exported more comedians to the States than any
  other place on earth, the Canadians have very humorless grad students.
  -- >                  SYSMGR@CADLAB.ENG.UMD.EDU                        < --
Xref: sparky comp.arch:5101 comp.lang.lisp:1416
From: preston@dawn.cs.rice.edu (Preston Briggs)
Newsgroups: comp.arch,comp.lang.lisp
Subject: Re: Ideas for new LISP Machines
Date: 16 Apr 1992 22:23:55 GMT
Organization: Rice University, Houston


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


gumby@Cygnus.COM (David V. Wallace) writes:
>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.

The Sparc has plenty of registers for each routine.
It's absurd to imagine that you've only got 8 for local use.
The incoming parameter registers may be reused as you're done with
then parameters (or spill the parameters if necessary).  How many
routines have 8 parameters anyway?  Further, the outgoing parameter
register can be use for temporaries in between procedure calls.

You may have to spill a little now and then, but you always have to
spill on real programs (except for the simplest leaf routines).  But
if you can keep most of the spills out of inner loops, then you've got
enough registers.

Preston Briggs
Newsgroups: comp.arch
From: bgr@sawwhet.owlnet.rice.edu (Robert Glen Rhode)
Subject: Re: GaAs CRAY
Keywords: Cray Computer, Gallium Arsenide
Organization: Rice University
Distribution: usa
Date: Tue, 7 Apr 1992 04:25:50 GMT

The ClariNet news tidbit I read last week said that
Cray Computer is having "mechanical" problems and
will try to build one 2-processor machine a month
until they get it nailed down, then will start building
8-processor machines.

Feel free to correct me, anyone.
Newsgroups: comp.arch
From: glew@pdx007.intel.com (Andy Glew)
Subject: Re: And now for something completely different...
Organization: Intel Corp., Hillsboro, Oregon
Date: Sun, 12 Apr 1992 03:01:14 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.  The first tells it on what shifts to add, and the second
    tells it on what shifts to subtract.

Many processor implementations have early outs for multiply and divide.

Theoretically a compiler could schedule for these when it knows the constant value.
--

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)
Xref: sparky comp.arch:5078 alt.folklore.computers:6534
From: grog@adagio.UUCP (Greg Lehey)
Newsgroups: comp.arch,alt.folklore.computers
Subject: Re: chip-on-chip technology
Date: 16 Apr 92 10:01:55 GMT
Followup-To: comp.arch
Organization: LEMIS, Schellnhausen 2, W-6324 Feldatal, Germany

In article <1992Apr15.061405.22573@public.sub.org> peterk@public.sub.org (Peter Kittel) writes:
>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.
>And as we here don't know this funny character at all, we say
>"Doppelkreuz-define", that would be "double cross" in English.

Well, also in Frankfurt (and other parts of Germany) it's referred to
as `Gartenzaun-define' (garden fence define) - not to mention
Klammeraffe, Gaensefuss and others.
-------------------------------------------------------------------------------
Greg Lehey		         | Public access UNIX available - try BSDI 
 LEMIS         			 | out on our machine! Mail and news 
W-6324 Schellnhausen 2           | connections available
Germany				 | Fax: +49-6637-1489
Tel: +49-6637-1488               | Mail: grog%lemis@Germany.Eu.net
Claimer: The opinions expressed *are* the opinions of LEMIS
Newsgroups: comp.arch
From: lindsay+@cs.cmu.edu (Donald Lindsay)
Subject: R5000
Date: Fri, 10 Apr 92 02:00:17 GMT
Organization: School of Computer Science, Carnegie Mellon

"...the company... said it has started work on an R4000 follow-on
that would likely perform in the 200 Specmarks range. That device
isn't scheduled to be completed until the 1995 timeframe or later,
though.

Until then, the highest-performance MIPS microprocessor would be the
100 MHz R5000, which would use the underlying R4000 technology and
thus isn't being portrayed as a full new generation. The R5000 is
expected to be ready in late 1993 with performance of 125-150
Specmarks, MIPS said.

Also in the works to augment the current 50 MHz implementation of the
R4000 are 67 MHz and 75 MHz designs, which should become available
later this year with respective throughput of 80 Specmarks and 105
Specmarks. Meanwhile, the lower-cost R4000 version is scheduled to
ship in mid-1993 and run at about 50 Specmarks.."

	Electronic News, P.19 6apr92
-- 
Don		D.C.Lindsay 	Carnegie Mellon Computer Science
Newsgroups: comp.arch,comp.lang.lisp