HDTenEightyP/NetNews huggingface dataset:
From: sdm7g@aemsun.med.Virginia.EDU (Steven D. Majewski)
Subject: Re: Microcoded processors?
Organization: University of Virginia
Date: Mon, 13 Apr 1992 21:52:55 GMT


>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??
>
In article <1992Apr13.200049.4428@crd.ge.com> davidsen@crd.ge.com (bill davidsen) writes:
>  It was an option on the VAX 11/780  ...


DEC also made a KMC-11, a microprogramable communications oriented 
processor to be used along with their serial I/O boards. 

OK - That's cheating - since it was a peripheral processor, and not the
main processor, there were no hairy problems with OS support for changing
instructions on the fly. But I suppose that was how you changed communication
protocols: download a new micro-program. 


But I wanted to re-iterate what I said in another thread ( and some other
people have also said in numerous threads ): 

RISC is "user level micro-code". 

Patterson states that it was work on compilers for Writeable Control 
Store microcode that led to some of the compiler advances that made 
RISC practical ( Patterson, CACM Vol 28 #1 )

He also says ( more or less ) that the problem of cramming a program 
into the WCS was leading to the idea of Virtual WCS. What is the difference
between a micro-coded processor with Virtual WCS and a RISC with cache 
memory ? ( very little, I think. )


Programming in micro-code entails problems of timing and synchronization
that you don't usually deal with in macro-assembler. Just like in the 
delay slots required in MIPS processors, but in the old days, you didn't
have a smart compiler to figure out how to re-order the instructions for
you. [ No - I haven't had any micro-coding experience. But I've seen some
examples, and it's not TOO different from some problems I HAVE run into on
some specialized image processing boxes: you had better have all the registers
loaded and be ready to set the go bit before the data is present on the video
bus - there is no memory to buffer it if you miss it! ] 

Some of the DSP chips also program as if they were micro-code! 

So who wants to bring back micro-code ? 

The ALPHA idea of macro-code atomic instructions looks like the best of 
both worlds: a realization of Virtual Writable Control Store. 

- Steve 

======== "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	1300 Jefferson Park Avenue
 FAX:   (804)-982-1616		Charlottesville, VA 22908

Xref: sparky comp.arch:5098 comp.ai:2040
From: rsb@mcc.com (Richard S. Brice)
Newsgroups: comp.arch,comp.ai
Subject: Re: Voice Recog. on Desktop
Summary: silly season
Date: 16 Apr 92 21:13:13 GMT
Organization: MCC, Austin, TX

In article <WAYNE.92Apr16062114@backbone.uucp>, wayne@backbone.uucp (Wayne Schlitt) writes:
> 
> sentences.  How does a system know that you have ended a sentance?
> How can it now that there is supposed to be a "?" instead of a "." at
> the end of a sentance?  In the last sentance, how would it have
> handled the double quotes?  If you had to say "double quote" every
> time you wanted a double quote, then how would you get the words
> -wayne


I know this is silly, but since the problem was solved decades ago
by Victor Borge (anyone remember him) I just had to respond.

If you haven't heard his "spoken language" monologue, you can't imagine
how hilarious all our offices would become if we adopted his solution.
Much less what it would be like to travel on an airplane filled with
people applying his approach.

Richard Brice
MCC Corp
From: umh@vax5.cit.cornell.edu
Newsgroups: comp.arch
Subject: <None>
Date: 15 Apr 92 17:52:41 EDT
Followup-To: comp.arch
Distribution: na,comp
Organization: Cornell University

In article <id.BHWO.943@ferranti.com>,
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. Prototype on a CISC machine
> cross-compiled from a RISC, and then switch to RISC for production? (yes, I'm
> kidding).
> 
> Comp.arch folks... is this a real effect or just imagination?

I would guess that 
1) It is a real effect.
2) It has nothing to do with optimization and is largely due to slow 
linking. Linking on most UNIX systems is pathetically slow. Maybe NeXT did some
work to try to speed this up, just like they (and NO-ONE else) have tried to
fix many other of UNIX' most obvious flaws.

Maynard Handley
From: jfarrell@jf.Eng.Sun.COM (Jerry Farrell)
Newsgroups: comp.arch
Subject: Re: Microcoded processors?
Date: 12 Apr 92 17:12:09 GMT
Article-I.D.: exodus.kugrr9INNc3d
Organization: Sun Microsystems, Mt. View, Ca.
NNTP-Posting-Host: jf

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

