HDTenEightyP/NetNews huggingface dataset:
From: nickh@CS.CMU.EDU (Nick Haines)
Subject: Re: integer/BCD/... dollars (was IEEE used for Dollars and Cents)
Originator: nickh@VOILA.VENARI.CS.CMU.EDU
Organization: School of Computer Science, Carnegie Mellon University
Date: Mon, 9 Nov 1992 19:33:06 GMT

But of course nobody is actually going to be representing the national
debt using 64-bit arithmetic (as if someone in Washington runs the
federal budget on Lotus 1-2-3 :->). We're talking about the
balance-sheets of actual companies, which are probably an order of
magnitude smaller even for really big conglomerates (anyone got any
numbers?). Trillions do occur in such financial calculations,
especially when trading in countries like Italy or Bolivia (where you
don't reserve those three places for mills), but not very often.
Besides which, they are generally down at the bottom line of the
ledger (where the mills have disappeared; they are used for
intermediate results).  In fact, none of the financial software I
wrote or used in Britain saved more than two places past the pennies
(for percentage totalling calculations: calculate a line-item
percentage, total line-by-line, and calculate a total percentage
separately; if you haven't kept those digits the totals disagree. But
the total value of the transaction is a whole number of pennies).

Nick "if a cent is $0.01, shouldn't a mill be $0.001?" Haines
nickh@cmu.edu

Xref: sparky comp.arch:10567 comp.graphics:11663
From: klee@wsl.dec.com (Ken Lee)
Newsgroups: comp.arch,comp.graphics
Subject: Re: Early use of XOR to show motion
Keywords: XOR Raster
Date: 10 Nov 92 00:41:44 GMT
Reply-To: klee@wsl.dec.com
Organization: DEC Western Software Laboratory

|> Does anyone have any early (pre 1974) references to the
|> use of XOR (Exclusive-OR) to display "alternate images"
|> (i.e. make it look like one image is moving over another)?

I take it you're trying to fight the infamous XOR patent.
You might try Richard Stallman's group, who seems to have
done a bit of research into this.

-- 
Ken Lee
DEC Western Software Laboratory, Palo Alto, Calif.
Internet: klee@wsl.dec.com
uucp: uunet!decwrl!klee
Newsgroups: comp.arch
From: mo@gizmo.bellcore.com (Michael O'Dell)
Subject: Re: RTX and SC32
Keywords: 
 
Reply-To: mo@bellcore.com
Organization: Center for Chaotic Repeatabilty
Date: Fri, 6 Nov 92 13:17:17 GMT

"Stacks always go in memory, and you always go to the stack."

Well, if you wanted a damning case against very fast stack machines,
i can't imagine a better one than that.

The simple reality is that processors get faster much more quickly than
affordable memory components, hence the only way you can feed this new
generation of blisteringly-quick processors (regardless of the
architectural fru-fru) is to build a complex  memory system (read this as
EXPENSIVE by comparison to simple minis and workstations).  The only way
you can go fast is to avoid touching deathly-slow memories, and when you
do, you gotta hack like hell to go as fast as possible.  That's why fast
RISC machines gotta be surrounded by  (or contain) instruction caches with
burst-fill (or something morally similar), and why they gotta have very
clever data caches with all kinds of nifty tricks like out-of-order
completion allowed, and/or deep write-buffer queues with associative
bypass for fast back-filling, and such.  If you touch memory, you lose,
pure and simple. There is no way an Alpha instruction pipeline (to pick
one at random) can go *LOTS* faster than an R2000 instruction pipe if it
is forced to touch 80ns dynamic memory chips with the same frequency and
with the same available memory bandwidth, ie, without a sophisticated
memory subsystem in between somewhere.

What does this have to do with Stack Machines?? LOTS.  The biggest
performance kicker in the Burroughs 7800 (come 7900) was
the introduction of a largish (for the time and available technology)
asynchronous stack-top cache.  It helped performance dramatically.
So, fast stack machines can play the memory system game - get
themselves large stack-top caches and good instruction caches.
(but don't forget what huge cache contexts do to context switch
time and how fast the machine runs at one MIPS after a switch while
the cache cold-starts).  But the what happened to the simplicity,
cheapness, and low transitor count?

And more importantly, does it really go as fast???

What I have not seen in the literature (which doesn't mean it doesn't
exist, just that i haven't seen it) is a comparison of a stack machine
design with the equivalent complexity budget of modern RISC machines
to such modern processors.  By complexity budget I mean one that spends
as much logic on cache and memory system complexity as the fast RISC
machines do.   (including the related trickle-down complexity like
dealing with out-of-order completion in the pipe, if required)

Note that we may have an interesting data point in this discussion:
the Hobbit may be close enough to this last model to be interesting.
We'll have to wait and see.

	-Mike O'Dell

Bellcore?? Bellcore isn't allowed opinions. Any found here are mine.
Newsgroups: comp.arch
From: Nick_Janow@mindlink.bc.ca (Nick Janow)
Subject: Re: What's wrong with stack machines?
Organization: MIND LINK! - British Columbia, Canada
Date: Fri, 6 Nov 1992 05:44:19 GMT

lindsay+@cs.cmu.edu (Donald Lindsay) writes:

> Surely typical stack-language programs can be mechanically transformed
> (recompiled) into non-stack forms.

Sure, and you can emulate a 486 on a 6502; it just doesn't run as fast.
Stack-oriented programs tend to have a lot of subroutine calls.  This would
bog down a non-stack processor.  There are other programming techniques that
run fast on a stack machine, but not on a non-stack one.  I don't think you
can mechanically transform that stack program to one that runs efficiently on
a non-stack processor.  Stack-oriented programs are structurally different
from non-stack programs.

> As far as I can tell, the only win for stack machines is code density when
> speed doesn't matter.

Stack machines tend to be smaller and simpler than the typical processors
coming out these days (486, Alpha, SPARC, etc), without compromising speed.
Looking at it the other way, for the same amount of silicon and engineering
effort, the stack machine would probably be a lot faster.

Code density does affect speed in many cases.  If you only have 8Kbytes of
high-speed RAM, wouldn't you like to be able to stick much of the program in
that space?  Stack machines are optimized for code re-use.

A processor with multiple stacks is probably easier to design for parallel
operations than one with a large array of random access registers.  The RTX,
for example, allows simultaneous access (one clock cycle) to both stacks,
memory, and two I/O ports.  Future processors might add a floating point
stack, a string stack, a logic (IF, WHILE, etc) stack, a locals stack, or any
other specialized stack that was appropriate.  Memory access could be split
into data and instruction.  Parallel processing ports could be added.  Note
that present stack processors offer high performance without pipelining or
memory caching.

Processor design has mainly focused on optimizing for non-stack languages;
there's a lot to explore in stack processor hardware and software design.

--

Nick_Janow@mindlink.bc.ca
Newsgroups: comp.arch
From: NetCmmnd@boole.uucp (System Administrator)
Subject: Re: MIPS and MHz
Keywords: RISC, MIPS, cps
Organization: Boole & Babbage, Inc.
Date: Fri, 13 Nov 1992 19:13:41 GMT

In <BxMn1J.GB3.2@cs.cmu.edu> lindsay+@cs.cmu.edu (Donald Lindsay) writes:

>NetCmmnd@boole.uucp (System Administrator) writes:
>>How can a non-superscalar implementation at 50MHz run 59.1 MIPS?
>>I thought the holy grail of RISC was 1 instruction retired per cycle
>>and that this is never attained (much less exceeded) in a non-
>>superscalar implementation.

>Correct, for reasonable measures of MIPS.

>However, "Dhrystone 1.1 MIPS" have ceased to be reasonable.  The
>"MIPS" is calculated by assuming that the VAX 11/780 was 1 MIPS, and
>then taking an execution-time ratio versus a historical VAX value.

>As compilers have improved (and have acquired Dhrystone-1.1-specific
>optimizations), the D-MIPS ratings have inflated beyond reason.
>-- 
>Don		D.C.Lindsay 	Carnegie Mellon Computer Science

Not only that but the 11/780 was a .5 MIPS machine
and NOWHERE IN THE STUFF from Sun that I saw was there
any mention of "Dhrystone MIPS" or what they are or 
how they are calculated.  

John Ahlstrom
Boole & Babbage

I can neither confirm nor deny that
these opinions are held by anyone elsee
Newsgroups: comp.arch
Subject: Re: IEEE used for Dollars and Cents
From: don@zl2tnm.gen.nz (Don Stokes)
Date: 7 Nov 92 11:00:54 GMT
Distribution: world
Organization: The Wolery

keith@ksmith.uucp (Keith Smith) writes:
> In article <1917307@zl2tnm.gen.nz> don@zl2tnm.gen.nz (Don Stokes) writes:
> >Machines that can handle 64 bit integers cleanly will make this problem
> >largely go away.  8-)
> 
> A pretty darn big assumption that you only need 2 or 3 decimal places of
> precision in a financial calculation.  We have some 4 decimal place
> multiplication here.

I did say "largely".  You can get yourself screwed up with BCD or decimal
character datatypes too -- I have fond memories of the fun and games when
a customer of a bureau I was working for started putting through >$10M 
transactions, and the system dropped the 10th digit (dollar amounts were
represented by ascii representations of an integer number of cents).  But
I digress.

A signed 64 bit integer gives nearly 19 digits of precision.  A four decimal
place multiplication of a dollar amount (thinking of them as integral
numbers of cents makes this easier) will only lose four of those digits 
before you divide the result by 10,000 to bring it back to a cent value 
again.  That still leaves you with dollar values of up to
$9,223,372,036,854.77.  

The "other" approach to the problem of datatypes that are too small is to
use floating point but keep to integer values.  The peril there of course
is that you silently lose digits if the value exceeds the precision of the
mantissa.

128 bit integers, anyone?

> Why doesen't someone build a bcd or bcddouble type INTO the 'C' compiler
> with a higher order than float.  Numbers could be 8 or 16 bytes, 2 bytes
> of sign/exponent, and eith 7 or 15 bytes of mantissa, (14 or 30
> *DECIMAL* as in BASE 10 places of precision).

Possibly because they feel, as I do, that C isn't the language to write
"business" applications in.  But a bit of extended precision support in the
language wouldn't go amis.  (He says having just written code _full_ of 64 
bit arithmetic on a 32 bit machine to cope with monthly network traffic
values in bytes....) 

Extended precision fixed point would be a reasonable compromise, and could
be made to run quite a bit faster than decimal on current hardware.

While I'm ranting:  Bricks to DEC for putting 64 bit integer support in the
Alpha C compiler only, and making the "same" datatype 32 bits on "compatible"
MIPS platforms.  Jeez!  Extended precision isn't _that_ hard.  Sure, it'll
run a little slower than a native datatype and operations won't be atomic,
but surely documenting this fact (or not treating programmers as idiots) is
a better way?

--
Don Stokes, ZL2TNM (DS555)                        don@zl2tnm.gen.nz (home)
Network Manager, Computing Services Centre            don@vuw.ac.nz (work)
Victoria University of Wellington, New Zealand              +64-4-495-5052
From: doconnor@sedona.intel.com (Dennis O'Connor)
Newsgroups: comp.arch
Subject: Re: RTX and SC32
Date: 5 Nov 92 08:54:08
Organization: Intel i960(tm) Architecture
	<ADAMS.92Nov5001909@PDV2.pdv3.fmr.maschinenbau.th-darmstadt.de>
NNTP-Posting-Host: potato.intel.com
In-reply-to: adams@pdv3.fmr.maschinenbau.th-darmstadt.de's message of Thu, 5 Nov 1992 00:19:09 GMT


adams@pdv3.fmr.maschinenbau.th-darmstadt.de (Adams) writes:
] The FRP1600 does a 16x16 multiply in one cycle (100ns--80ns--66ns).
]
] A 10MHz FRP1600 does 16x16bit multiply at least 5 times faster than
] a 33MHz AMD29000. 

