HDTenEightyP/NetNews huggingface dataset:
From: peter@ferranti.com (Peter da Silva)
Subject: Re: Generic Top Secret Microprocessor Development Plan
Followup-To: comp.os.misc
Organization: Xenix Support, FICC
Date: Fri, 10 Apr 1992 15:19:40 GMT

In article <1992Apr9.210954.19624@decuac.dec.com> mjr@hussar.dco.dec.com (Marcus J. "will do TCP/IP for food" Ranum) writes:
> 	It's big: I have heard 16Mb on a 486 is a "usable" system

That's a LOT bigger than UNIX. Why is it so big? What has it got in it that
takes up all that memory? I still can't figure what System 7 and OS/2 have
that need *2* MB just to run... what's NT doing with 16 MB?

> 	Now, if someone had a multitasking, efficient operating system
> with a windows API that could run DOS applications pretty reasonably,

I could suggest one, except that the windows API isn't "MS Windows" and
the DOS isn't "MS DOS". But I've used it for 6 years.
-- 
/F{findfont exch scalefont setfont}def /S{moveto show}def /T{/Times-Roman F}def
8 T(Ferranti International Controls Corporation)24 28 S(+1 713 274 5180)24 12 S
(Sugar Land, TX  77487-5012)24 20 S 12 /Courier F(`-_-')320 32 S( 'U` )320 16 S
12 T(Peter da Silva)24 36 S 16 T(Have you hugged your wolf today?)358 24 S
From: maf@hpfcso.FC.HP.COM (Mark Forsyth)
Date: Tue, 7 Apr 1992 16:13:28 GMT
Subject: Re: Who will have the next killer micro?
Organization: Hewlett-Packard, Fort Collins, CO, USA
Newsgroups: comp.arch

In comp.arch, hyatt@cis.uab.edu (Robert Hyatt) writes:

> 
> I'm not sure where this is coming from or where it's heading.  However, to the
> best of my limited knowledge the MHZ problem is REAL.  What works at 1Mhz 
> DOES NOT work at 100Mhz due to a multitude of different RF-type problems.
> Minimal capacitance between traces has little effect at 1Mhz, but massive
> effect at 100-200Mhz.  Same for trace lengths.  I recall seing many of the
> original Cray-1 modules that had lots of "zigzags" on them to equalize trace
> lengths and/or effect delays where they were needed.
> 
I guess I never meant to imply that high speed SRAM cache designs are easy - 
they aren't - only that on a relative scale they are not an intractable
problem with modern tools.  Some solutions to the "designability" issue 
include: 1) the cache layout can be analyzed when the chip is being designed
allowing pinouts to be optimized for the board layout and chip specs to 
include PCB design rules and min/max trace lengths - the designer need only 
tune trace lengths to meet a length spec (assuming board construction and
design rules are followed),  2) actual layouts of the cache array can be 
shipped as macros with the chip,  3) a faster speed SRAM can be substituted
(at extra cost) to compensate for a less well tuned layout, 4) clock speed
can be easily reduced where performance is less critical, 5) chips and SRAMs
can be shipped together as an MCM or daughtercard.  I don't know the actual
reasons that HP is not in the microprocessor business but I suspect it is
much more business related than due to technical problems.  I agree that
the companies currently announced chips are not optimized for the general
purpose uP market.  BTW, some hardware designers here tell me that DRAM 
memory arrays are no less challenging in some respects to design.  

> I can only assume that this is a serious problem based on what the Cray-3
> guys have been fighting at 500Mhz.  Did I overlook something here?

I think that 500MHz is yet another ballgame.

> 
> -- 
> !Robert Hyatt                    Computer and Information Sciences   !
> !hyatt@cis.uab.edu               University of Alabama at Birmingham !
From: sdm7g@aemsun.med.Virginia.EDU (Steven D. Majewski)
Newsgroups: comp.arch
Subject: Instruction Path Coprocessors (was: Re: Interpreted code penalties)
Keywords: interpreters, Instruction Path Coprocessors, PIPE, RISC
Date: 10 Apr 92 17:38:09 GMT
Followup-To: comp.arch
Organization: University of Virginia

In article <1992Apr10.155012.11523@murdoch.acc.Virginia.EDU>
 I ( sdm7g@aemsun.med.Virginia.EDU - Steven D. Majewski ) write:
>
> In:
>   Eddy H. Debaere, Jan M. Van Campenhout. 
>   Interpretation and instruction path coprocessing 
>   Cambridge, Mass. : MIT Press, c1990.
> the authors describe different styles of interpreters, and various methods
> of optimization - including micro-coding the interpreter loops. They state
> that modern RISC architectures SHOULD give comparable performance to 
> microcoded interpreters - the interpreter loops are usually small enough
> to fit into cache. But that expected performance has not usually been 
> achieved because of the rather different memory reference patterns of 
> interpreted code ( often stack based, short instruction paths with lots
> of jumps, lots of indirect references, etc. )
>

Let me add that their solution is an Instruction Path Coprocessor - 
( FP & graphics chips they classify as Data Path Coprocessors ) 
which supplies the processor with a stream of instructions to execute. 
[ Maybe you could characterize it as "Intelligent Cache/prefetch"! ]

I read through the book very quickly, so perhaps these remarks are 
more inspired by their argument that a representation of it, but
it suggests to me: 

A 'functional/parallel' IPC , i.e. one that has no off-chip side effects,
and thus is able to speculatively execute branches using local ( and 
duplicated on parallel units ) registers. The main processor would 
have no BRANCH/JMP/JSR/CALL instruction as such - only an instruction
that switches among one of two instruction streams presented to it 
by the Instruction Path Coprocessor.  ( Or possibly several execution 
units also in parallel. ) 

This is perhaps only different in degree from current Superscalar 
processors with an "A-Box" ( as alpha calls it ) functional unit,
but I offer it as an unformed idea for discussion. 

I have seen a reference to the University of Wisconsin PIPE 
( Parallel Instructions and Pipelined Execution ) as a dual 
processor RISC split between address and computation. Does 
anyone have any details on that experiment ? 

 
- Steve Majewski 

======== "If you have a hammer, find a nail" - George Bush,'91  =========
 Steven D. Majewski		University of Virginia Physiology Dept.
 sdm7g@Virginia.EDU		Box 449 Health Sciences Center
 Voice: (804)-982-0831/32	1600 Jefferson Park Avenue
 FAX:   (804)-982-1616		Charlottesville, VA 22908

 
Xref: sparky comp.arch:5045 comp.ai:2004
From: ted@aps1.spa.umn.edu (Ted Stockwell)
Newsgroups: comp.arch,comp.ai
Subject: Re: Voice Recog. on Desktop
Date: 15 Apr 92 16:00:33 GMT
Article-I.D.: lynx.TED.92Apr15100033
	<1992Apr10.152204.1544@sctc.com> <1992Apr12.055723.13230@
	<KERS.92Apr13154911@cdollin.hpl.hp.com>
	<GLEW.92Apr14153132@pdx007.intel.com>
	<TOMS.92Apr14202248@pdx069.intel.com>
Organization: Univ. of Minnesota Astronomy Dept., APS Lab

In article <TOMS.92Apr14202248@pdx069.intel.com> toms@pdx069.intel.com (Tom Shott) writes:
>   Yes I expect for giving commands to my computer voice will be great. I
>   don't need to move my hands to the key board or move away from my desk.
>   Voice is the wave of the future for command interaction.

Its kind of neat when you find yourself typing text into one window and
dictating into another.  but I digress...
--
Ted Stockwell                                     U of MN, Dept. of Astronomy
ted@aps1.spa.umn.edu                          Automated Plate Scanner Project
--
Ted Stockwell                                     U of MN, Dept. of Astronomy
ted@aps1.spa.umn.edu                          Automated Plate Scanner Project
Newsgroups: comp.arch
From: jgd@csd4.csd.uwm.edu (John G Dobnick)
Subject: Re: Use of "crashme"
Originator: jgd@csd4.csd.uwm.edu
Reply-To: jgd@csd4.csd.uwm.edu
Organization: University of Wisconsin - Milwaukee
Date: Mon, 13 Apr 1992 18:31:28 GMT

