HDTenEightyP/NetNews huggingface dataset:
From: rcain@netcom.com (Robert Cain)
Subject: Re: Microcoded processors?
Date: Tue, 14 Apr 92 07:30:33 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 

johnl@iecc.cambridge.ma.us (John R. Levine) writes:
: 
: In fact,
: the first use of floppy disks was to load the microcode in the 370/145.
: 

Right close John.  The floppy was first employed on the 370\155 and I
microcoded the first ECL floppy disk controller for that mutha. We even
had a System\370 channel interface to the controller for writing the
beasties.  You should have seen the iterations of physical designs the
venerable floppy went through until they came up with the final design.
For a while it was the floppy of the month and they were radically different
mechanical designs.  I wish they had been saved, it would be a great museum
display. "Evolution of the Floppy". Some of them were downright funny.

BTW that controller was a minimal 4 bit thingey that didn't even have an
ALU yet we made it do virtually everything a computer can do including
an alphanumeric raster display (Tektronix scope screen).  Don Hitt invented
it in '65 and it incorporated nearly every concept ultimately embodied in
the microprocessor but the level of integration. It was truly the first risc.
It had 6 instructions I think. We called it "Mini" because the term mini-
computer had not yet been coined. I wish the tech report was still available. 
It deserves a place in the history of computer architecture.

There was a purpose to its minimality.  It served as not only the floppy
controler for the microcode loader but also as the maintenance processor
and was designed so as to have the absolute smallest possible core needed
to diagnose and call out a fix for the main system.  Don is/was a genius.

Bob
-- 
Bob Cain    rcain@netcom.com   408-358-2007

"There are some strings.  They're just not attached."
                                                    Victoria Roberts
Newsgroups: comp.arch
From: zalman@adobe.com (Zalman Stern)
Subject: Re: Tagged Architectures.
Organization: Adobe Systems Incorporated
Date: Thu, 9 Apr 1992 20:53:34 GMT

In article <12383@auspex-gw.auspex.com> guy@Auspex.COM (Guy Harris)  
writes:
> I wonder how much would be involved in making a capability-architecture
> version of the POWER instruction set, and using *that* as the underlying
> instruction set of an AS/400 model, and whether that could be made
> faster than existing models....

I heard there is a company that sells an RS/6000 (POWER, whatever you like  
to call it) package that emulates a System 36. In more 'mainstream'  
terminology it pretty much provides binary compatibility. Binary  
compatibility is not precisely correct since there is a level of  
interpretation that happens on the native machines as well. This gives one  
a lot more lattitude in implementing an emulator.

The story I heard was that IBM was pretty unhappy about this product.  
(I.e. its price performance against an AS/400 was good enough that people  
might actually use it.) I don't follow that realm of the computer business  
though so this is totally second hand.

--
Zalman Stern		   zalman@adobe.com		    (415) 962 3824
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
Newsgroups: comp.arch
From: dow@nova2.stanford.edu (Keith Dow)
Subject: Re: Who will have the next killer micro?
Organization: Stanford University
Date: Mon, 6 Apr 1992 15:06:16 GMT


stuff deleted

>Keith> Sun violated a few common sense rules.
>
>Keith> 3. Design and build a good chip the first time so you don't have to do
>Keith>    again, i.e. Pinnacle.
>
>I thought Sun wanted the CPU manufacturers competing among themselves
>with many different designs and implementations.  Sun would then just
>pick the best.

It will cost over 30 million dollars to design a 64-bit Sparc.  The
supplier of the Sparc-2 chip is Cypress semiconductor.  Their gross
annual income is less than $300 million.  You can't expect them to 
spend over 10% over their revenue designing a chip!  Sun needs to 
change their business plan.

Sun also needs to hire RISC design managers with better skills than the 
ones who designed Viking.  Also, to quotes McNealy, they need to put
all their wood behind one shaft.  Thus, their next move should be for
Sun to design a 3.3volt, 64-bit, three layer metal microprocessor.  The
design speed should be 100Mhz.  The chip should be able to be used like
the R4000, i.e. in everything from multiprocessors to PCs.

>Keith> These rules were followed by HP, DEC, MIPS, IBM and Intel.  Why didn't
>Keith> Sun follow them?
>
>Because - unlike the others - Sun does not manufacture CPU's?

MIPS doesn't make CPUs either.  

Newsgroups: comp.arch
From: eugene@wilbur.nas.nasa.gov (Eugene N. Miya)
Subject: Re: Cray Soap Opera 
Keywords: Alpha, Gallium Arsenide
Organization: NAS, NASA Ames Research Center, Moffett Field, CA
Date: Wed, 8 Apr 92 05:56:55 GMT