The Intel i960(R) CA microprocessor does a 32x32->32 bit multiply in
4 or 5 cycles, depending on the data. It does the multiply in
a separate on-chip subunit, so succeediing instruction execution
can proceed (barring an interlock) in parrallel with the multiply.
The i960 CA is available in a 33 MHz speed grade, leading to
a 32-bit multiply time of 120 to 150 ns. A 32x32->64 bit mul takes 
4-6 cycles ( 120 to 180 ns ).

And remember, it takes 4 16x16 multiplies and 3 32-bit adds
( minimum ) to do a 32x32 bit multiply. How long does that
take on the FRP1600 ?

Some older RISC architectures didn't implement fast multiply
at first but added it in later products. There's no causal
relationship between architectural class ( RISC, CISC, Stack, VLIW )
and multiply speed.

] This example was not dedicated to any particular advantage of stack
] machines, but to an area RISC chips did tend to loose.

The i960 CA RISC (mainly) microprocessor has been around for years.
You didn't compare to the right RISC chip.

] For realtime and controller applications, FORTH chips and stack machines
] may blow RISCs out of the water, yes, they run much faster....

The i960 family has delivered over 1 million units into embedded
and control applications. In typical Intel fashion, I tend to
measure an arhcitectures success by the revenue it generates ...
after all, the silicon itself is only one peice of the solution.
--
Dennis O'Connor			doconnor@sedona.intel.com
Newsgroups: comp.arch,comp.lang.forth
From: braker@ennex1.eng.utsa.edu (Jim Brakefield)
Subject: Re: What's wrong with stack machines?
Keywords: register allocation, stack cache
Organization: Univ of Texas at San Antonio
Date: Fri, 6 Nov 1992 18:23:26 GMT