From article <799@niktow.canisius.edu>, by pavlov@niktow.canisius.edu (Greg Pavlov):
> In article <00348@meph.UUCP>, gsarff@meph.UUCP (Gary Sarff) writes:
>> ........  Nea[r]ly every company that came out with a machine running unix,
>> ported the code, bugs and all, and presumably did not fix the bugs because of
>> the fear of being struck by a lightning bolt from the unix gods...
> 
>   ... or because they do not have the resources to re-fix these bugs each
>   time they receive a new port... there's enough to do in that realm 
>   already, I presume, with X, NFS, etc..

... Hmmm, I wonder....   Do these 'resellers', when they detect and/or fix
a bug, bother to report said bug to *their* supplier, so that the _originator_ 
of said bug can fix it?   Any re-sellers wish to comment on this?

-- 
John G Dobnick                          ATTnet: (414) 229-5727
Computing Services Division             INTERNET: jgd@uwm.edu
University of Wisconsin - Milwaukee     UUCP: uunet!uwm!jgd

"Knowing how things work is the basis for appreciation,
and is thus a source of civilized delight."  -- William Safire
From: yariva@GEMINI.MATH.TAU.AC.IL (Aridor Yariv)
Newsgroups: comp.arch
Subject: hardware support for Fine-grained comp.
Date: 14 Apr 92 16:15:04 GMT
Article-I.D.: aristo.1992Apr14.161504.25444
Organization: Tel-Aviv University Math and CS School, Israel




I am working on a parallel language which combines functional and object 
oriented subsets. In general the implementation is based on light-weight tasks
which as usual, causes overhead (in every processor) due to their
allocation/scheduling/context-switch.

I am looking for references on SPECIAL HARDWARE FEATURES which helps to overcome
this local overhead like : 

1. co-processors/hardware which prepare (IN PARALLEL) the next task(process) in the 
   queue for work (Make ready the relevant data in registers). 

2. Special machine instructions. 

Are there any articles on this subject ? 

Thanx for the cooperation.

	- Yariv Aridor
	  E-mail:yariva@math.tau.ac.il

paper address:

Yariv Aridor
Computer Science Dept.
Tel-Aviv university
Ramat-Aviv
Tel-Aviv 69978
ISRAEL
Newsgroups: comp.arch
From: puri@enel.ucalgary.ca (Ruchir Puri)
Subject: Re: Discreet logic info request
Date: Mon, 06 Apr 1992 18:04:24 GMT
Organization: ECE Department, U. of Calgary, Calgary, Alberta, Canada
Keywords: discreet circutry, design

In article <11957@ns-mx.uiowa.edu> bmandrsn@umaxc.weeg.uiowa.edu (Bryan M. Andersen) writes:
>
>     I'm looking for information on how the various logic gates
>are formed with discreet circuitry such a transistors, etc.  I'm
>most intested in methods which can be used for asyncronous logic,
>because I like the idea of doing the designs with asyncronous
>circuitry.  I've also thought it might be intesting to implement
>one of the current logic families like CMOS, ECL, or TTL with
>discreets if possible.
>
>     References to books, articles, etc would be best, especially
>if they include good descriptions of the basic philosophy of the
>logic designs.  Subjects to lookup would also be much appreciated.
>I like browsing through libraries.
>
>--
>Bryan M. Andersen.  <bmandrsn@umaxc.weeg.uiowa.edu>

If you are looking for transistor implementation of logic gates, then
for CMOS refer to " Weste and Eshraghian" book titled "Principles of 
CMOS VLSI Design". 

For Asynchronous implementations, refer to a recent paper in 
IEEE Journal of solid state circuits by McAuley

"Dynamic Asynchronous Logic for High-Speed CMOS systems", Anthony J. McAuley,
IEEE JSSC, Vol.27, No.3, March 1992.

You will get more references from this paper...

(Some other intersting stuff is through Cascode Voltage Switch Logic: 
 Meng, Jacobs et al.)


--Ruchir Puri
  (puri@vlsi.enel.UCalgary.CA)

 
	
Ruchir Puri                          VLSI Gp., Dept. of Elect. & Computer Engg.
puri@vlsi.enel.UCalgary.CA           The University of Calgary, CANADA - T2N1N4
                                     403-220-4870 (Dept), 403-284-5825 (Home)  

Xref: sparky comp.arch:5037 comp.sys.sun.hardware:1699
From: jw@peanuts.informatik.uni-tuebingen.de (Joerg Wedeck)
Newsgroups: comp.arch,comp.sys.sun.hardware
Subject: Caches of the Sparcstation II
Date: 15 Apr 92 09:16:01 GMT
Organization: "Lehrstuhl fuer Technische Informatik, Uni Tuebingen"