Just passing thru.

In article <1992Apr06.174145.10353@skynet.uucp> ice@skynet.uucp (Ice) writes:
>And what of Steve Chen? Haven't heard anything about him recently.

They are out there.  They can read these posts.  They won't respond (yet).
A reader has to have a need to know then sign non-disclosure.

I don't want to know anything more (until it's time).
They will inform the world when they want.  No sense in spreading rumors.
Enough said.

--eugene miya, NASA Ames Research Center, eugene@orville.nas.nasa.gov
  Resident Cynic, Rock of Ages Home for Retired Hackers
  {uunet,mailrus,other gateways}!ames!eugene
This is the Usenet: do you expect anything other than gross generalizations?
Ref: Mathematics and Plausible Reasoning, vol. 1, G. Polya
Xref: sparky comp.arch:4899 comp.sys.intel:849 comp.benchmarks:693
From: shap@xanadu.com (Jonathan Shapiro)
Newsgroups: comp.arch,comp.sys.intel,comp.benchmarks
Subject: Re: Registerless chips
Keywords: Intel,processor,performance
Date: 10 Apr 92 07:14:49 GMT
Organization: Xanadu Operating Company

In article <1992Mar31.195253.28980@zds.com> gerry@zds.com (gerry) writes:
>The processor described above was presented in a paper by D. Ditzel; it was
>called "CRISP" for "C Reduced Instruction Set Processor".  I worked on
>prototypes of this processor, but I don't think they ever made it to product
>stage.
>
>Gerry Gleason

CRISP was licensed to Apple, who mostly completed the design of a low-power
version before deciding to use another part.  The resulting chip, known as the
hobbit, is being used in at least one of the new pen-based personal
communicator products.


Jonathan Shapiro
Newsgroups: comp.arch
From: hofmann@cs.uiuc.edu (J. Scott Hofmann)
Subject: WANTED: MC68HC11A8 chips
Originator: hofmann@suna3.cs.uiuc.edu
Reply-To: hofmann@cs.uiuc.edu (J. Scott Hofmann)
Organization: University of Illinois at Urbana-Champaign
Date: Tue, 7 Apr 1992 02:58:01 GMT

   Can someone please point me to an electronics store/mail-order house that
stocks the MC68HC11A8 microcontroller chip? Jameco (my usual place) doesn't
stock that chip.
   Please respond by email, as I am not subscribed to this group. Thanks!

                                                           Scott


-- 
-------------------------------------------------------------------------------
J. Scott Hofmann                   u2439| "Scientific Progress goes 'Boink'?"
hofmann@cs.uiuc.edu (NeXTmail accepted) |  -Hobbes
Epoch development team, UIUC            |
Newsgroups: comp.arch
From: sysmgr@king.eng.umd.edu (Doug Mohney)
Subject: Re: 88K family computers?
Date: Fri, 10 Apr 92 15:33:06 GMT
Organization: Computer Aided Design Lab, U. of Maryland College Park
Distribution: usa
Reply-To: sysmgr@king.eng.umd.edu

In article <GLEW.92Apr9212301@pdx007.intel.com>, glew@pdx007.intel.com (Andy Glew) writes:
>Motorola MCD (Micro Computer Division) makes 88K based VME boards.
[snip]

>What's this!?! An Intelloid saying nice things about Motorolan
>products?  Ah, well, nostalgia - plus, Motorola's really not in the
>running any more...
>
>:-) (Asbestos suit on)
>
>Andy Glew, glew@ichips.intel.com
>This is a private posting; it does not indicate opinions or positions
>of Intel Corp.

Another example of a Canadian with a sense of humor migrating to the United
states of America.

Good thing you aren't a marketing type, or we'd have to shoot yeu....

 
  For a country which has exported more comedians to the States than any
  other place on earth, the Canadians have very humorless grad students.
  -- >                  SYSMGR@CADLAB.ENG.UMD.EDU                        < --
Newsgroups: comp.arch
From: zrepachol@cc.curtin.edu.au
Subject: Re: Bliss
Organization: Curtin University of Technology
Date: Thu, 16 Apr 1992 17:09:28 GMT