and then there was the Alto: not exactly a microprocessor (after all,
it was designed 20 years ago!), but it would dynamically swap in the
BCPL or Mesa interpreter, depending on whether you were running old
or new software, and while you were waiting for the disk to spin up,
you could net-boot Clint Parker's pinball machine, which had *its*
own ucode.  Wonderful machine.

followups should probably go to alt.folklore....
Xref: sparky comp.arch:5131 comp.ai:2054
From: kehler@endor.uucp (Andy Kehler)
Newsgroups: comp.arch,comp.ai
Subject: Re: Voice Recog. on Desktop
Date: 17 Apr 92 19:23:54 GMT
Article-I.D.: das.1992Apr17.192354.25392
Organization: Aiken Computation Lab, Harvard University

In article <id.CNYO.TU5@ferranti.com> peter@ferranti.com (Peter da Silva) writes:
>In article <1992Apr15.175943.27200@das.harvard.edu> kehler@endor.uucp (Andy Kehler) writes:
>> This may be so, but so what?  Practically speaking, how often are we
>
>< This maybe sew, butts sow watt? Practical lisp peaking, how off tenner wee
>
>> going to encounter such an intense ambiguity?  I agree that generic
>
>< go into Anne counters session tents ambiguity? I agree thought generics
>
>> speech applications will have to account for context; speech
>
>< peach chap lick cautions well half tour count fork on text; speech
>
>I dare say that in reality most of these ambiguities can be resolved,
>but if even 5% slip through dictation of text is going to be an excersize
>in frustration.
>-- 

I'm in full agreement!  You're demonstrating the difference between
recognizing a coherent text and a basically random list of words.
This is closer to the current problems with speech recognition
technology, and to the kind of tests that will ultimately reveal the
level of usefulness of systems.

In my reacting to Eugene Miya's beach/speech example, by saying
"intense ambiguity" I was referring to the phonetic similarly between
two well-constructed sentences, not between a well-constructed
sentence and a random list of words.  This is what will not happen
that often (IMHO); what you are demonstrating above will happen all of
the time.  I'm just tired of people putting down developing
technologies by applying the toughest, most concocted examples from
the outset.  This is why I said that Eugene Miya's "first test" should
be his last.  Examples like yours are more relevant; if we use the
beach/speech example to dismiss systems then we are never going to get
anywhere.

Thanks for the point.

 -- Andy K.
From: davec@nucleus.amd.com (Dave Christie)
Newsgroups: comp.arch
Subject: Re: RISC == direct execution of microcode ?? ( was: Interpreted code)
Date: 14 Apr 92 16:11:34 GMT
Reply-To: davec@nucleus.amd.com (Dave Christie)
Organization: AMD Advanced Processor Development

In article <DOCONNOR.92Apr13220728@layton.inews.intel.com> doconnor@layton.inews.intel.com (Dennis O'Connor) writes:
>
>sdm7g@aemsun.med.Virginia.EDU (Steven D. Majewski) writes:
>]
>]  The RISC philosophy has often been characterized as "User level micro-code"
>]  -  rather than building complex instructions from simple micro-code
>]  instructions, make the basic user-level instructions as fast as micro-code. 
>]  RISC *is* microcode that uses a cache of main memory instead of a limited
>]  size writable control store.
>
>I have some difficulty with this statement. The difference between a 
>RISC Instruction Set Architecture (ISA) instruction and microcode is 
>related to the difference between a computer architecture and an 
>implementation of that architecture.

Yes, microcode, unlike RISC instructions, can be tailored to a
particular implementation - it basically allows one to vary the degree 
to which an ISA is implemented in hardware vs. software (software 
being the microcode).

This can give you flexibility in meeting various cost/performance goals
over a range of implementations - a strategy that was useful in the 
mainframe and mini world of years gone by for low- and mid-range 
machines, but which I think has little merit in these days of leapfrog
high-end microprocessor development.  When you throw more into hardware,
I think any gains to be had by tailoring the microcode can be cancelled by
the cost of having the microcode (realestate, extra pipe stage).

At a more philosophical level, where computing is viewed as a collection
of primitive data movement/manipulation and branching operations, Steven's
statement is exactly correct.

------------------------------------------
Dave Christie		My opinions only.
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.arch
Subject: Re: Tagged Architectures.
Date: 9 Apr 92 17:39:33 GMT
Organization: Auspex Systems, Santa Clara