In article <1992Nov6.094639.28441@email.tuwien.ac.at>  
anton@mips.complang.tuwien.ac.at (Anton Martin Ertl) writes:
> |> The problem is that there hasn't been enough work done on stack  
languages.
> 
> Or on stack machines.
> 
There is a perspective on RISC/register based architectures and CISC  
and/or stack based machines.  It is: when and how do you do register
allocation.  On a RISC machine the compiler does it.  On a stack machine
the hardware does it on-the-fly, i.e., a particular data value or variable
gets allocated to a specific hardware register during execution.  Thus 
the debate reduces to something similar to the virtual memory debate of
10 years ago: Is hardware memory management efficient enough to displace
programmer memory management?  (notice the context for virtual memory
debate was ram <-> disk I/O, for stack machines it is registers <-> ram
I/O).

James C. Brakefield
braker@ennex1.eng.utsa.edu
signal space >> address space >> symbol space
From: ijp@doc.ic.ac.uk (Ian Palmer)
Newsgroups: comp.arch
Subject: Re: SPA: pixie for Sparc architecture
Date: 5 Nov 1992 10:22:21 -0000
Organization: Department of Computing, Imperial College, University of London, UK.
NNTP-Posting-Host: oak43.doc.ic.ac.uk

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 ? Someone previously mentioned that the above program
  is available from solbourne.solbourne.com in /pub/uploads/from.larry but
  I could find that in the above mentioned directory. For your information,
  SPA is a program similar to pixie on R-x000-based systems.