In article <42184@as0c.sei.cmu.edu>, firth@sei.cmu.edu (Robert Firth) writes:
> In article <34609@nntpd.lkg.dec.com> pettengill@cvg.enet.dec.com () writes:
>>It was called BLISS for
>>Basic Language for Implementing System Software (or sometimes,
>>Bill (Wulf)'s Language...).

>>  Second, because
>>the compiler requires lots of machine resources, the vast majority of
>>computers in the world today can't support a BLISS compiler - keep
> 
> Here, I emphatically disagree.  Bliss was implemented on a DEC PDP-11
> with 56k bytes of main memory.  No machine in the world today is that
> small.

What? The CMU BLISS-11 I have is a cross compiller than run on a PDP-10. The
Bliss compilers are all highly optimizing and can consume *HUGE* ammounts of
memory for the internal data.

I would love to get a Bliss-11 that would run on an 11, could flush C for
good... :)

~Paul

Newsgroups: comp.arch
From: mch@regent.e-technik.tu-muenchen.dbp.de (Michael Hermann)
Newsgroups: comp.arch
Subject: Re: Cyrix 486
Date: 7 Apr 92 06:04:33 GMT

hyatt@cis.uab.edu (Robert Hyatt) writes:

>In article <mch.702540303@regent.e-technik.tu-muenchen.de> mch@regent.e-technik.tu-muenchen.dbp.de (Michael Hermann) writes:
>>
>>Has ANYONE a 386sx-board with a socket for the processor??
>> ....

>all the 386sx machines I have seen have a socket (that is probably not the

Yes, but is this socket holding the processor or is it for the FPU?

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

>-- 
>!Robert Hyatt                    Computer and Information Sciences   !
>!hyatt@cis.uab.edu               University of Alabama at Birmingham !

I think the AMD-chips are COMPLETELY compatible to the Intel-products.
Which is much harder to achieve than improving a design (like C&T with
the 38605 etc) or degrading (like Cyrix) it.

However I'd like to get some more info about the Cyrix 486.

a) Why is it called 486 if it does have some severe constraints
   like much smaller cache and also slower core?

b) How does the cache cope with external busmasters as DMA
   (which may invalidate the contents of the internal cache)
   if the processors has the pinout of a 386sx? 
   I think you would need either additional pins or some new
   type of bus-transaction for an external invalidate request.
   Both should destroy compatibility with existing designs.

c) What type is the 1K cache?
   Inst, Date, both, selectable, freezable, x-way associative?

d) Can the processor run faster bus-transactions than the 386sx when
   the external design is tailored towards the Cx468?

Michael Hermann

Xref: sparky comp.arch:5110 comp.ai:2045
From: lindsay+@cs.cmu.edu (Donald Lindsay)
Newsgroups: comp.arch,comp.ai
Subject: Re: Voice Recog. on Desktop
Date: 13 Apr 92 22:36:21 GMT
Organization: School of Computer Science, Carnegie Mellon


glew@pdx007.intel.com (Andy Glew) writes:
	[ about using a CPU, not a DSP ]

I agree that a fast CPU may not need a DSP.

>My personal opinion: speech technology is much more useable than the
>so-called "pen computers". There are applications even for the current
>primitive levels. Speech will probably ramp up quicker than pen
>computers, maybe even quicker than video on computers.

There are lots of issues here. For one, talking to your computer has
bad privacy, and isn't polite in semipublic places. I wonder if
throat mikes could help here - but this brings back encumbrance,
which we were specifically trying to eliminate. And we'd better allow
for the humorist who walks into the flight lounge and yells "Control
C"... by which I mean, noise cancelling and command confirmation.

Also, for all the press coverage, the bulk of the announced pen
products haven't shipped yet. Obviously, pens can be superior for
gestural inputs - tick marks, push buttons, writing musical notes.
Just as obviously, people handwrite slowly, particularly when the
!@#$@^ gadget is perched on their knee or wrist. It will be
interesting to see how many applications are actual wins, and how
many simply live off the low weight/cost of the smaller package.
-- 
Don		D.C.Lindsay 	Carnegie Mellon Computer Science
From: cet1@cl.cam.ac.uk (C.E. Thompson)
Newsgroups: comp.arch
Subject: Re: Condition Codes and RISC arch.
Date: 14 Apr 92 15:35:12 GMT
Reply-To: cet1@cl.cam.ac.uk (C.E. Thompson)
Distribution: comp
Organization: U of Cambridge Computer Lab, UK

In article <1992Apr6.093746.1574@lsl.co.uk>, robin@lsl.co.uk
(Robin Fairbairns) writes:
> In article <1992Apr4.213933.54194@cc.usu.edu>, ivie@cc.usu.edu
> (CP/M lives!) writes:
>> In article <1992Apr4.173725.11509@vax5.cit.cornell.edu>,
>> r4ty@vax5.cit.cornell.edu writes:
>>> Here's a question that's been puzzling me for a while.  Why don't
the latest 
>>> RISC processors (or any microprocessors) have conditional codes inbedded in
>>> every instruction?  
>> 
>> The Acorn RISC Machine does this.
> 
> Which is perfectly right: ARM architecture comes from Cambridge, where
> _everyone_ (of a certain age - like me ;-) is influenced by the
> Titan(Atlas) architecture. 
> 
> ... Which was fundamentally RISC before all of today's hype, and which 
> did indeed have this sort of operation.