>The vertical
>microinstruction set of this machine is a typical register-memory
>architecture in many ways, but with special support for the operations that
>are needed to support the secure tagged capability architecture.

I seem to remember a claim that different models of S/38 and AS/400 have
*different* "vertical microinstruction" sets.

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....
From: doconnor@layton.inews.intel.com (Dennis O'Connor)
Newsgroups: comp.arch
Subject: RISC == direct execution of microcode ?? ( was: Interpreted code)
Date: 14 Apr 92 05:07:28 GMT
	<ktkt4iINN65g@boogie.cs.utexas.edu> <SIMON.92Apr2111448@liasg2.epfl.ch>
	<1992Apr10.155012.11523@murdoch.acc.Virginia.EDU>
Followup-To: comp.arch
Organization: /eng/eng25/doconnor/.organization
In-reply-to: sdm7g@aemsun.med.Virginia.EDU's message of 10 Apr 92 15:50:12 GMT


sdm7g@aemsun.med.Virginia.EDU (Steven D. Majewski) writes:
]
]  The RISC philosophy has often been characterized as "User level micro-code"
]  -  rather than building complex instructions from simple micro-code
]  instructions, make the basic user-level instructions as fast as micro-code. 
]  RISC *is* microcode that uses a cache of main memory instead of a limited
]  size writable control store.

I have some difficulty with this statement. The difference between a 
RISC Instruction Set Architecture (ISA) instruction and microcode is 
related to the difference between a computer architecture and an 
implementation of that architecture.

For example, I imagine the Intel i386(tm) and it's imitators have
completely different microcode, but they should have the same user-
visible architecture.

Now pure RISC machine have no microcode. But there are different
implementations of the same architecture (e.g. SPARC, MIPS R3000). If
RISC instructions were microcode, each SPARC or R3000 could have it's own
unique instruction set. But RISC instructions aren't microcode, because
they are visible to the user, which microcode generally is not.

This is perhaps a subtle distinction, but I think it's important. No would
tolerate a RISC "architecture" with incompatable implementations, I think.
--
Dennis O'Connor			doconnor@sedona.intel.com
Newsgroups: comp.arch,comp.lang.lisp
From: glew@pdx007.intel.com (Andy Glew)
Subject: Re: Ideas for new LISP Machines
Organization: Intel Corp., Hillsboro, Oregon
	<CARLTON.92Apr2164722@husc8.harvard.edu>
	<MEISSNER.92Apr3104846@tiktok.osf.org>
	<GLEW.92Apr3172834@pdx007.intel.com>
	<MEISSNER.92Apr6102821@tiktok.osf.org>
Date: Tue, 7 Apr 1992 05:20:44 GMT


    For integer constants, and stack frame addresses, I agree that signed
    offsets is generally more desirable than unsigned offsets.  However,
    for things like loading up a global/static variable, it is less
    desirable.  It forces you to add special relocations that deal with
    the sign extension of bit 16, when the address is broken into two
    instruction (load upper immediate followed by the memory instruction).
    Futhermore, it prevents (or at least hinders) splitting up these two
    instructions for scheduling purposes.

Agreed.

What a well-designed architecture would have is a signed 17 bit offset,
plus a load immediate as upper 16 bits instruction.




    Finally, with regard to global addresses, I notice that botht he R4000
    and Alpha do not deal at all well with global/static variable
    addresses being more than 32-bits.  I think that there is an implicit
    assumption that linkers won't put things above the 4G limit.

Loading >32 bit constants is necessarily problematic.

It begins to sound like the old constant pool approach will be
necessary - place the constant in memory, and load it in as needed.
Have a linker that will use an immediate if possible, otherwise add
the extra instructions to load from the constant pool.

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?

And, the really good one, which all IBM 360 programmers will know and
love?: what happens when a random pointer overwrites the constant
pool, and your constant -1 is now 0xDEADBEEF?

Nah... better make the constant pool read-only.


--

Andy Glew, glew@ichips.intel.com
Intel Corp., M/S JF1-19, 5200 NE Elam Young Pkwy, 
Hillsboro, Oregon 97124-6497

This is a private posting; it does not indicate opinions or positions
of Intel Corp.

Intel Inside (tm)
Xref: sparky comp.arch:5099 alt.folklore.computers:6556
From: Eddie.Saxe@bbs.oit.unc.edu (Eddie Saxe)
Newsgroups: comp.arch,alt.folklore.computers
Subject: Re:  chip-on-chip technology
Date: 16 Apr 92 21:55:05 GMT
Organization: Extended Bulletin Board Service