I think it keeps moving around :-)

It is 'currently' available at :  june.cs.washington.edu in /pub/ai

Ian

-- 
                            E-mail : ijp@doc.ic.ac.uk
 ___           __       Snail mail : Department of Computing, Huxley Building,
  /  _   _    /_/ _   / _ _   _  _   Imperial College, 180 Queens Gate,
_/_ (_|_| )  /   (_|_(_| ) )_|/_)    London. SW7 2BZ. England.
From: gbs@kolob.mti.sgi.com (Greg Shippen)
Newsgroups: comp.arch
Subject: Re: News Release - Pentium - "INTEL UNVEILS NAME FOR ITS FIFTH GENERATION COMPATIBLE MICROPROCESSOR"
Date: 11 Nov 1992 01:38:03 GMT
Organization: Silicon Graphics Computer Systems, Inc.
Distribution: world
Reply-To: gbs@mti.sgi.com
NNTP-Posting-Host: kolob.mti.sgi.com

In article <1dpc7mINN1l5@almaak.usc.edu>, ajayshah@almaak.usc.edu (Ajay Shah) writes:
> davidsen@ariel.crd.GE.COM (william E Davidsen) writes:
> 
> >  What Intel marketing is doing is dangling the product just out of
> >reach to discourage major users from scraping DOS and Intel and going to
> >a reasonable workstation to get affordable performance. Just as IBM
> 
> IMHO the sickest case of "dangling a nonexistent product" is Windows
> NT.  It's how Microsoft manages to flog revenues out of the dead
> horses of DOS and Windows.  Apparently even OS/2 is a "better OS" than
> Microsoft's offerings, whatever that means.
> 