The Titan(Atlas) architecture had one or two RISC-like features, but it
was most certainly not `fundamentally RISC', imho.

As regards conditional instructions: the conditional branch was just
a conditional instruction in which the target register (Ba) was the
instruction counter (B127 in main control). For any condition and value
that you could branch to, you could conditionally set the value into
any B-register. This was useful, but it is very far from the `all
instructions can be done conditionally' state of the ARM. You couldn't
do accumulator operations conditionally, for example.

Chris Thompson
JANET:    cet1@uk.ac.cam.phx
Internet: cet1@phx.cam.ac.uk
Newsgroups: comp.arch,comp.ai
From: toms@pdx069.intel.com (Tom Shott)
Subject: Re: Voice Recog. on Desktop
Organization: Intel Corp, Hillsboro, Oregon
	<1992Apr10.152204.1544@sctc.com> <1992Apr12.055723.13230@
	<KERS.92Apr13154911@cdollin.hpl.hp.com>
	<GLEW.92Apr14153132@pdx007.intel.com>
Date: Wed, 15 Apr 1992 04:22:48 GMT


I don't know, Andy, if you've ever really listened to somebody talk. The
comment made about 'um' , 'awh', 'ehhh' is true. What people write and what
people say are two very different things.

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.

For inputing large amounts of data I don't know if voice will replace a
keyboard. Maybe with training people will learn to speak like they write
but most people won't like the initial results. Given very good contex
sensitive systems under voice recognation that filters out those non words
maybe be this isn't a problem.


--
------------------------------------------------------------------------------
Tom Shott  INTeL, JF1-19, 5200 Elam Young Pkwy, 		(503) 696-4520
	   Hillsboro, OR 97124  		   	 toms@ichips.intel.com
 INTeL.. We brought you segments,432,EPROM,CISC,RISC,VLIW,EISA,DRAM,FLASH
Newsgroups: comp.arch,comp.sys.intel,comp.benchmarks
From: rcain@netcom.com (Robert Cain)
Subject: Re: Registerless chips
Date: Fri, 10 Apr 92 05:15:25 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 

gerry@zds.com (gerry) writes:
: In article <1992Mar21.230612.14566@uwm.edu> markh@csd4.csd.uwm.edu (Mark William Hopkins) writes:
: >I'm looking for a processor with the following description:
: 
: >     * There are no on-chip software-accessible registers.
: >     * All addressing is immediate, memory-direct, (indexed) memory-indirect.
: >     * In place of registers, there is an on-chip cache and paging unit,
: >       which functions in a manner transparent to the software.
: 

This sounds a lot like a Transputer.
-- 
Bob Cain    rcain@netcom.com   408-358-2007

"There are some strings.  They're just not attached."
                                                    Victoria Roberts
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.arch
Subject: Re: Tagged Architectures.
Date: 9 Apr 92 17:36:57 GMT
Organization: Auspex Systems, Santa Clara

>And then there is the sad case of the Intel iapx432

But it wasn't a tagged architecture....

