HDTenEightyP/NetNews huggingface dataset:
From: masjpf@gdr.bath.ac.uk (J P Fitch)
Newsgroups: comp.arch
Subject: SPARC Floating Point Query
Date: 9 Sep 92 13:59:13 GMT
Organization: School of Mathematics, University of Bath, UK

Can anyone throw any light on the following aspect of the SPARC?

We have a trivial C program which calls double divide.  Compiled to
assembler it creates what one might expect.  When we assemble the code
and look with adb we find that the assembler has created an additional
instruction, a fmovs, immediately after that fdivd.  We cannot find
anything in the documentation we have been able to find to explain
why, or what it is trying to avoid.  To make things worse, on an ICL
DRS6000 (SPARC) it does not add this instruction, and seems to work.
When I force it to avoid the extra fmovs (when we are in doubles!) it
seems to work in some contexts but not others.
  So what is the problem?  Below I give the full exhibits.
==John



The Program
===========

int foo (x,y)double x; double y;{ return x/y;}

which when passed through SUN's C compiler generates the assembler

LL0:
	.seg	"data"
	.seg	"text"
	.proc 04
	.global	_foo
_foo:
	!#PROLOGUE# 0
	sethi	%hi(LF12),%g1
	add	%g1,%lo(LF12),%g1
	save	%sp,%g1,%sp
	!#PROLOGUE# 1
	st	%i0,[%fp+0x44]
	st	%i1,[%fp+0x48]
	st	%i2,[%fp+0x4c]
	st	%i3,[%fp+0x50]
	ld2	[%fp+0x44],%f0
	ld2	[%fp+0x4c],%f2
	fdivd	%f0,%f2,%f4		<<< Note well
	fdtoi	%f4,%f5
	st	%f5,[%sp+LP12]
	ld	[%sp+LP12],%o0
	b	LE12
	nop
LE12:
	mov	%o0,%i0
	ret
	restore
       LF12 = -72
	LP12 = 64
	LST12 = 72
	LT12 = 72
	.seg	"data"


The Binary
==========

If I now assemble this and look at the disassemly (with adb) I get

foo?i
_foo:		sethi	%hi(0xfffffc00), %g1
_foo+4:		add	%g1, 0x3b8, %g1		 ! -0x48
_foo+8:		save	%sp, %g1, %sp
_foo+0xc:	st	%i0, [%fp + 0x44]
_foo+0x10:	st	%i1, [%fp + 0x48]
_foo+0x14:	st	%i2, [%fp + 0x4c]
_foo+0x18:	st	%i3, [%fp + 0x50]
_foo+0x1c:	ld	[%fp + 0x44], %f0
_foo+0x20:	ld	[%fp + 0x48], %f1
_foo+0x24:	ld	[%fp + 0x4c], %f2
_foo+0x28:	ld	[%fp + 0x50], %f3
_foo+0x2c:	fdivd	%f0, %f2, %f4
_foo+0x30:	fmovs	%f4, %f4		<<< Note
_foo+0x34:	fdtoi	%f4, %f5
_foo+0x38:	st	%f5, [%sp + 0x40]
_foo+0x3c:	ld	[%sp + 0x40], %o0
_foo+0x40:	ba	_foo + 0x48
_foo+0x44:	nop
_foo+0x48:	mov	%o0, %i0
_foo+0x4c:	ret
_foo+0x50:	restore
Newsgroups: comp.arch
From: clc5q@hemlock.cs.Virginia.EDU (Clark L. Coleman)
Subject: Re: Not using integers
Organization: University of Virginia Computer Science Department
Date: Fri, 11 Sep 1992 20:06:50 GMT


