HDTenEightyP/NetNews huggingface dataset:
From: rschnapp@metaflow.com (Russ Schnapp)
Subject: Re: Does a 487sx shut down the 486sx??
Organization: Metaflow Technologies Inc.
Date: Tue, 8 Sep 1992 19:19:01 GMT

In article <1992Sep7.220629.29316@bcars64a.bnr.ca>, schow@bqneh23.bnr.ca (Stanley T.H. Chow) writes:
|> In article <1992Sep4.172131.27778@tandon.com> tdbear@tandon.com (Tom Barrett) writes:
|> >I truely cannot believe that the 486sx PGA (which probably
|> >still has the numeric) would not be tested thoroughly to
|> >ensure that all of the silicon is working (even though it
|> >won't be used) since there is a slight chance a damaged
|> >numerics area might cause contamination to the rest of the
|> >chip if (say) something overheats.
|> 
|> I assume the 486sx die would have at least disabled or disconnected
|> the numeric section, therefore it will be untested.

I'm _certain_ that I have read (and re-read, and re-re-read) here that
the 486SX die has not included the numeric coprocessor for many, many
moons.  It was there initially, but not anymore!
-- 

...Russ Schnapp
BIX: rschnapp           Email: uunet!metaflow!rschnapp or rschnapp@metaflow.com
Metaflow Technologies   Voice: 619/452-6608x230;  FAX: 619/452-0401
La Jolla, California    Unless otw specified, I`m speaking only for myself!
Newsgroups: comp.arch
From: prener@watson.ibm.com (Dan Prener)
Subject: Re: 128 bit floating point formats
Date: Wed, 16 Sep 1992 03:46:23 GMT
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 <GLEW.92Sep15181245@pdx007.intel.com> glew@pdx007.intel.com (Andy Glew) writes:

>Q: I believe that the RS6000's double double format is not hardware supported.
>Don't they just emit the correct sequence of DP flops to get the QP answer?

That is correct.
--
                                   Dan Prener (prener@watson.ibm.com)
From: torbenm@diku.dk (Torben AEgidius Mogensen)
Newsgroups: comp.arch
Subject: Re: No Branch Delay Slot(s)...
Date: 11 Sep 92 08:40:29 GMT
Distribution: comp
Organization: Department of Computer Science, U of Copenhagen

preece@urbana.mcd.mot.com (Scott E. Preece) writes:

>I think the implication is that the chip folks now believe they can do
>better with branch prediction and speculative execution than they could
>with a single delay slot.  Speeds being what they are, filling one slot
>in the bubble is no longer very interesting, and filling more than that
>is just not practical for hand (or compiler) coding techniques, so the
>chips basically *must* do it themselves, anyway.

I've always thought that delay slots were a bad idea: consider the two
cases

	if test jmp <address>
	instruction	; in delay slot

and

	instruction
	if test jmp <address>

Let's assume that the instruction in the delay slot doesn't modify
flags. Then it is a simple matter to have a lookahead of one to decide
whether the branch is taken. Certainly, it shouldn't be (much) more
difficult than the delay slot mechanism.

The case where the instruction does modify flags is most useful if the
flag information is used soon after in another test, for example in a
loop like

     .label
	if test jmp label
	instruction	; in delay slot

But such occurrences are not sufficiently common to make up for the
rather common case of having a NOP in the delay slot. The branch
lookahead mechanism is transparent and it will support arbitrary
lookahead without changing the code (which multiple delay slots
require).

Another strategy that diminishes pipeline stalls is conditional
instructions other than jumps. This will avoid many short forward
jumps. Alpha has conditional moves, HP-PA has a skip mechanism that
amounts to much the same thing, and in the ARM all instructions are
conditional. Code that on a conventional processor (with no delay
slot) looks like

	if test jmp label
	instruction
     .label

and with one delay slot

	if test jmp label
	NOP
	instruction
     .label

will on the ARM look like

	if !test instruction

The test adds no cycles to the execution time.

	Torben Mogensen (torbenm@diku.dk)
From: supnik@human.enet.dec.com (Bob Supnik)
Newsgroups: comp.arch
Subject: 128 bit floating point formats
Summary: Input requested on 128b IEEE formats
Keywords: quad precision, IEEE floating point
Date: 12 Sep 92 00:42:02 GMT
Organization: Digital Equipment Corporation


I have seen (at least) three formats for 128 bit (quad precision) IEEE
floating point:

1. Mips: 1 bit sign, 15 bit exponent, 112 bit fraction
   with explicit high order 1 (no hidden bit)

2. HP PA: 1 sign bit, 15 bit exponent, 113 bit fraction
   with implicit high order 1 (hidden bit)

3. RS/6000: two double precision numbers used, with exponents offset by
   2**(-53) (I believe), in effect 1 sign bit, 11 bit exponent, 105 bit
   fraction with implicit high order 1 (hidden bit)

I would appreciate inputs -- from both implementers and applications 
viewpoints -- on the pros/cons of these (or other) choices.

For reference: VAX implemented (with VAX floating rules, of course),
format #2.  No format has been published for Alpha.

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
Newsgroups: comp.arch,alt.folklore.computers
From: rf@cl.cam.ac.uk (Robin Fairbairns)
Subject: Babbage and politics
Reply-To: rf@cl.cam.ac.uk (Robin Fairbairns)
Organization: U of Cambridge, England
Date: Mon, 7 Sep 1992 13:46:43 GMT


In article <phillips.713439392@infs4>, phillips@swanee.ee.uwa.oz.au
(Christopher Phillips) writes:
[re: people's misconceptions about what stopped Babbage]
|> He also had major problems with politics.  He got on the wrong side
|> of some people in high places, who went to great lengths to block
|> or diminish grants in Babbages direction.  Combined with the
|> kind of project delays that seem to have become part and parcel
|> of the construction industry today, he didn't have much of a chance
|> of getting anything much done.

Babbage was truly remarkable in getting _any_ sort of government money
in his day.  We're talking about an era when government was much
smaller than anything you see in the developed world today.

He was a rich man to start with, and spent quite a bit of his own
money in getting to the point of being able to make a proposal to the
Board of the Navy for a machine to calculate navigation tables.
Sadly, he lost interest in the thing before _they_ thought he was
finished.  The net result of this was that all his further requests
for money met with increasing scepticism, and he finally reached the
point of not being able to get any support whatever.

That, combined with the obvious problems of being at the forefront of
the technology of the time, and the delays, and the finite size of his
personal fortune, meant that the projects all ultimately ended in
failure.
--
Robin (dump Brian Kay) Fairbairns                    rf@cl.cam.ac.uk
U of Cambridge Computer Lab, Pembroke St, Cambridge  CB2 3QG, UK
[Finally back in work - what a relief!]
Newsgroups: comp.arch
From: glew@pdx007.intel.com (Andy Glew)
Subject: Re: 128 bit floating point formats
Organization: Intel Corp., Hillsboro, Oregon
Date: Wed, 16 Sep 1992 02:12:45 GMT

    Bob Supnik	>Supnik@human.enet.dec.com

    I have seen (at least) three formats for 128 bit (quad precision) IEEE
    floating point:

    ...

    3. RS/6000: two double precision numbers used, with exponents offset by
       2**(-53) (I believe), in effect 1 sign bit, 11 bit exponent, 105 bit
       fraction with implicit high order 1 (hidden bit)


Q: I believe that the RS6000's double double format is not hardware supported.
Don't they just emit the correct sequence of DP flops to get the QP answer?
--

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: rf@cl.cam.ac.uk (Robin Fairbairns)
Newsgroups: comp.arch
Subject: Re: Are 64 Int or FP registers useful?
Keywords: Chip Real State, Register Usage
Date: 8 Sep 92 14:06:35 GMT
Reply-To: rf@cl.cam.ac.uk (Robin Fairbairns)
Organization: U of Cambridge, England


In article <1992Sep7.091904.2626@newsroom.bsc.no>, izahi@bsc.no (Raul
Izahi Lopez Hernandez) writes:
|>    Can somebody provide me with comments or references to pros and cons of
|> having a large register set on-chip. Lets say 64 Int and 64 FP
registers be it
|> 32-bit or 64-bit.
|>    Specifically is there a study that shows how many registers typical
|> programs would like to have (i.e. unlimited registers as resources, like
|> the studies on unlimited number of execution units)?
|>    This is for a microprocessor.

I can't offer a study, and I can't say anything about microprocessors.
However... We used to have here a (mainframe) machine that offered
user-mode programs free use of 93 registers (2 of which always read as
zero, one of which was the program counter, and one of which was a
register indexer - see that other thread...).

The compilers for that machine _never_ made cogent use of this
enourmous number of registers, except by way of the trick that one
regularly used in assembler programs of loading "useful constants"
into a set of registers at the start.  High-level language register
dumps had a certain monotony about them...
--
Robin (dump Brian Kay) Fairbairns                    rf@cl.cam.ac.uk
U of Cambridge Computer Lab, Pembroke St, Cambridge  CB2 3QG, UK
[Finally back in work - what a relief!]
From: jgj@ssd.csd.harris.com (Jeff Jackson)
Newsgroups: comp.arch
Subject: Re: Are 64 Int or FP registers useful?
Date: 8 Sep 92 18:56:43 GMT
Organization: I would rather be windsurfing.
In-reply-to: izahi@bsc.no's message of 7 Sep 92 09:19:04 GMT

>    Can somebody provide me with comments or references to pros and cons of
> having a large register set on-chip. Lets say 64 Int and 64 FP registers be it
> 32-bit or 64-bit.

I can't provide you with a study, but I can offer some personal
experience.  I work on the code generator for our family of compilers
(C, FORTRAN, ADA) on the MC88000 series of processors (where you have
32 general registers, and 32 float registers on the 110).  I assure
you that I do run out of registers from time to time.  I've seen
benchmarks where 64 registers would have helped tremendously.
Typically, these are simulations that consist of thousands of lines of
straight-line code and hundreds of variables.
--
============================================================================
Jeffrey Glen Jackson  _|_Satan jeered, "You're dead meat Jesus, I'm gonna
jgj@ssd.csd.harris.com |     bust you up tonight."
x5120                  | Jesus said, "Go ahead, make my day."
                   ~~~~~~~~~ -- Carman, "The Champion"
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
	Politically, I am neither conservative nor liberal --
		     I think for myself instead.
Newsgroups: comp.arch
From: stripes@pix.com (Josh Osborne)
Subject: Re: CPU and speed question
Keywords: thanks
Organization: Pix Technologies -- The company with no adult supervision
Date: Wed, 9 Sep 1992 17:09:35 GMT

[I think this is Dana Jacobsen jacobsd@solar.cor2.epa.gov, but can't tell from
the prev message]

>Operation      Moto 88110    TI SuperSPARC     DEC  Alpha
>
>Int add/sub        1/    1        1/   1          1/1-2
>Int mul            1/    3        4/   4      19-23/19-23
>Int div           18/   18       18/  18          ---
>FP add/sub         1/    3        1/   1          1/ 6
>FP mul             1/    3        1/   3          1/ 6
>FP div         13-26/23-26    6- 9/ 6- 9      30-63/30-63
>FP sqrt            ???        7-12/ 8-12          ???

Am I right in assuming that 1/3 means "1 outstanding (max) 3 cycles to
complete", or is it something else?
-- 
           stripes@pix.com              "Security for Unix is like
      Josh_Osborne@Real_World,The          Multitasking for MS-DOS"
      "The dyslexic porgramer"                  - Kevin Lockwood
We all agree on the necessity of compromise.  We just can't agree on
when it's necessary to compromise.       - Larry Wall
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.arch
Subject: Re: Multi uP P5 systems
Date: 14 Sep 92 14:33:44 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <n2vn=9h.erb@netcom.com>, erb@netcom.com (Elizabeth R. Brown) writes:
| 
| Well, I'm back.  Asia was great.  Prepair for hot rumor mongering.
| 
| On a tour of a major MB manufacturing plant my friend showed me what they
| were working on in the design lab.  It was an EISA board with sockets for
| four P5 chips!  He said the P5 has features that make it very easy to
| design multi-CPU boards.  

  I hate to say this, but what is anyone going to plug into the sockets?

  Rumor of the day: Intel has dropped the P5 design as unmanufacturable
and is redesigning the chip in 4000 angstrom biCMOS to improve yeild.
They will never sell commercial quantities of the P5 as it has been
shown.

  The Intel presentation at FORUM seemed to hint at this, and I've heard
other things, would someone from Intel care to deny this? 
-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
    I admit that when I was in school I wrote COBOL. But I didn't compile.
Newsgroups: comp.arch
From: anthony@tony.worldbank.org (T Anthony Allen)
Subject: Re: FPCA '93 Call for Papers
Reply-To: anthony@tony.worldbank.org
Organization: /home/arthur/Anthony/.organization
Date: Fri, 11 Sep 1992 17:54:55 GMT

The call for papers for a conference on functional programming
languages intrigued me. What is a functional programming language and
what differentiates it from a dis-functional language? I guess I am not
familiar with the terminology.  My curiousity is genuine. Any definition
would be appreciated.

Tony

---
+-------------------------------+---------------------------------------+
|  T Anthony Allen		| internet: anthony@tony.worldbank.org	|
|  Senior Budget Systems Analyst| UUNET	: uunet!nimbus!anthony		|
|  The World Bank		| BITNET: ANTHONY@IBRDVM1		|
|  Washington, D.C. 20433	| phone : (202)473-0199			|
|				| FAX	: (202)676-1634			|
+-------------------------------+---------------------------------------+
From: paul@taniwha.UUCP (Paul Campbell)
Newsgroups: comp.arch
Subject: Re: Not using integers
Date: 10 Sep 92 15:16:38 GMT
Organization: Taniwha Systems Design

In article <1992Sep8.182423.26063@athena.mit.edu> solman@athena.mit.edu (Jason W Solinsky) writes:
>Does anybody here know of any microprocessors which did not use any integer
>units or registers, but instead modified the floating point execution units
>to inhibit the normalization pipe stage whenever an "integer" flag within
>the instruction was set.

The good old Burroughs 6700 (and family now called the A-series) had/has a 
FP format for which a value with a 0 exponent looks like a 'normal' integer
(they use a signed integer rather than a 2's complement one) - the hardware
goes out of its way to keep a 0 exponent for values if it possibly can ...
this means that there are no FP/INT instructions, there's only one ADD, SUB,
MULT etc instructions

	Paul
-- 
Paul Campbell    UUCP: ..!mtxinu!taniwha!paul     AppleLink: CAMPBELL.P

       "Most American's day to day experience of 'Family Values' is found in
	brightly colored fliers from such organisations as Target and K-Mart."
Newsgroups: comp.arch,comp.lang.misc
From: rwallace@unix1.tcd.ie (russell wallace)
Subject: Re: "Training" of programmers
Organization: Trinity College, Dublin
Date: Thu, 10 Sep 1992 17:15:43 GMT

In <id.Z12T.QD5@ferranti.com> peter@ferranti.com (peter da silva) writes:

>In article <1992Sep4.151001.9886@sei.cmu.edu> firth@sei.cmu.edu (Robert Firth) writes:
>> This problem is pervasive.  Each generation sees a new and more monstrous
>> bloat in the size and cycle consumption of what I still think of as basic
>> system software - device drivers, editors, compilers, linkers.  And the
>> reason the programmers are so profligate of resources is that they have
>> never been taught that resources matter - they are told that, in computer
>> science, "everything is virtual", and all resources are infinite and free.

>Agreed. Because they never have to deal with an environment where this isn't
>true.

>> There is no technical perception of the machine as a real engine, with
>> finite capability, and no aesthetic perception that economy of means is
>> one of the cardinal qualities of good engineering.

>I think that this is only part of the problem. The other part is that they
>are never required to make do with less than the best. How many people
>graduated this year have ever used a machine that enforced a significant
>constraint on resource use?

!!! Well, try having to write a program in Ada on a system that takes
about 10 minutes to compile a 100-line program (and this is at 1 am in
the morning, with nobody else on the system!).

Though I agree with you: the program in question was thrown away as soon
as the marks were in, so we didn't have to care about run-time resource
consumption, or for that matter design and code bloat (which things
unfortunately tend to be considered positive attributes in computer
science courses).

--
"To summarize the summary of the summary: people are a problem"
Russell Wallace, Trinity College, Dublin
rwallace@unix1.tcd.ie
Newsgroups: comp.arch
From: jod@equator.com (John Setel O'Donnell)
Subject: Re: trapping speculative ops
Organization: Equator Technologies, Inc., Seattle, WA
Date: Sat, 12 Sep 1992 17:09:54 GMT

In article <Btvou1.6F9@news.orst.edu> pmontgom@math.orst.edu (Peter Montgomery) writes:
>In article <1992Aug31.224611.5196@odin.diku.dk> thorinn@diku.dk 
>(Lars Henrik Mathiesen) writes:
>>To summarize: trap bits are proposed to enable a compiler to move a
>>potentially trapping operation outside of a condition. As a special
>>case, this would allow many, if not all, of the same optimizations
>>that can be done if a load through a NULL pointer yields zeroes.
>
>	On the early models in the CDC Cyber series, such
>as the CDC 6400 and 6600, floating point errors
>(e.g., overflow, division by zero) generated special
>results (e.g., indefinite quantity).  They did not generate
>a trap until those NaN-like results were used as operands
>to other floating point instructions.

In the Multiflow TRACE family of machines, there were several architecture
features to support moving operations above IFs.

- There was a floating-point mode called "deferred exception" that acted
similarly to what's described above.  Register-to-register floating
point operations didn't signal exceptions; overflows wrote Inf, other
failures wrote NaN.  Chains of operations could move above an If.  We
checked for Nan/Inf when doing the following operations:
	- store to user memory (2 variants of store opcodes, one for 
				spill/restore, one for user stores which
				performed the check on the data)
	- convert to int	(don't want to lose exception status)
	- floating compare	(likewise)
This mechanism lost underflows; most users didn't care.  There were
compile-time options to specify whether to use precise exceptions or
this mode.

- There were 2 types of LD opcodes, one called "dismissable."  If no
valid address translation existed for a DLD, the target register 
was loaded with -1 (a NaN, and an unaligned pointer to boot) and 
the computation continued.  The compiler rewrote LD->DLD when making
a scheduling decision to move a LD above a branch.

I'm aware of experimental implementations on other systems of the latter
feature without hardware modifications, by changing the TLB-miss/page fault
code to check a bitmap in the process address space which specifies which
PC's have DLD's.

This is written up in ASPLOS-II (10/87) and IEEE Trans. Computers, 8/88.
Comments on the second (improved) implementation of these features are
in a paper in Supercomputing '90.
-- 
- - -
John Setel O'Donnell                      jod@equator.com
Equator Technologies, Inc.                206-328-6544 voice/fax
Seattle, WA                               Read everything by Alice Miller.
Xref: sparky comp.arch:9279 comp.lang.misc:2967
From: bds@mbunix.mitre.org (Smith)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: "Training" of programmers
Date: 8 Sep 92 14:40:02 GMT
Organization: The MITRE Corporation, Bedford, MA

In article <Bu5qD3.GAM@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
>
>>This problem is pervasive.  Each generation sees a new and more monstrous
>>bloat in the size and cycle consumption of what I still think of as basic
>>system software - device drivers, editors, compilers, linkers.  And the
>>reason the programmers are so profligate of resources is that they have
>>never been taught that resources matter - they are told that, in computer
>>science, "everything is virtual", and all resources are infinite and free.
>>There is no technical perception of the machine as a real engine, with
>>finite capability, and no aesthetic perception that economy of means is
>>one of the cardinal qualities of good engineering.
>
>>This must be changed.  Or real companies, with real problems, will continue
>>to hire english majors, biochemists and quantum mechanics to write their
>>programs; because, as a senior member of one such company told me: "It is
>>cheaper to train than to re-train."
>
>The problem is even more pervasive than that.  Our educational system never
>did that great a job of educating rather than training, but at least students
>used to be tested to a fair extent on understanding rather than rote.  This
>has almost vanished from the elementary and secondary schools, and is rapidly
>disappearing from the universities.  The calculus course never did that great
>a job on teaching the concepts, and only a fair one on examining them, but
>now even that is reduced.  What CS program does more than barely hint to the
>students that there is much more to what a computer can do than Pascal or C++?
>Or that there are real problems where these other things are useful?
>-- 
>Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399


I think the problem is even more pervasive than that.  I know of a
large contractor who had a programmer who discovered an excellent
alternative to the way some code had been written to that point.  He
rewrote it, improving performance and eliminating over 3KLOC.  His
management was furious with him, though, since his productivity that
week was -3000 LOC, and that meant about $1M in revenues!

Barry Smith
Xref: sparky comp.arch:9308 comp.lang.misc:2980
From: schow@bqneh23.bnr.ca (Stanley T.H. Chow)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: "Training" of programmers
Date: 9 Sep 92 14:22:53 GMT
Organization: Bell Northern Research Ltd, Ottawa

In article <id.Z12T.QD5@ferranti.com> peter@ferranti.com (peter da silva) writes:
>In article <1992Sep4.151001.9886@sei.cmu.edu> firth@sei.cmu.edu (Robert Firth) writes:
>> This problem is pervasive.  Each generation sees a new and more monstrous
>> bloat in the size and cycle consumption of what I still think of as basic
>> system software - device drivers, editors, compilers, linkers.  And the
>> reason the programmers are so profligate of resources is that they have
>> never been taught that resources matter - they are told that, in computer
>> science, "everything is virtual", and all resources are infinite and free.
>
>Agreed. Because they never have to deal with an environment where this isn't
>true.

And of course, some learn about reality very reluctantly. I venture to
guess that a majority of *paid* programming is done in an environment 
where the cost mattered: embedded control, PC/Mac programs, mainframe
computing, supercomputing, accounting, inventory, MIS, etc (actually, 
have I left out any major areas where people get paid to program?)

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