(Yes, I'm serious.)
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.arch
Subject: Re: Who will have the next killer micro?
Date: 16 Apr 92 21:17:14 GMT
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Organization: Commodore, West Chester, PA

linley@hpcuhe.cup.hp.com (Linley Gwennap) writes:
>Peak MFLOPS may not be an important number, but remember that the
>500 MB/sec for RAMBUS is also a peak number.  The thing that would
>kill the performance of a CPU using only a RAMBUS cache is the delay
>while waiting for the first word of data.  

	If RAMBus comes into use I would expect BTC's (branch target caches)
to become very popular very fast (they seem to be gaining in popularity
anyways).  Also, with long latency and high bandwidth I would expect some
combination of longer data cache lines and/or more sophisticated data caching
strategies to become popular.  (I've mentioned some of these data caching
ideas, which date back to the RPM-40, here before.)

	High bandwidth is great for instructions, but a lot of data accesses
are not sequential (or even close).  The longer the latency for data, regard-
less of bandwidth, the more important the data caching (and pre-fetching!)
strategy is.

-- 
"Thus spake the Master Ninjei: If your application does not run correctly,
do not blame the operating system." - The Zen of Programming
-
Randell Jesup, Jack-of-quite-a-few-trades, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com  BIX: rjesup  
Disclaimer: Nothing I say is anything other than my personal opinion.
From: pshuang@athena.mit.edu (Ping-Shun Huang)
Newsgroups: comp.arch
Subject: Re: Microcoded processors?
Date: 12 Apr 92 06:00:09 GMT
Organization: Massachusetts Institute of Technology

In article <1992Apr10.214150.5525@cs.tu-berlin.de> tolk@opal.cs.tu-berlin.de (Robert Tolksdorf) writes:

 > are there or have there been microcoded microprocessors on which the
 > microprogram could be changed during runtime thus changing the
 > semantics of assembly-code??

I recall an article in Byte magazine about four years back about a CPU
with similar characteristics (the only specifics I remember were that
this made emulating other CPU's relatively cheap, i.e. taking somewhat
less than the usual order of magnitude hit in performance). I believe
the article included the acronym "WISC" for Writeable Instruction Set,
so you might wish to search any indices for Byte magazine using that.
The article may have a biography that would be useful, in addition to
describing that particular implementation.

--
Above text where applicable is (c) Copyleft 1991, all rights deserved by:
UNIX:/etc/ping instantiated (Ping Huang) [INTERNET: pshuang@athena.mit.edu]
From: borasky@ogicse.ogi.edu (M. Edward Borasky)
Newsgroups: comp.arch
Subject: Re: Microcoded processors?
Date: 13 Apr 92 14:56:03 GMT
Article-I.D.: ogicse.36204
Organization: Oregon Graduate Institute (formerly OGC), Beaverton, OR

>In article <1992Apr10.214150.5525@cs.tu-berlin.de> tolk@opal.cs.tu-berlin.de (Robert Tolksdorf) writes:
> > are there or have there been microcoded microprocessors on which the
> > microprogram could be changed during runtime thus changing the
> > semantics of assembly-code??
This idea was implemented at least once in the 1960s.  I forget the
name of the vendor but they built a microprogrammed machine that could 
emulate the popular 36-bit machines of the day -- IBM 7040/7090, UNIVAC 
1106/1108, etc.  I believe someone more recently built a chip-slice
machine (AMD parts, I think) that emulated either a PDP-11 or Intel
8086, depending on the microcode.

Then, there's FPS.  The FPS-164 was a machine that was programmed in
FORTRAN; a full FORTRAN compiler translated this program to microcode
which was executed.
From: shap@xanadu.com (Jonathan Shapiro)
Newsgroups: comp.arch
Subject: Re: chip-on-chip technology
Date: 13 Apr 92 16:04:26 GMT
Organization: Xanadu Operating Company

In article <1992Apr3.111940.18683@doc.ic.ac.uk> pd@doc.ic.ac.uk (Philip Daniels) writes:
>	The only snag with multi-chip modules, is the need to make electrical
>connections between chips and substrate. Wire bonding is the currently favoured
>method, with TAB or flip chip (using solder or gold alloy bumps) as
>alternatives. The ultimate assembly method will undoubtedly be to put active
>chips upside down on circuit chips, connecting them together using z axis
>adhesives.

As near as I can tell, flip-chip (solder bump technology) has pretty much
won this battle.  Several foundaries are already doing it, and several
others are coming on line in the next six months.

>	At present, silicon-on-silicon multi-chip modules are mainly used
>military aircraft. They are compact and the use of identical materials for
>device and substrate eliminates cracking problems which might otherwise arise
>from thermal cycling. Both DEC and IBM, however, are said to be beginning to
>use the modules in high performance workstations.

I'm pretty sure that the IBM RS/6000 was a multichip implementation.
A number of companies are known to be working on flip-chip based parts to be
delivered at various times in 1993, but since they haven't announced yet
I'm reluctant to name names.

Chip-on-chip has two serious advantages over chip-on-<anything else>.  When
the modules heat up, the rate of expansion on the substrate is the same as
the rate of expansion on the chips (they're all silicon), so the bond
between the two isn't stressed.  This means you can put more chips in a
module with chip-on-chip than with, say, chip-on-tape, and you can run them
at faster clock speeds (power dissipation, a.k.a. heat, is as the square of
the frequency).

In addition, the coupling between the chip and the substrate is better,
because there isn't a change in resistance at the boundary between the
chip and the substrate.

Note that a properly done chip-on-chip implementation in .5 micron CMOS
will outperform any GaAS implementation I'm aware of, and the discrepancy
is likely to grow over time because of the rules determining speedup in the
two technologies as you decrease the chip area.

I'm far from a chip expert, though.  John Mashey might want to comment on
some of this.

Jonathan Shapiro
Newsgroups: comp.arch