Hello,

sorry, if this should be a FAQ.

does anybody know, how large caches of a Sparcstation II are, and how
these are organized ?

please answer by mail, as i am not able to read news in the next 2 weeks.


thanks in advance,

	Joerg Wedeck

-- 
--------------------------------+-------------------------------------
Joerg Wedeck			| E-Mail: jw@peanuts.informatik\
Universitaet Tuebingen		|		.uni-tuebingen.de
Lehrstuhl fuer Techn. Informatik|
Sand 13				|
7400 Tuebingen			|
Germany				|
--------------------------------+-------------------------------------
From: renglish@cello.hpl.hp.com (Bob English)
Newsgroups: comp.arch
Subject: Re: CISC vs RISC compilers (Re: whining about "marketing" (was Re: Does every ...))
Date: 15 Apr 92 00:40:54 GMT
Distribution: na
Organization: Hewlett Packard Labs

peter@ferranti.com (Peter da Silva) writes:
> In article <1992Apr14.064325.7459@leland.Stanford.EDU> fangchin@leland.Stanford.EDU (Chin Fang) writes:
> > For some reasons, some CISC machines have very good compilation speed.  Like
> > NeXT (68040) compiles faster than SPARC 1+ on many occations.  
> 
> I would guess that the compiler doesn't have to do quite as aggressive a job
> of optimisation to produce acceptably fast code.

I suspect this has more to do with marketing than any intrinsic
difference in the compilers.  A compiler, like any other application, is
subject to performance bugs or incomplete performance tuning, so it is
difficult to generalize from the performance of individual compilers to
the intrinsic performance of compilers across an entire class of
architectures.  Since RISC vendors are more likely to compete on a
performance basis than CISC vendors, however, their compilers are more
likely to use expensive and/or complicated algorithms to squeeze the
last bit of performance out of their hardware.  SPEC, for example,
doesn't measure speed of compilation by the host compiler, just the
speed of the resulting code.

--bob--
I'm not sure I even speak for myself.
Newsgroups: comp.arch
From: wbeebe@bilver.uucp (Bill Beebe)
Subject: Re: Cyrix 486
Organization: W. J. Vermillion - Winter Park, FL
Date: Thu, 9 Apr 1992 03:00:27 GMT

In article <1992Apr6.131334.22658@cis.uab.edu> hyatt@cis.uab.edu (Robert Hyatt) writes:
>
>all the 386sx machines I have seen have a socket (that is probably not the
>right term any longer as the chips I have seen don't have "legs").  However,
>I am confused here.  The 386sx has only 24 bits worth of address lines (16mb
>real address space) as opposed to the 386dx with it's 32 bit addressing (again,
>real addressing not virtual which both are equal at).  The 486sx is not a
>pin-compatible chip to the 386sx (both Intel chips here, not AMD) as the 486sx
>is still a full 32-bit address bus chip.  Does this mean that AMD has built
>a 486-compatible chip with only a 16mb real memory addressing capability?  Seems
>foolish if they did.

1) the socket on 386sx motherboards is for the 387sx.

2) it's Cyrex, not AMD, and yes, to be pin compatible, its data and address
   bus are limited.

3) Cyrex's part is not a full 486sx implementation, since, amoung other things,
   it only has 1K of internal cache.

4) the way things are right now, it'd be cheaper to by a new motherboard than
   tear up an existing one to replace the chip.

-- 
William H. Beebe, Jr. - wbeebe@bilver.UUCP
                 UUCP - {ucf-cs,peora,uunet}!tarpit!bilver!wbeebe
                      - bilver Public Access Unix, Orlando FL
                      - (407)644-8327  2400/9600  24 hours  8N1
Xref: sparky comp.arch:4852 comp.lang.lisp:1346
From: my@laverde.nsc.com (Mike Yip)
Newsgroups: comp.arch
Subject: ATT  Hobbit RISC
Keywords: AT&T, Hobbit, RISC
Date: 15 Apr 92 01:49:35 GMT
Reply-To: my@laverde.nsc.com
Organization: National Semiconductor Corp.

