HDTenEightyP/NetNews huggingface dataset:
From: tmb@arollaidiap.ch (Thomas M. Breuel)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: Hardware Support for Numeric Algorithms
Date: 6 Nov 1992 17:18:12 GMT
Organization: MIT Artificial Intelligence Lab
Distribution: world
Reply-To: tmb@ai.mit.edu
NNTP-Posting-Host: arolla.idiap.ch

In article <1992Nov5.202412.7266@linus.mitre.org>, bs@gauss.mitre.org (Robert D. Silverman) writes:
|> In article <1992Oct29.153514.22927@yrloc.ipsa.reuter.COM> rbe@yrloc.ipsa.reuter.COM (Robert Bernecky) writes:
|> :
|> :I write programs for correctness and maintainability first, THEN worry
|> :about little details such as performance. If you create something that's
|>  
|> You've probably never done any large scale computing.
|> 
|> I measure the run time of my algorithms in MIPS-YEARS.  A MIPS-YEAR
|> is a 1 MIPS machine running for 1 year, or approximately 3.1 x 10^13
|> instructions.  Jobs that take several hundred MIPS-YEARS are not uncommon.
|> 
|> Needless to say, there are people who have to worry about speed FIRST,
|> and that other considerations are (almost) irrelevent.
|> 
|> I wish you people would stop insulting Herman simply because his requirements
|> leads to code that is different from your petty and self-righteous 
|> pre-conceived notions about coding style.
|> 
|> :wrong, or that has to be scrapped in a year because nobody can understand
|> :it, who cares how fast it runs?
|>  
|> Not everyone writes commercial code, or code for customers. Maybe it's
|> a research project that will end in a year. Stop being so provincial.

I do write and use long-running programs (weeks, months) that use
multiple workstations extensively in my work.

For such programs, I find that correctness and maintainability are of
paramount importance.  Efficiency, on the other hand, is of much
less importance.  If I run my program once for 9 weeks, I'm going to be
much better off than if I speed it up by 30% but have to run it twice
(for a total of 12 weeks) because I introduced some error.

I think the idea that scientific programmers have to squeeze every last
cycle out of their machines is a myth passed on from generation to
generation and is out of touch with the modern economic realities of
programming. The only people who have to squeeze every last cycle out
of their programs are real-time programmers and software/hardware
vendors who are concerned with looking good on benchmarks.

I wouldn't care much if you make yourself unhappy by writing messy,
unmaintainable, unportable, "optimized" code that will crawl along 
miserably once the next generation of hardware comes along. However,
sadly, users like you are the most vocal when it comes to incorporating
unnecessary and costly "efficiency" features into languages, operating
systems, and hardware, and the rest of us have to pay the price
and suffer the consequences.

					Thomas.
Newsgroups: comp.arch,comp.lang.misc
From: di1helol@claudius (Helge Olsen)
Newsgroups: comp.arch
Subject: The old hercules graphics card
Date: 5 Nov 92 11:44:14 GMT
X-Newsreader: Tin 1.1 PL3


  I wonder if anyone knows how to set/unset graphics mode on the HGC
(yes, I still use it), preferrably in C-code, as I will be using it in
both MS-DOS and COHERENT (unixlike opsys). I'm not sure if this is the
right group, so if not, just ignore this posting.
  Anyone who wants to answer, please use email to address
	di1helol@caligula.his.se

Thanks in advance..
From: tremblay@flayout.Eng.Sun.COM (Marc Tremblay)
Newsgroups: comp.arch
Subject: Re: RISC goes CISC?
Date: 7 Nov 1992 18:55:11 GMT
Organization: Sun Microsystems, Mt. View, Ca.
NNTP-Posting-Host: flayout

In article <1992Nov6.092012.19239@rhein-main.de> vhs@rhein-main.de writes:
>Under this assumption, how does e.g. SuperSPARC fit this principle? As far
>as I know the processor does a lot of cross-checking between pipelines,
>squashing instructions depending on non-trivial conditions, etc. Is that done
>just to maintain compatibility with previous implementations?
>Could, theoretically, the most recent compilers take care of this
>at compile-time, thus eliminating the need for run time
>checking (again theoretically since people want to run their old code).