Well, I'm not sure what exactly you mean by "dangling a nonexistant product".
I have Windows NT running in Beta form on MIPS hardware on the screen next 
to the one I'm writing this on.  It runs and it runs well.  Anybody can buy
the Beta version today for $69 by calling Microsoft.  

I'm not sure how you define nonexistence but I define it as:

1.  I can't buy the software now.

2.  If I can buy it, it won't run very long (if at all) on real
    hardware I can buy today.

3.  I can't do real application development.

None of these nonexistance clauses are true of NT...

-- 
Gregory B. Shippen
Silicon Graphics Inc./MIPS Technology Inc.			gbs@mti.sgi.com
2011 N. Shoreline Blvd. M/S 10L-175                      
Mountain View, CA  94039 (415) 390-4483
Newsgroups: comp.arch
From: sysmgr@king.eng.umd.edu (Doug Mohney)
Subject: Re: DEC Alpha AXP System Performance
Date: Thu, 12 Nov 92 15:34:39 GMT
Organization: Computer Aided Design Lab, U. of Maryland College Park
Reply-To: sysmgr@king.eng.umd.edu

In article <1992Nov12.133126.13079@linus.mitre.org>, bs@gauss.mitre.org (Robert D. Silverman) writes:
>In article <1992Nov10.211153.5992@ryn.mro4.dec.com> bhandarkar@wrksys.enet.dec.com (Dileep Bhandarkar) writes:
>:> 
>:>	- how much do these machines cost? What's the SPEC/$?
>:
>:DEC 3000 Model 400 AXP starts at $15K
>:DEC 3000 Model 500 AXP starts at $39K
>:DEC 4000 AXP starts at about $70K
>:DEC 7000 AXP starts at about $150K
>:DEC 10000 AXP starts at about $300K
>:
>These prices are ridiculous. There are nowhere close to being competitive
>with what is being offerred by Sun or HP.
> 
>108 Specs for $15K??  Why would anyone want one?

Huh? *slightly befuddled look* 

Let's see, for around $10K list, you had the VAXstation 4000/90, which clocks
at around 24-30 SPEC. If I'm not mistaken, (going way, way wayyyyy out on a limb
here, listening to the wood creek) the high end DECstation runs at 30-32 SPEC,
costs about the same, list ($10Kish). 

Now, for $5K more (*handwave broadly*), you get roughly 3-4x the performance
(plus a box to keep your room warmer in winter) over both VAX and DEC hardware.

If you have an application wedded to VMS which is CPU intensive, AXP systems
are on the shopping list for Christmas. 

I would HOPE you can swap daughterboards to crank performance. I really wish
DEC hadn't gone with the funky clock-speed ranges for "product differentation",
but I suspect it's a marketing decision to recoup their investment rather than
"Slay the All Bastards Outright." 