I have read that AT&T plans to introduce the Hobbit RISC as
the perfect match for the handheld pen-based computers.  

WHY?  Is it because it runs at ultra-low power?  Or is it
becuase they cannot crack any other market?

---
| Michael Yip			Email: my@berlioz.nsc.com
| National Semiconductor Corp	Voice: (408) 721-5148
| 
| Of course, this is my own opinion!
Newsgroups: comp.arch
From: tarolli@tenno.boston.sgi.com (Gary Tarolli)
Subject: Re: Who will have the next killer micro?
Organization: Silicon Graphics, Inc.
Date: Wed, 8 Apr 92 17:58:49 GMT

In article <1992Apr8.163204.2361@news.arc.nasa.gov>, lamaster@viking.arc.nasa.gov (Hugh LaMaster -- RCS) writes:
|> 
|> 500 MB/sec/(8 bytes/word)/(3 Words/FLOP) = 20 MB/sec.
|> .75-.90 * 20. MB/sec = 15.6 - 18.75.  So, the back-of-envelope
|> calculation for a RAMbus-based system would put the expected
|> performance on this test at ~15-20 MFLOPS.

The 500 MB/sec is for one RAMbus chip, a workstation would probably
use 4-8 of these to get 32-64 bits per access.  Thus the total bandwidth
would be 2-4 GB/sec for a rating of 60-120 MFLOPS using 15 Mflops from
above or 80-160 MFLOPS using the 20 Mflops from above.  This is quite a
leap from todays workstations.
______________________________________________________________________________
  _____              ______           _  _	(508)562-4800  tarolli@sgi.com
 / ___  __  __         / __  __  ___ // // *	M/S DER-200