Considering that Sun has the largest base of applications running on
workstations, it is very important to improve the performance of existing
binaries running on SuperSPARC without having to re-compile the source.
The increase in performance for existing binary is around 2x-3x for
SuperSPARC running at the same clock frequency (vs. Cypress 40MHz SPARC).

Notice that the fact that SuperSPARC takes care of all the interlocks between
instructions does not mean that the compiler cannot help improve the
performance. SuperSPARC is an in-order processor which means that
incoming instructions do not bypass older instructions even if older
instructions are stalled. Thus it is important for new compilers
to perform scheduling based on instruction latencies and on the
functional units available.

- Marc Tremblay.
Sun Microsystems.
Xref: sparky comp.arch:10407 comp.sources.wanted:4928 comp.unix.programmer:5165
From: storm@cs.mcgill.ca (Marc WANDSCHNEIDER)
Newsgroups: comp.arch,comp.sources.wanted,comp.unix.programmer
Subject: Tools to measure Pointer Usage
Date: 5 Nov 92 12:45:15 GMT
Organization: SOCS - McGill University, Montreal, Canada



	We are about to undertake on a project to study pointer usage in
computer programs, and were wondering if anybody has written a tool that
will tell you what percentage of loads are, in fact, just getting addresses
for pointer dereferences...

	If such a tool has been written, we would like to save ourselves the
time of writing it.  If not, we would appreciate any suggestions on how we'd
go about doing this.

	Toodlepip!
	Marc 'em.
-- 
  storm@cs.mcgill.ca           McGill University         "-- Attack ships on
  Marc Wandschneider           Montreal, CANADA             fire "
	Any opinions expressed are not mine, but those of the Demon Lord
      Yeegeheeegenogohugu who possessed me whilst I munched on Raisin Bran.
From: walter@zarquon.Eng.Sun.COM (Walter Bays)
Newsgroups: comp.arch
Subject: Re: MIPS R4400
Date: 9 Nov 1992 18:15:33 GMT
Organization: Sun Microsystems
Distribution: world
Reply-To: walter@zarquon.Eng.Sun.COM
NNTP-Posting-Host: zarquon

In article lflj8pINN158@spim.mti.sgi.com, cprice@mips.com (Charlie Price) writes:
>>
>The detail on this wasn't in the press release, so here it is.
>
>R4400 SC 75 MHz SPEC-89 *simulations* using IRIX "best binaries".
>The compilation flags for the binaries are whatever SGI published
>for SPEC-89 for the Crimson or Indigo-4000.  They are complicated.
>
>Peak75 is intended to be the fastest uniprocessor you could reasonably
>build using this chip in order to illustrate the performance available
>from the *CHIP*.
>These parameters are not intended to represent a
>system that any vendor is currently building or will build.

Congratulations again to MIPS for going beyond the bare minimum in SPEC
disclosure requirements and telling us how you simulated these numbers.

>In article <JCALLEN.92Nov6135200@marley.think.com> jcallen@marley.think.com (Jerry Callen) writes:
>[I was surprised to see MIPS use SPEC 89 numbers...]

I also wonder why you would use the old 89 suite.  Was it that some of
the new 92 benchmarks are too complicated to simulate, in particular
026.compress and 072.sc?  (I believe there are ways around the
difficulties.)  But even if SPECint92 was intractable, can't you at
least simulate SPECfp92?

---
Walter Bays                                         walter.bays@eng.sun.com
Sun Microsystems,  2550 Garcia Ave.,  MTV15-404,  Mountain View,  CA  94043
(415) 336-3689     SPEC Steering Committee Chairman      FAX (415) 968-4873

Newsgroups: comp.arch
From: jckelly@netcom.com (John Kelly)
Subject: Good Examples of SPARC Assembly code sought
Summary: Looing for good examples of SPARC assembler
Keywords: SPARC Assembler
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Sun, 8 Nov 1992 03:58:40 GMT