I have a vague memory of the announcement of the FRISC microprocessor by
Micron Technology up in Idaho.  I thought it had only floating point ALUs
and no integer units.  Can someone confirm or deny?
-- 
--------------------------------------------------------------------------
"It is seldom that any liberty is lost all at once." David Hume
|||  clc5q@virginia.edu (Clark L. Coleman)
Xref: sparky comp.arch:9370 comp.lang.misc:3031
From: phd85@seq1.keele.ac.uk (D.H. Holden)
Newsgroups: comp.arch
Subject: CPU and speed question.
Keywords: CPU's,speed, pc's workstations.
Date: 7 Sep 92 19:27:26 GMT
Organization: University of Keele, England


 Hi,
    I was wondering if any one could resolve my confusion,
    what is it that makes a workstation faster than a PC
    apart from the operating system.
    Because I've just read a article about a PC with a
    50Mhz clock, would this be faster than say a sun 
    workstation with 25mhz clock?
    I also read that dec are bringing out a new chip
    that can manage 200Mhz, is'nt this a massive jump
    from current chips, I thought the fastest intel chip
    only did 66Mhz.

    Hope this is the right group to post this, comp.arch
    sounded right,
    cheers, 
		Dave
Newsgroups: comp.arch,comp.parallel
From: wheinri@informatik.tu-muenchen.de (Werner Heinrich)
Subject: Reference Manuals for Multiflow TRACE and IBM RS/6000
Organization: Technical University Munich 
Date: 	Tue, 8 Sep 1992 16:24:47 +0200

For a project on formal specification of computer architectures targeted to 
the exploitation of instruction level parallelism, I'm desperately seeking
Architecture and/or Instruction Set Reference Manuals for the following two
machines:

- Multiflow TRACE ( this seems to be very difficult to get, since Multiflow 
                    don't exist any more; anybody has one ? )

- IBM RS/6000     ( whom to contact at IBM in Germany or elsewhere ? )

Any pointer would be greatly appreciated.

============================================================================
Werner HEINRICH                    email:  wheinri@informatik.tu-muenchen.de
Department of Computer Scienece
Technical University Munich

Newsgroups: comp.arch,sci.math,comp.lang.misc,comp.lang.fortran,comp.edu
From: hallam@zeus02.desy.de (Phill Hallam-Baker)
Subject: Re: Re: Scientists as Programmers (was Re: Small Language Wanted)
Reply-To: Hallam@zeus02.desy.de
Organization: Deutsches Elektronen Synchrotron, Experiment ZEUS bei HERA
Date: Fri, 11 Sep 1992 00:45:23 GMT

In article <KERS.92Sep7084415@cdollin.hpl.hp.com>, kers@hplb.hpl.hp.com (Chris
Dollin) writes:

|>In article ... hallam@zeus02.desy.de (Phill Hallam-Baker) writes:
|>
|>   RISC machines are fast bercause they abolish support for assembly code. On
|>a
|>   RISC machine instructions are provided for the sole benefit of compilers.
|>
|>Funny, that, because the RISC machine I have at home has an operating system
|>written primarily in assembler.
|>
|>[Perhaps we Acornites could say; on the ARM, machine instructions are
|>provided for -- and by -- the benefit of Roger Wilson!]

Well since the guy can assemble 6502 code in his head (including branches) you
would expect that sort of thing. All I would say is that the ARM is a "real"
RISC machine, ie it is genuinely a reduced instruction set, if you look at the
die it is pad bound with lotsa empty space. It is also a pretty unsuccessful
chip considering that it beat the rest of the RISC crowd to the market. Acorn
used RISC to allow them to build a chip very fast, the point about RISC though
is not reducing the instruction set, it is rationalising it, optimising it to
the demands of the task in hand. As with object oriented RISC is now an
information content free word. Rest assured that any new chip will be dubbed
"RISC" even a chip like DECchip "Alpha" with more variants for instructions than
Joan Collins has had husbands. I bet if Motorola were to reintroduce the 68000
as a 64 bit chip they would start by passing it off as a "RISC" design! I'm
waiting to find a label on toasters saying "object oriented" - you give the
toaster object a "bread" message and it returns a "toast" message...

--

Phill Hallam-Baker
Newsgroups: comp.arch,sci.math,comp.lang.misc,comp.lang.fortran,comp.edu
From: shenkin@avogadro.barnard.columbia.edu (Peter S. Shenkin)
Subject: Re: Re: Scientists as Programmers (was Re: Small Language Wanted)
Organization: Dept. of Chem, Barnard College, Columbia U, New York
Date: Fri, 11 Sep 1992 04:35:52 GMT
X-Posted-From: avogadro.barnard.columbia.edu
X-Posted-Through: sol.ctr.columbia.edu

In article <1992Sep11.004523.20552@dscomsf.desy.de> Hallam@zeus02.desy.de writes:
>...I'm
>waiting to find a label on toasters saying "object oriented" - you give the
>toaster object a "bread" message and it returns a "toast" message...

According to the fine print on my toaster, the "bread" is the data, the
"toast" is the output, and the little knob that you set to tell the toaster
how dark you want the toast is the message.

	-P.
-- 
************************f*u*cn*rd*ths*u*cn*gt*a*gd*jb*************************
Peter S. Shenkin, Department of Chemistry, Columbia Univ.,  New York, NY 10027
(212)854-8402    shenkin@avogadro.barnard.columbia.edu   shenkin@cunixf.BITNET
*********************** UNIX:  the wave of the present ***********************
Newsgroups: comp.arch
From: karger@osf.org (Paul A. Karger)
Subject: Re: Not using integers
Organization: Open Software Foundation
Date: Wed, 9 Sep 1992 14:30:04 GMT

In article <BuBB0L.MDD@mentor.cc.purdue.edu>, hrubin@mentor.cc.purdue.edu (Rubin Herman) writes:
|> 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 idea is to use this feature for a huge savings in area in processors which
|> >are intended primarilly for FP operation but must still have good integer
|> >performance.
|> 
|> I do not know about any micros in this category, but there are mainframes.
|> The CDC 6x00 series and its successors did have integer addition and 
|> subtraction, but multiplication was done in the floating unit.  The
|> Crays are somewhat similar, but have a rather odd integer multiply.
|> These machines do have integer registers, however, essentially usable
|> only for indexing.
|> 
|> The Cyber 205, etc., has no separate integer registers.  There is one
|> additional addition and one additional subtraction for address arithmetic,
|> which cause the right 48 bits to be handled in normal 2's complement
|> form.  Since unnormalized arithmetic is supported, and exponents are
|> handled without bias, this provides effectively for 24 and 48 bit integers.
|> Double precision is reasonably handled, so that 47+sign x 47+sign ->
|> 94+sign is no problem.  
|> -- 

The Burroughs B5500, B6500, B6700, etc. line of processors did not 
distinguish between integer and floating point datatypes.  I believe
that Unisys now sells a microprocessor version for a desktop model of
their current A-series computers.   
Newsgroups: comp.arch
From: John@boole.uucp (John Ahlstrom)
Subject: Re: Computer architects forced to change careers. NOT!
Organization: Boole & Babbage, Inc.
Date: Thu, 10 Sep 1992 18:34:49 GMT



NEW COMMENTS AT THE TOP INSTEAD OF THE BOTTOM OR INTERMIXED:

    RIGHT ON Timothy C May -- If you are not making mistakes
    you are not pushing hard enough.  Too bad others don;t
    write bout theirs so we can learn from theirs stead of
    ours.

In <x+tnpl#.tcmay@netcom.com> tcmay@netcom.com (Timothy C. May) writes:

>zeke@fasttech.uucp (Bohdan Tashchuk) writes:

>: Take a look at the history of the Intel 432. Was there ever a computer
>: architecture that was a worse disaster?
>: 
>: And yet, those most directly responsible were (at least initially) allowed an
>: almost completely free hand to architect what eventually became the Intel 960.
>: The proprietary crud that was left in the 960 after some sanity prevailed
>: became the cornerstone of BiiN's non-contribution to the computer industry.
>: 
>: Probably $100e6 down the drain between the 432 and BiiN. Not even taking into

>Ironically, I just posted a few thoughts on the 432 over in
>comp.sys.intel just yesterday. You might want to take a look. While
>the 8800/432/Gemini/Biib/960 saga is a long and convoluted one (and is
>arguably not over yet, as the 960 has gotten a lot of design wins), I
>think you're being simplistic in your characterization.

>: 
>: 	The concept of reward for a job well done and punishment for an abject
>: 	failure doesn't exist in many high-technology companies.

>Not true. Successes are rewarded, failures aren't. People leave
>companies, etc. But companies like Intel---and I was at Intel from
>1974 to 1986---don't shitcan engineers just because an effort failed!
>Mistakes are made, that's the nature of high tech. 

>: 	The 432 should be studied in all engineering schools as an example of
>: 	how NOT to design and implement a computer architecture.
>: 
>: 	When screwups like this happen, a LOT of people get hurt in the
>: 	resulting layoffs that endear the company to Wall Street.

>I agree the 432 should be studied. I'm surprised that none of the
>principals (one of whom later started Intel's iPSC supercomputer
>effort, which is doing very well) has written a detailed case history
>of what went wrong and what went right.

>As for your next comment, are you suggesting that with more careful
>planning mistakes can be eliminated? In any case, I don't recall
>seeing massive layoffs at Intel at any time.

>--Tim

>-- 
>..........................................................................
>Timothy C. May         | Crypto Anarchy: encryption, digital money,  
>tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
>408-688-5409           | knowledge, reputations, information markets, 
>W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
>Higher Power: 2^756839 | RSA MailSafe Public Key: by arrangement
Newsgroups: comp.arch
From: glew@pdx007.intel.com (Andy Glew)
Subject: Re: No Branch Delay Slot(s)...
Organization: Intel Corp., Hillsboro, Oregon
Date: Thu, 10 Sep 1992 04:12:08 GMT

    [phil@news.ccutah.edu (Phillip Neiswanger)]

    In the august issue of Byte there is a rather lightweight article on DEC's
    Alpha architecture and its current incarnate the 21064.  In the article it
    states that DEC deemed the branch delay slot to be of little value in
    future multiple(read >2) instruction issue implementations of the Alpha
    architecture.  If I remember correctly, the article states that the use of
    delayed branch slots could introduce incompatibilities from implementation
    to implementation.  This does not seem very intuitive to me.  Would anybody
    care to discuss how branch delay slots are going to affect future generation
    of RISC cpus as they enter the era of multiple(read >2) instruction issue
    implementations.

Branch delay slots are an artifact of a "first implementation".

E.g. the MIPS R[23]000 had one branch delay slot, so that was made
part of the architecture.

The MIPS R4000 really has 2 (maybe 3, I'm sure I'll be corrected)
branch delay slots, but there is still only one made architecturally
visible.


I only know of one mechanism to expose multiple branch delay slots in
a manner that varies cleanly between implementations, in that the same
binary will run nor matter how many branch delay slots are implemented
- Hwu and Chang's "Forward Semantic".  But even this assumes an
in-order machine implicitly.


--

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:9419 comp.lang.misc:3074
From: anton@mips.complang.tuwien.ac.at (Anton Martin Ertl)
Subject: Re: trapping speculative ops (LONG)
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Date: Tue, 8 Sep 1992 09:11:12 GMT

Andi Krall have written a tech report on this problem. Our solution is
slightly different from the one discussed here. The trap bit is
checked explicitely (by a branch instruction). This seems to waste
instruction bandwidth, but we assumed a high-degree superscalar
processor, where the problem is not the number of instructions, but
their low parallelism. This approach has the advantage that the
compiler can move more than the roots of a dependence DAG above a
branch.

@TechReport{ertl&krall92exceptions,
  author = 	"M. Anton Ertl and Andreas Krall",
  title = 	"Exception Handling vs.\ Speculative Execution",
  institution = 	"Institut f{\"u}r Computersprachen, Technische
		 Universit{\"a}t Wien",
  year = 	"1992",
  type = 	"Bericht",
  number = 	"TR 1851-1992-10",
  abstract =	"Superscalar processors, which execute basic blocks
		 sequentially, cannot use much instruction level
		 parallelism. Speculative execution has been proposed
		 to execute basic blocks in parallel.  Previous
		 approaches for speculative execution rely heavily
		 either on hardware or on software. A pure hardware
		 approach is expensive. A pure software approach like
		 restricted percolation suffers from low performance,
		 because exception-generating instructions cannot be
		 executed speculatively.  General percolation solves
		 this problem by ignoring exceptions. This behaviour
		 is clearly unacceptable, as many applications rely on
		 the correct handling of exceptions.  We propose
		 delayed exceptions, a combination of hardware and
		 compiler extensions that can provide correct
		 exception handling in compiler-based speculative
		 execution.  Exception-generating instructions are
		 split into a trap-noting version that can be moved
		 around freely, and a trap-check that calls
		 compiler-generated fix-up code on an exception.
		 Delayed exceptions can also be used to solve the
		 imprecise exception problem."
}

- anton
-- 
M. Anton Ertl                    Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
From: zhu@cs.utexas.edu (Kai Zhu)
Newsgroups: comp.arch
Subject: Performance of SPARC station 1
Date: 9 Sep 1992 16:55:39 -0500
Organization: CS Dept, University of Texas at Austin
NNTP-Posting-Host: panda.cs.utexas.edu

Does anyone know the performance of SUN SPARC station 1 in terms
of MIPS ?  I got some data from gatekeeper.dec.com, but it
includes only SPARC IPC,etc.  Is there any ftp site I can get similar data
on SPARC 1 ?  Thanks in advance.

-Kai Zhu
Newsgroups: comp.arch
From: wheinri@informatik.tu-muenchen.de (Werner Heinrich)
Subject: Seeking Reference Manuals for Multiflow TRACE and IBM RS/6000 
Organization: Technical University Munich
Date: Wed, 9 Sep 1992 12:41:16 GMT

For a project on formal specification of computer architectures targeted to 
the exploitation of instruction level parallelism, I'm desperately seeking
Architecture and/or Instruction Set Reference Manuals for the following two
machines:

- Multiflow TRACE ( this seems to be very difficult to get, since Multiflow 
                    don't exist any more; anybody has one ? )

- IBM RS/6000     ( whom to contact at IBM in Germany or elsewhere ? )

Any pointer would be greatly appreciated.

============================================================================
Werner HEINRICH                    email:  wheinri@informatik.tu-muenchen.de
Department of Computer Science
Technical University Munich
From: mjohnson@netcom.Netcom.COM (Mark Johnson)
Newsgroups: comp.arch
Subject: Re: Adder Designs in Modern Microprocessors
Date: 11 Sep 92 00:59:44 GMT
Organization: Netcom Online Communications Service

Appendix A of Hennessy and Patterson gives loads of
detail about implementing arithmetic functions on
IC's.  It also has three relatively thorough
examples of 1987-vintage chips and their hardware,
algorithms, tradeoffs, and performance on
arithmetic functions.
From: jon@alpha.ee.ufl.edu (Jon Mellott)
Newsgroups: comp.arch
Subject: Re: Intel CAD coprocessor?
Date: 9 Sep 92 19:22:42 GMT
Distribution: usa
Organization: EE Dept at UF

The Intel RapidCAD processor chipset is a replacement for the 386DX/387DX chipset.
The DX is the operative word here: DX's (from Intel, anyway) are PGA devices 
which are usually socketed. 

I haven't used one yet so I can't make any comments on Intel's claimed performance
gains. If you have a 386 machine it is an alternative to upgrading to a 486, 
however, these days, upgrading to the 486 is not a whole lot more expensive 
(if you can migrate your memory to the new machine, that is). The RapidCAD 
is not as fast as the 486.

Hope this helps...

Jon Mellott
High Speed Digital Architecture Laboratory
University of Florida
(jon@alpha.ee.ufl.edu)
From: khb@chiba.Eng.Sun.COM (Keith Bierman fpgroup)
Newsgroups: comp.arch
Subject: Re: Computer architects forced to change careers. NOT!
Date: 10 Sep 92 19:25:55
Organization: Sun MegaSystems
NNTP-Posting-Host: chiba
In-reply-to: John@boole.uucp's message of Thu, 10 Sep 1992 19:47:33 GMT


In article <1992Sep10.194733.8001@boole.uucp> John@boole.uucp (John Ahlstrom) writes:


   >	The concept of reward for a job well done and punishment for an abject
   >	failure doesn't exist in many high-technology companies.

		   Reward for well done exists in all the successful ones I know.
		   Never as much as I think is deserved, sometimes not even enough
		   to keep the well doers there it is true.  If you punish for
		   failure you are likely to discourage trying hard things.

The Punishment should Fit the Crime (not be nonexistant).

If the Crime is an ontime quality implementation of the wrong product
... the Architect is not really the one who should be flogged (unless
they were also the head of the strategic Marketing team ;>).

If the Crime is failure to establish correct procedures, manage the
team, or otherwise misadmister the effort .... one might think twice
about having that person do more management (of course, they might be
thought to have Learned Their Lesson).

If the Crime is to mispredict technology ... and that alone ... being
Wrong may be punishment enough in and of itself ;>

Of course, IMHO only.
--
----------------------------------------------------------------
Keith H. Bierman    keith.bierman@Sun.COM| khb@chiba.Eng.Sun.COM
SunPro 2550 Garcia MTV 12-33             | (415 336 2648) fax 964 0946
Mountain View, CA 94043  <speaking for myself, not Sun*> Copyright 1992

Newsgroups: comp.arch
From: rf@cl.cam.ac.uk (Robin Fairbairns)
Subject: Re: Computer architects forced to change careers. NOT!
Reply-To: rf@cl.cam.ac.uk (Robin Fairbairns)
Organization: U of Cambridge, England
Date: Fri, 11 Sep 1992 13:35:32 GMT


In article <1992Sep9.213319.7894@fasttech.uucp>, zeke@fasttech.uucp
(Bohdan Tashchuk) writes (quotes omitted):
|> Take a look at the history of the Intel 432. Was there ever a computer
|> architecture that was a worse disaster?

I was a manager when the 432 was announced.  With commendable
dedication to principle I delegated attending a seminar Intel had
invited us to.  The woman I sent had (like me) come out of CS
research. When she came back, she remarked that the whole set up
was so exciting that she would have jumped at a job if they had been
offering them.

The 432 attacked problems that I had been involved with in
architecture research in the 70s.  While it obviously failed, it
seemed like a signpost to me - silicon was going to become more and
more complex, and be able to solve more and more extreme problems.  Of
course, what has actually happened is that the complexity has gone on
increasing, but (following the earthquake of the introduction of RISC
in most of the industry) has been pretty largely devoted simply to
increasing throughput, ignoring so many of the CS-y ideas that the 432
addressed.

|> And yet, those most directly responsible were (at least initially)
allowed an
|> almost completely free hand to architect what eventually became the
Intel 960.
|> [...]
|> 
|> The concepts behind RISC have helped bring some sanity back into the field.

Hmmm.  Depends what you mean by sanity.  I still fancy the idea of
firewalls existing in the hardware I use.  Don't tell me it's not
possible (chip design is so damned clever nowadays).  I do understand
that it's not the way of (today's) world, and I appreciate the quality
of the thinking behind many of today's designs.  But, as a programmer
(at heart ;-), I still appreciate other things than pure speed...
--
Robin (dump Brian Kay) Fairbairns                    rf@cl.cam.ac.uk
U of Cambridge Computer Lab, Pembroke St, Cambridge  CB2 3QG, UK
From: peter@ferranti.com (peter da silva)
Subject: Re: OS/MFT and Macintosh (was: ..History)
Organization: Xenix Support, FICC
Date: Tue, 8 Sep 1992 19:27:21 GMT

In article <Bu4J78.785@exnet.co.uk> dhd@exnet.co.uk (Damon) writes:
>  2) Long market stability means commodities get cheaper.  We can't all
>     have the latest technology on our desks anyway, so better 20 years
>     out of date and dirt cheap than not at all.  Ie better DOS on 50m
>     desks than super-duper WhatzitOS (TM) on 50,000 and crank desk
>     calculators on the rest.

Except that super-duper-whatzitos runs more efficiently and responsively
on smaller systems than today's DOS users expect, and has been available
on personal computers for 6-15 years (depending on your value of whatzitos).
-- 
Peter da Silva                                               `-_-'
Ferranti Intl. Ctls. Corp.                                    'U` 
Sugar Land, TX  77487-5012
+1 713 274 5180                                   Har du kramat din varg idag?
Newsgroups: comp.arch