(____/ (_/_/ (_(_/    / (_/_/ (_(_/ (/_(/_/_
	       _/
From: haynes@cats.ucsc.edu (Jim Haynes)
Newsgroups: comp.arch
Subject: Re: Tagged Architectures.
Date: 9 Apr 92 05:45:57 GMT
Organization: University of California, Santa Cruz


And then there is the sad case of the Intel iapx432
-- 
haynes@cats.ucsc.edu
haynes@cats.bitnet

"Any clod can have the facts, but having opinions is an Art."
        Charles McCabe, San Francisco Chronicle
From: rhealey@digibd.com (Rob Healey)
Newsgroups: comp.arch
Subject: Re: GaAs Alpha implementation
Keywords: Alpha, Gallium Arsenide
Date: 6 Apr 92 21:25:47 GMT
Organization: Dell Computer Corporation

In article <1992Apr1.215327.6986@regina.cs.uregina.ca>, bayko@hercules.cs.uregina.ca (J. Bayko) writes:
|>     It's been said that Cray people had some involvement in the design
|> of Alpha. Even if not, Cray has apparently chosen it for their next
|> generation of massivly parallel machines.
|>     After making such a large investment in GaAs facilities for the
|> cancelled Cray-3, Cray may be using the expertise they've acquired in the
|> process for a faster version of the Alpha chip.
|> 
	
	For clearification:

	I doubt Cray Computer Corporation, CCC, who worked with GaAs and
	owns the Cray 3 would be in to big of a hurry to give all that
	information to a competitor, Cray Research Inc., CRI.

	You are mixing your Cray companys here. CRI is the one coming
	out with the Alpha based MPP and who probably had more than
	a little influence on the Alpha design, NOT CCC.

	CRI has the X & Y MP lines as well as the C90. CCC has the Cray
	3.

		-Rob
From: pcockere@abcl.co.uk (Pete Cockerell)
Newsgroups: comp.arch
Subject: Re: chip-on-chip technology
Date: 6 Apr 92 14:10:47 GMT
Reply-To: pcockere@abcl.co.uk (Pete Cockerell)
Organization: EO Computer Ltd, Cambridge, UK

In article <1992Apr3.111940.18683@doc.ic.ac.uk> pd@doc.ic.ac.uk (Philip Daniels) writes:
>
>	Re: the recent discussion about clock speeds and what is likely to be
>achieved in the near future, I thought you might be interested in the following
>article which I reproduced from a magazine called `Eureka on Campus', which is
>sponsored by various companies and distributed *FREE* around British
>Universities. It is aimed at undergraduates . Since it is free I do not think
>they will mind me reproducing this: it just adds up to more publicity for them.
>At the end of this article I include the addresses of the sponsors and the
>publishers; if you repost please do not trim this, I feel that if companies take
>the trouble to produce free literature then they should get the publicity they
>deserve.
>	Note that `Eureka' is primarily an engineering publication, not IT.
>All spelling errors are victims of my typing.
>
> (article omitted)

This is nothing to do wih the article itself, but rather to point out
to our non-British readers that `IT' stands for `Information
Technology', or, more simply, `computers'. I just mention this because
I seem to remember having a long conversation with an American the last
time I was in the States, at the end of which he said `By the way, what
does `IT' mean?' I'd only used it 20 or 30 times by then...

Actually working in America taught me all sorts of interesting things,
like

#define

is pronounced `pound-define' (not `hash-define') and

ls -l

is pronounced `el ess dash el', not `el ess minus el', which is what I
was always brought up to say. Finally

char c;

is pronounced `care see', not `char see'. Maybe it's time for an
American-British IT (sorry, I mean computing :-) dictionary...

Pete
Newsgroups: comp.arch
From: feustel@netcom.com (David Feustel)
Subject: Re: Microcoded processors?
Date: Wed, 15 Apr 92 02:25:01 GMT
Organization: DAFCO: OS/2 Software Support & Consulting

The HP 2100 had a useful writeable control store option that permitted
extension of the basic instruction set with user-defined operations.
-- 
David Feustel N9MYI, 1930 Curdes Ave, Fort Wayne, IN 46805. (219)482-9631
Republicans believe in the "carrot and stick" approach to social problems:
 	   - carrots for the rich and sticks for the poor -
From: firth@sei.cmu.edu (Robert Firth)
Newsgroups: comp.arch
Subject: Re: Ideas for new LISP Machines
Date: 10 Apr 92 19:32:24 GMT
Article-I.D.: as0c.43404
Organization: Software Engineering Institute

In article <GLEW.92Apr6212044@pdx007.intel.com> glew@pdx007.intel.com (Andy Glew) writes:

>Interesting question: what is the probability of a cache miss on a
>constant pool access?  When is it more effective to synthesize the
>constant from the I-stream using 16 bit immediates and shifts, than to
>perform a memory access to the constant pool?  How can you organize
>the constant pool so as to reduce cache misses?

You could always have one constant pool per procedure.  Yes, it implies
repetition of constants, but it avoids a cache miss, and since you use
PC-relative addressing you don't need an extra base register.  Also, you
never have to tell the hapless user at link time that she has too many
constants for your 13-bit (or whatever) offset range.

And yes, make it read-only.  That also helps with the infamous

	CALL INCREMENT(2)

that is a less than fond memory of the halcyon age.

When in this cheaper?  On a risc machine, almost always, since you can
overlap the load delay with useful work.
Xref: sparky comp.arch:4838 comp.lang.lisp:1341
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.arch,comp.lang.lisp
Subject: Re: Ideas for new LISP Machines
Date: 9 Apr 92 04:36:38 GMT
Followup-To: comp.arch
Organization: Comp Sci, RMIT, Melbourne, Australia

mash@mips.com (John Mashey) writes:

:Here's a quiz: what is fundamentally *different* about 
:	[Rb + Ri + d] or [Rb + Ri<<something + d]
:compared to the addressing modes provided by the RISCs?
:This addressing mode subsumes most of those found in RISCs (except the
:auto-modification versions), so why didn't people do it?
:
:A: the RISC addressing modes need at most an add of 2 inputs to create
:the address, and (depending on the design) may well use the standard
:ALU to generate the address.
 
:The proposed addressing mode needs to add 3 distinct inputs, which probably
:means back-to-back adds *before* the data address is available. There is
:a good chance that this could be in the critical path for many pipelined
:designs.

Cormen, Leiserson, & Rivest, in their Algorithms book, note that a 3-input
add can be reduced to a 2-input add with one extra stage.  A heck of a lot
faster than 2 back to back adds.  It could be useful for faster software
multiplies, too.

-- 
I am writing a book on debugging aimed at 1st & 2nd year CS students using
C/Modula/Pascal-like languages.  Please send suggestions (other than "you
_must_ cite "C Traps and Pitfalls") to ok@goanna.cs.rmit.oz.au
Newsgroups: comp.arch