I'm looking for some good examples of SPARC assembler code.  I'm interested
in string and memory move oriented code.  I have the SPAC architecture Manual
from SPARC International but that's of little help.  Any examples, ftp sites
or suggestions would be appreciated.  I asked my local Sun SE but he
couldn't help.

Thanks in advance,


-- 
John C. Kelly  Work:   jckelly@opus.insoft.com
	       Home1:  jckelly@netcom.com
               Home2:  jckelly@world.std.com
DISCLAIMER: I speak for me.  Only.  "Change is inevitable. Growth is optional."
                                          

Newsgroups: comp.arch,comp.lang.misc
From: dhd@exnet.co.uk (Damon)
Subject: Re: CLU break and continue (Was: Re: A challenge to the anti-goto)
Organization: ExNet Systems Ltd Public Access News, London, UK
Date: Mon, 9 Nov 1992 16:12:37 GMT

In article <BRADLEY.92Nov9101822@marley.think.com> bradley@marley.think.com (Bradley Kuszmaul) writes:
>In article <1992Nov9.114323.22688@rdg.dec.com> jch@rdg.dec.com (John Haxby) writes:
>
>   ...
>   It's not surprising that the Ada exception mechanism is similar to CLU's
>   since CLU is one of Ada's ancestors.
>
>   CLU has two exception mechanisms for slightly different purposes.  One
>   mechanism is for returning an exception from a procedure call: a procedure
>   can signal an exception to be caught by its caller (the exception is not
>   propagated up the procedure call stack) or by a generic handler for
>   unhandled exceptions.  The other mechanism is a local form that allows a
>   block (eg in a loop or if-statement) to exit to an enclosing block.
>   Apart from the local/procedure-call difference the two mechanisms are
>   identical, although `signal' tends to be expensive and `exit' is simply
>   an unconditional branch. ...
>
>The signal is not as expensive as you might think.  This is because the
>exception is not propagated up the call stack.  I remember descriptions of
>two implementations of signal, both of which had the property that
> - if the signal is not raised, there is zero runtime cost (e.g., to set up the
>   signal handler.
> - if the signal is raised, only a few instructions need to execute to
>   figure out where the signal handler is and to jump to it.
> - if the appropriate handler is not defined, it only takes a few more
>   instructions to figure out where the `failure' handler is and to jump to
>   it.

I think the New Jersey implementation of ML also only takes a few
instructions to get to an exception handler from the raising of the
exception.  I'm no expert on how NJML is implemented, so maybe someone
out there could explain how ML does it...

Damon
-- 
Damon Hart-Davis                          Internet: dhd@exnet.co.uk, d@hd.org

PUBLIC ACCESS UNIX (Suns), NEWS AND MAIL FOR UK#5 PER MONTH.  FIRST MONTH FREE.
[1.34] Cheap Sun eqpt.  UUCP news/mail feeds.  Tel/Fax: +44 81 755 0077.
From: lindsay+@cs.cmu.edu (Donald Lindsay)
Newsgroups: comp.arch
Subject: Re: DEC Alpha AXP System Performance
Date: 12 Nov 92 03:39:52 GMT
Article-I.D.: cs.BxL3IH.KtH.2
Organization: School of Computer Science, Carnegie Mellon

In article <15445@auspex-gw.auspex.com> guy@Auspex.COM (Guy Harris) writes:
>Hmm.  As I remember, somebody from DEC at a session on topics such as
>OSF/1-on-MIPS on Tuesday night at the San Antonio USENIX claimed that
>HP-PA was "out of gas"; anybody know what his response to the above
>figures are?

He would have known about the 7100, although not its exact SPECs.
So, he's not *too* surprised.

What he may have meant, is that HP won't be able to use offchip
primary cache much longer. That was difficult at 66 MHz, and is
really impressive at 100 MHz. Even HP can't do it at 200 MHz, surely.

DEC's architects also have a low opinion of HP's high semantic
loading. That is, HP has instructions that also do some second thing -
such as skip-on-condition. The Alpha team avoided that, and have
handwaving arguments about how this will help in future "aggressive"
implementations.
-- 
Don		D.C.Lindsay 	Carnegie Mellon Computer Science
Xref: sparky comp.arch:10678 comp.lang.misc:3620
From: dik@cwi.nl (Dik T. Winter)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: Hardware Support for Numeric Algorithms
Date: 13 Nov 92 01:01:31 GMT
Followup-To: comp.arch
Organization: CWI, Amsterdam

In article <1992Nov12.131856.12605@linus.mitre.org> bs@gauss.mitre.org (Robert D. Silverman) writes:
 > In article <1992Nov10.153705.27804@yrloc.ipsa.reuter.COM> rbe@yrloc.ipsa.reuter.COM (Robert Bernecky) writes:
 > :>I measure the run time of my algorithms in MIPS-YEARS.  A MIPS-YEAR
 > :>is a 1 MIPS machine running for 1 year, or approximately 3.1 x 10^13
 > :>instructions.  Jobs that take several hundred MIPS-YEARS are not uncommon.
 > :
 > :Bad guess, unless Crays, 3090s (Yes, I know they barely count) and
 > :a bit of CM-2 don't count.
 >  
 > Several hundred MIPS-YEARS is a Cray running for a whole year or two. What jobs
 > have you run on Cray-class computers that take a whole year? 
 > 
Not a whole year.  But one program I was involved in used one CPU-month on
a Cyber 205.  I had taken two weeks to optimize it beyond recognition.  And
it was still correct (it found some hardware bugs).  And indeed speed was
the most important.
-- 
dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland
home: bovenover 215, 1025 jn  amsterdam, nederland; e-mail: dik@cwi.nl
From: lindsay+@cs.cmu.edu (Donald Lindsay)
Newsgroups: comp.arch
Subject: Re: Mainframe >> PC, why?
Date: 7 Nov 92 17:02:53 GMT
Article-I.D.: cs.BxCvCu.JIn.2
Organization: School of Computer Science, Carnegie Mellon

djakman@fwi.uva.nl (Kemal  Djakman) writes:
>But, my question is, what makes the (current) difference in power for the
>mainframes against the PCs?

There are a number of differences. CPU power used to be one of them,
but that is ceasing to be true.

The other differences largely remain:
- multiprocessor - 4,6 or 8 way.
- big caches: may be megabytes/CPU instead of kilobytes.
- big memory: plural gigabytes. [And it may be SRAM, not DRAM, at that.]
- "solid state disk", ie plural gigabytes of block-access RAM.
- high aggregate memory bandwith: the processors do not compete
	for a limited resource such as a memory bus.
- high aggregate I/O bandwidth - GB/s not MB/s.
- high channel counts - e.g. a hundred times as many I/O devices as
	you can imagine attaching to one PC.
- extensive fault detection and fault tolerance.
- features for rapid fault analysis and rapid repair.
- serious power conditioning and power backup - like, diesels.
- software suitable to keep the above busy.

Not that I'm advocating traditional mainframes. It will be very
interesting to watch HP and DEC as they build RISC-based mainframes.
These new machines are for a new technical environment (increasingly
fast networks) and for an application mix that is increasingly
distributed.
-- 
Don		D.C.Lindsay 	Carnegie Mellon Computer Science
From: kh@dcs.glasgow.ac.uk (Kevin Hammond)
Newsgroups: comp.arch
Subject: Re: SPA: pixie for Sparc architecture
Date: 5 Nov 92 14:16:07 GMT
Organization: Computing Sci, Glasgow Univ, Scotland

In article <1dasktINNm0m@oak43.doc.ic.ac.uk> ijp@doc.ic.ac.uk (Ian Palmer) writes:
>In article <1992Nov5.084954.8390@kum.kaist.ac.kr> symin@cosmos.kaist.ac.kr (Min Sanglyeol) writes:
>  Could someone in the netland please indicate whether the trace generation
>  program called SPA is public domain software and if so where I can get that
>  through anonymous ftp ? 
>
>It is 'currently' available at :  june.cs.washington.edu in /pub/ai

That seems to be some kind of AI planning system -- certainly not a trace
generator!  If anyone can tell where this really lives, I'd be grateful...

Kevin


-- 
Dept. of Computing Science, Glasgow University.    E-mail: kh@dcs.glasgow.ac.uk

This Signature Intentionally segmentation fault
Newsgroups: comp.arch,comp.lang.forth
From: torek@horse.ee.lbl.gov (Chris Torek)
Newsgroups: comp.arch
Subject: Re: integer/BCD/... dollars (was IEEE used for Dollars and Cents)
Date: 9 Nov 92 02:33:05 GMT
Reply-To: torek@horse.ee.lbl.gov (Chris Torek)
Organization: Lawrence Berkeley Laboratory, Berkeley
NNTP-Posting-Host: 128.3.112.15

(Last word on this non-computer-architecture stuff :-) )

I wrote:
>> Signed integers are not an absolute must, but precision greater than
>> one penny is; most businesses seem to keep records to five digits or so.

In article <2664312@zl2tnm.gen.nz> don@zl2tnm.gen.nz (Don Stokes) writes:
>Figures are only _published_ to five digits or so.  Bookkeeping must be
>to the last cent,

Sorry, I meant `five digits past the decimal point', the decimal point
being dollars.  These are apparently called `mills', i.e., thousanths
of a cent ($0 + 0 cents + 0.001 cents = 1/1000 cents = 0.00001
dollars).

I did drop a decimal point in my kitchen arithmetic:

	2^64 =	18446744073709551616
in mills:	184467440737095.51616
or:	$184 467 440 737 095.51616
or:	$184 467 441 million
or:	$184 467 billion [U.S. usage, though I understand `milliard' is
				dropping out of favour]