I'm surprise the HP marketing shills haven't come out yet. Give 'em a day.


                 Play in the intelluctual sandbox of Usenet 

  -- >                  SYSMGR@CADLAB.ENG.UMD.EDU                        < --
Newsgroups: comp.arch,comp.lang.misc
From: bhandarkar@wrksys.enet.dec.com (Dileep Bhandarkar)
Subject: More Alpha AXP Performance Numbers
Organization: Digital Equipment Corporation
Date: 10 NOV 92 15:44:40    

This is in response to e-mail requests for more benchmark data.

    Alpha AXP OpenVMS (version 1.0) SYSTEMS PERFORMANCE DATA 

 |---------------------------------------------------------------------------|
 |METRIC              | 3000/400  | 3000/500 |   4000   | 7000      | 10000  |
 |====================|===========|==========|==========|===========|========|
 |SPECint89           |   65.8    |   73.5   |   83.7   |   95.1    | 104.5  |
 |SPECfp89            |  150.6    |  169.9   |  188.4   |  244.2    | 268.6  |
 |SPECmark89          |  108.1    |  121.5   |  136.2   |  167.4    | 184.1  |
 |--------------------|------------------------------------------------------|
 |SPECint92           |   65.3    |   74.3   |   83.5   |   96.6    | 106.5  |
 |SPECfp92            |  112.2    |  126.0   |  143.1   |  182.1    | 200.4  |
 |--------------------|------------------------------------------------------|
 |Dhrystone(DMIPS)V1.1|  129.9    |  146.7   |  158.8   |  177.3    | 194.5  |
 |--------------------|------------------------------------------------------|
 |Linpack 100x100     |   26.4    |   30.2   |   36.3   |   38.6    |  42.5  |
 |       1000x1000    |   70.8    |   79.9   |   86.4   |  102.1    | 111.6  |
 |--------------------|------------------------------------------------------|
 |Perfect BM Suite    |   18.1    |   20.4   |   22.9   |   26.0    |  28.6  |
 | Mflops(Geom. Mean) |           |          |          |           |        |
 |--------------------|------------------------------------------------------|
 |DN&R Labs           |           |          |          |           |        |
 |CPU2    (MVUPS)     |  159.1    |  179.7   |  193.2   |  217.9    | 239.3  |
 |--------------------|------------------------------------------------------|
 |Livermore Loop Mflop|   18.7    |   21.3   |   22.9   |   25.6    |  28.1  |
 |--------------------|------------------------------------------------------|
Newsgroups: comp.arch
From: preston@miranda.cs.rice.edu (Preston Briggs)
Subject: Re: RTX and SC32
Organization: Rice University, Houston
Date: Thu, 5 Nov 1992 17:23:47 GMT

cliffc@rice.edu (Cliff Click) writes:

>I try to compare a popular RISC (Sparc) to a hypothetical Forth machine,

>An 8 bit opcode can reference the top 16 stack elements, so 32 bits can
>do a "push r1", "push r2", "op", "pop r3" - basically imitate a 3-address
>instruction.  And I've seen the chip which can do all 4 in 1 50Mhz cycle
>(really it was a 200Mhz internal clock).  No Viking technology here, it was
>under 33,000 transistors.

I keep seeing stack machine proponents bragging about small numbers of
transistors.  Aren't most of the forth chips 16 bits (or 21 or
whatever)?  With no FP.  And no support for virtual memory?
Fine for embedded systems, nut you have to remember the greater
functionality offered by the large transistor counts of a workstation
CPU.

Now about clock rates.  A 50 MHz external clock, accomplishing 50 M
3 address equivalents.  That's 1/4 of a 200 MHz Alpha, right?

About pipelining...
What are you going to do when you have to do FP?
Spend several cycles per FP-ADD or pipeline?

Preston Briggs
Xref: sparky comp.arch:10582 comp.lang.misc:3570