In article <liam.02qi@durie.amigans.gen.nz> liam@durie.amigans.gen.nz (Liam Greenwood) writes:
>In article <id.D1PO.B0K@ferranti.com> peter@ferranti.com (Peter da Silva) writes:
>>In article <1223@eouk15.abcl.co.uk> pcockere@abcl.co.uk (Pete Cockerell) writes:
>>> #define
>>
>>> is pronounced `pound-define' (not `hash-define')
>>
>>No, it's pronounced `number-define'. :->
>
>'hash-define' in these parts.

All these different names for it is confusing.  I say we should standardize it,
maybe get it ANSI standardized, something we can all agree upon:

`thingie-define'

 ____/|  Bill the Cat says "Vote Dave Barry | Eddie@uncvx1.bitnet alias     
 \ o.O|  for President!"  Actually, he says,| Eddie@uncvx1.oit.unc.edu      
  =(_)=  "ACK!  THPHTH!" but we're sure that| "I've changed my mind, Hobbes.
    U    he's a Dave Barry supporter.       |  People are scum."---Calvin
--
   The opinions expressed are not necessarily those of the University of
     North Carolina at Chapel Hill, the Campus Office for Information
        Technology, or the Experimental Bulletin Board Service.
           internet:  bbs.oit.unc.edu or 152.2.22.80
Newsgroups: comp.arch
From: anup@zapata.sps.mot.com (Anup Seshadri)
Subject: Hot Chips Conference
Reply-To: anup@zapata.sps.mot.com
Organization: Computerized Clinic for Superior Cynics, Synthetic City,Finite State 2112.
Date: Fri, 10 Apr 1992 02:25:46 GMT


When is it? Where is it? (I suppose at Stanford). Can someone please email some information
about it to me: anup@zapata.sps.mot.com.

Many thanks.
Anup.
From: kaiser@heron.enet.dec.com
Newsgroups: comp.arch
Subject: Re: Alpha Memory Semantics
Date: 9 Apr 92 03:56:41 GMT
Organization: European Technical Centre, Sophia-Antipolis (Valbonne)


In article <1992Mar3.201841.20457@midway.uchicago.edu>,
rtp1@quads.uchicago.edu (raymond thomas pierrehumbert) writes...

> Given that Alpha has a small onboard cache...

Small correction: at least in comp.arch you haven't read anything from
Digital about the sizes of *on-board* cache (which is a matter of system
design, not Alpha architecture), only about *on-chip* cache of the first
Alpha product chip, the 21064-AA.  You shouldn't assume anything about the
size of off-chip, on-board cache.

___Pete

kaiser@heron.enet.dec.com
+33 92.95.62.97
From: jinx@zurich.ai.mit.edu (Guillermo J. Rozas)
Newsgroups: comp.arch
Subject: Re: Interpreted code penalties (was: Re: Ideas for new LISP Machines)
Date: 11 Apr 92 14:23:31 GMT
	<SIMON.92Apr2111448@liasg2.epfl.ch>
	<1992Apr10.155012.11523@murdoch.acc.Virginia.EDU>
Reply-To: jinx@zurich.ai.mit.edu
Followup-To: comp.arch
Organization: M.I.T. Artificial Intelligence Lab.
In-reply-to: sdm7g@aemsun.med.Virginia.EDU's message of 10 Apr 92 15:50:12 GMT

In article <1992Apr10.155012.11523@murdoch.acc.Virginia.EDU> sdm7g@aemsun.med.Virginia.EDU (Steven D. Majewski) writes:

*  The other problem is: along with RISC instructions becoming the new
*  functional equivalent of micro-code, we increasingly have C becoming
*  the new functional equivalent of assembler-language. It is also partly
*  a question of economics: a lot of R&D has gone ( is going ) into optimizing
*  C-compilers. Most of those "higher-level" languages are going to be 
*  implemented in C. (1) An architectural feature that can't be expressed well
*  from C may be of limited use. (2) I'm not sure how easily and portably 
*  the Self techniques can be applied in these other cases. *IF* the software
*  solution is difficult and needs to be replicated slightly differently for 
*  each processor/language pair, then a hardware solution makes economic sense.

Unfortunately it is a very poor assembly language.
Although it has more addressing modes than current hardware, it has
very limited control constructs, and in particular, no first-class
labels, and very expensive procedure calls.

In addition, it has no support for checking integer and
floating-point computations for overflow which makes generic arithmetic
painful.  Of course, since C does not need support for detecting these
conditions, new hardware (e.g. MIPS and Alpha) do not include good
support either.

With respect to control, Scheme compilers that generate C code either
give up the requirement that the implementation be fully
tail-recursive or have to go through many expensive contortions (often
requiring the emulation of a stack and return addresses) to preserve
the expected behavior.
Xref: sparky comp.arch:5069 comp.ai:2019
From: lindsay+@cs.cmu.edu (Donald Lindsay)
Newsgroups: comp.arch,comp.ai
Subject: Re: Voice Recog. on Desktop
Date: 16 Apr 92 02:06:36 GMT
Organization: School of Computer Science, Carnegie Mellon


eugene@wilbur.nas.nasa.gov (Eugene N. Miya) writes:
>To this end I put together the RhosettaStone (nice name) benchmark test.
>I have yet to find a machine which can get pass the first test:
>	How to recognize speech.
>	How to wreck a nice beach.

A, DhryUtterance. Almost DhryWit.
-- 
Don		D.C.Lindsay 	Carnegie Mellon Computer Science
Newsgroups: comp.arch,comp.ai
From: tj@alliant.com (Tom Jaskiewicz)
Subject: Voice recognition in car
Organization: Alliant Computer Systems Corp.
Date: Thu, 16 Apr 1992 22:11:10 GMT

In article <1992Apr15.172528.30412@alliant.com> I write:
>The first company with the hardware/software to allow a driver to "write"
>memoes is going to make a lot of money.

In article <1992Apr16.193905.20286@zoo.toronto.edu> you reply:
>And cause a lot of traffic accidents.  We've already got pinheads who
>think they can shave or chatter away on a cellular phone while weaving
>through traffic.  99% of the time they're right...

I would accept a smart-car that drove itself on the smart-roadway.
Then I can use the proven keyboard/mouse/CRT technology.

Unfortunately both of these good technologies (voice recognition and
smart-cars) are many years away.

-- 
##########################################################################
# The doctrine of nonresistance against arbitrary power, and oppression is
# absurd, slavish, and destructive of the good and happiness of mankind.
#   -- Article 10, Part First, Constitution of New Hampshire
Xref: sparky comp.arch:5090 comp.ai:2039
From: tom@ssd.csd.harris.com (Tom Horsley)
Newsgroups: comp.arch,comp.ai
Subject: Re: Voice Recog. on Desktop
Date: 16 Apr 92 20:49:43 GMT
	<1992Apr15.015106.18722@ichips.intel.com>
	<1992Apr15.150519.5356@sctc.com>
	<1992Apr15.175943.27200@das.harvard.edu>
Followup-To: comp.arch
Organization: Harris Computer Systems Division
In-reply-to: kehler@endor.uucp's message of 15 Apr 92 17:59:43 GMT

How about non-realtime voice recognition? Are there systems (or will there
soon be systems) which can do something like make a transcript from a
recording?  It could take almost all the time it wanted to, it need not make
the transcript in realtime.
--
======================================================================
domain: tahorsley@csd.harris.com       USMail: Tom Horsley
  uucp: ...!uunet!hcx1!tahorsley               511 Kingbird Circle
                                               Delray Beach, FL  33444
+==== Censorship is the only form of Obscenity ======================+
|     (Wait, I forgot government tobacco subsidies...)               |
+====================================================================+
From: gaynor@brushfire.rutgers.edu (Silver)
Newsgroups: comp.arch
Subject: Re: Ideas for new LISP Machines
Date: 11 Apr 92 10:57:22 GMT
Organization: Rutgers Univ., New Brunswick, N.J.

leinen> The transition to 64bit-addressing that has just started seems like a
leinen> good opportunity to convince chip designers that this makes sense.

Deserved repeating.

leinen> 000 and 100 are the resp. typecodes for "even fixnum" and "odd fixnum"

What is the advantage over having a single nixfum tag?  Seems wasteful to this
amateur.

wilson> I think it's probably better to focus on better OS support and
wilson> software techniques than on specialized hardware.

leinen> The problem with conventional architectures is not so much that they
leinen> are missing support in form of expensive features like hardware tags

Deserved repeating.

This discussion is enlightening and interesting.  Thanks!  [Ag]

ps  Hmmm...  Maybe consider sending a (perhaps babyl-format, for convenience)
    archive of it to those objects tagged `vendor'.