or:	$184 trillion

If signed, we have to cut this in half ($92 trillion).

(Since our debt has been growing exponentially, this is not really much
worse than I thought.  Exponential rapidly overwhelms a factor of ten.
Note, incidentally, that 18-digit BCD has less range than 64-bit
binary.  Other random side note: the traditional way to retire the
national debt is high inflation.  When this happens, will accountants
stop using mills?)
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov
From: torbenm@diku.dk (Torben AEgidius Mogensen)
Newsgroups: comp.arch
Subject: Re: MINIMUM instruction set
Date: 13 Nov 92 11:31:47 GMT
Organization: Department of Computer Science, U of Copenhagen

pete@jura.uucp (Pete Bevin) writes:

>You can get away with four instructions in the following (rather
>inefficient) Turing-Machine-equivalent architecture.  Allow yourself a
>number of registers, each of which can hold large enough numbers for
>what you want to do.  Then, you only need:

>	Z(register):        Zero a register
>	S(register):        Increment a register (`S' for `successor')
>	T(r1, r2):          Transfer value from r1 to r2
>	J(r1, r2, address): Jump to address if r1 and r2 hold the same
>			    value.

>You wouldn't want to program it, but I guess it's fairly easy to reason
>mathematically about it.

The efficiency of such a machine is horrendous even compared to the
one-instruction machine (reverse subtract and skip on borrow). On the
latter you are at least able to do most arithmetic only about ten
times slower than a "normal" processor. The main limitation of the
latter is the lack of bitwise logic operations. Though these can be
simulated using subtraction, this is horribly slow (though not as bad
as on the 4 instruction machine above). If we make the single
instruction capable of both logic and arithmtic at the same time we
are home. A very general instruction would be

	x:=(a-b) and not (c>>d), skip on borrow

but that has 5 addresses. We can reduce this to 4 by letting x be
equal to one of the arguments, say b and to 3 by replacing d by a
constant, say 1. The latter makes arbitrary shifts more expensive. One
could consider to make the shift interact with the borrow flag, but I
think that would only complicate things.

One could consider what we the purpose of a one-instruction machine
is, apart from proving it can be done. None of the above machines will
be substantially smaller than normal machines if built in hardware, so
this is not a good reason. The code density will be horrible, as you
need more instructions and these are not very much smaller, if at all
(as they need memory operands).

So here is a challenge: design a machine that uses no more than 4 bits
per instruction (including operand fields), is Turing complete, not
terribly inefficient and which can be built using far less hardware
than current microprocessors. The latter would make it suitable for
massively parallel systems.

	Torben Mogensen (torbenm@diku.dk)
Newsgroups: comp.arch
From: cholette@JSP.UMontreal.CA (Cholette Martin)
Subject: ************* Architecture Project HELP ************
Organization: Universite de Montreal
Date: Mon, 9 Nov 1992 19:55:47 GMT



Hello everyone!

 I have a class in computer architecture, and I have to make an oral
 and written presentation for my class project. I can choose whatever
 subject I want ( subject to approval of course ) that is related to
 comp. architecture. My oral presentation must be between 30 - 50 minutes,
 and the written report must be 10-20 pages. I am a 3rd year comp. sci.
 student. 

 Does anyone have any suggestions as to which topic I should choose?
 I am looking for something recent and hopefully " cool and interesting "
 I would prefer to do it on a topic that is relatively unknown, hence
 my difficulty in finding a subject. I would appreciate any insight!

 Thanks a million!

 Martin Cholette
 cholette@jsp.umontreal.ca
Xref: sparky comp.arch:10609 comp.lang.misc:3585
From: martin@math.rwth-aachen.de (  Martin Schoenert)
Subject: Re: DEC Alpha AXP System Performance
Keywords: Alpha, AXP, SPEC, DEC
Organization: Rechnerbetrieb Informatik  /  RWTH Aachen
Date: 12 Nov 92 07:51:57 GMT

bhandarkar@wrksys.enet.dec.com (Dileep Bhandarkar) writes:

    Here is a summary of SPEC results for Alpha AXP Systems announced today.

    [SPEC89 numbers deleted]

    DEC 10000 Model 610 AXP, @200 MHz
        SPECint92	106.54
        SPECfp92	200.36

    DEC 7000 Model 610 AXP, @182 MHz
        SPECint92	 96.58
        SPECfp92	182.11

    DEC 4000 Model 610 AXP, @160 MHz
	SPECint92	 83.51
	SPECfp92	143.10

    DEC 3000 Model 500 AXP, @150 MHz
	SPECint92	 74.30
	SPECfp92	126.0

    DEC 3000 Model 400 AXP, @133 MHz
	SPECint92	 65.32
	SPECfp92	112.2

In front of me I have  Digital Equiment Germany's announcement of the new
systems for  ``Forschung und Lehre'' (research and education).   For  one
thing it doesn't mention the first  three  models at  all.  Also it gives
the following numbers

    DEC 3000 AXP Model 500
        SPECint92        66
        SPECfp92        118

    DEC 3000 AXP Model 400
        SPECint92        59
        SPECfp92        103,5

Any idea why the numbers are smaller?  (Is it  because we are ``Forschung
und Lehre'', or is it because we are in Germany, or what? ;-)

Martin.

-- .- .-. - .. -.  .-.. --- ...- . ...  .- -. -. .. -.- .-
Martin Sch"onert,   Martin.Schoenert@Math.RWTH-Aachen.DE,  +49 241 804551
Lehrstuhl D f"ur Mathematik, Templergraben 64, RWTH, D 51 Aachen, Germany
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.arch
Subject: Re: RISC goes CISC?
Date: 12 Nov 92 00:47:54 GMT
Organization: Auspex Systems, Santa Clara

>The i860 is going down the pan, but the new chip to be used by Intel
>SSD and which will be x86-ish will have a new instruction set.

"Will be x86-ish" and "will have a new instruction set"?

Am I missing something here?  Which will it be - x86-ish, with an x86
instruction set, or not x86-ish, with a new instruction set?

>This SSD chip is due in 1996.  I wonder if it's really the Pentium?

I've heard claims of a 64-bit member of the x86 family; *if* the chip
has a new instruction set, perhaps they'll have the x86 instruction set
as the 32-bit instruction set, and some new instruction set as the
64-bit instruction set.

Doesn't sound like the Pentium, in any case.
Newsgroups: comp.arch