HDTenEightyP/NetNews huggingface dataset:
From: meissner@osf.org (Michael Meissner)
Subject: Re: Ideas for new LISP Machines
Organization: Open Software Foundation
	<1992Apr16.200227.18221@kithrup.COM> <skt2nINN8e6@agate.berkeley.edu>
Date: 17 Apr 92 10:24:16

In article <skt2nINN8e6@agate.berkeley.edu> jbuck@forney.berkeley.edu
(Joe Buck) writes:

| In article <1992Apr16.200227.18221@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes:
| >One of the advantages of the 29k is that the traps can be in user mode, and
| >are *cheap*.  (Something like a three-cycle overhead.)  This means that you
| >don't incur a horrible penalty each time you spill some registers to memory
| >(which, of course, you might not do anyway).
| 
| Cool -- one of the things that fast user mode traps can give you are really
| fast garbage collectors, also tag bits for Lisp or Smalltalk
| implementations can be exploited in interesting ways (take an unaligned
| address trap if what you've got isn't a pointer to a cons cell, and still
| have fast code for that case).
| 
| I think it's the main feature that's missing on most RISC implementations.

While I agree, I would dearly love to be able to bypass the OS for all
sorts of traps, if you are ever going to have your machine certified
at a secure level (C2 I think), the OS has to have the ability to
audit all attempted references outside of the program's address space.
When I was doing the C compiler for the Data General MV/Eclipse
computers, this came up, because the machine originally had a reserved
user space location to point to a trap handler (if it was 0, the trap
would go to the kernel).  When it came time to make the OS C2 secure,
this came up.  Eventually the microcode was changed to always go to
the kernel, and the kernel out of the goodness of it's heart would
then check if the user space location was non-zero, and if so, invoke
the user space trap handler.  The integer/floating/debug exeception
traps were also all done in user space.  The debug trap in particular,
allowed the debugger to download code into the user program that would
check if a variable was modified, and only send an IPC to the debugger
if it was for cheap watchpoints.

--
Michael Meissner	email: meissner@osf.org		phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142

You are in a twisty little passage of standards, all conflicting.
Newsgroups: comp.arch,comp.parallel
From: Lubomir Bic <bic@cj2.ICS.UCI.EDU>
Subject: Workshops at ISCA'92 -- Australia
Organization: Clemson University
Date: 4 Apr 92 00:11:46 GMT

A series of Workshops will be held at the Architecture Symposium
(ISCA'92) this May. If you would like to attend, please contact me to
receive travel and other information.

Lubomir Bic, Workshops Chair
University of California, Irvine
bic@ics.uci.edu
(714) 856-5248


                          ISCA'92

            INFORMATION ON ARCHITECTURE WORKSHOPS

DATES

There will be three 2-day workshops and 1 one day workshop. The
dates are May 24-25, 1992.

LOCATION

All Workshops will be held on Hamilton Island (a part of the
Whitsunday Island group), which is a very popular vacation resort on
the Great Barrier Reef.


LIST OF WORKSHOPS AND ORGANIZERS

1. Dataflow Computing

Guang Gao
McGill University
514-398-4446
gao@andy.cs.mcgill.ca

Jean-Luc Gaudiot
Univeristy of Southern California
(213) 740-4484
gaudiot@usc.edu

Lubomir Bic, University of California, Irvine
(714) 856-5248
bic@ics.uci.edu


2. Future Multicomputers: Beyond Minimalist Multiprocessors?

Andrew A. Chien
University of Illinois
(217) 333-6844
achien@cs.uiuc.edu

Daniel Reed
University of Illinois
(217) 333-3807
reed@cs.uiuc.edu

Justin Rattner
Intel


3. Graphics Architectures & Algorithms

David Mizell
Boeing Computer Services
Research & Technology
(206) 865-2705
mizell@espresso.boeing.com

Fred Kitson
c/o Carmen Ramos
Hewlett Packard Labs
(415) 857-3604
ramos@hplabs.hp.com


4. Optical Computing Systems: Architectures and Algorithms

THIS WORKSHOP HAS BEEN CANCELED


5. High Performance Special-Purpose Architectures

Heiko Schroder, Univeristy of Newcastle, AUS
heiko@venus.newcastle.edu.au

David Abramson, Commonwealth Scientific and Research Organisation, AUS
davida@mel.dit.csiro.au
61 3 282 2666

---------------------------------END------------------------------------

Newsgroups: comp.arch
From: preston@dawn.cs.rice.edu (Preston Briggs)
Subject: Re: Condition Codes and RISC arch.
Organization: Rice University, Houston
Date: Tue, 7 Apr 1992 21:37:43 GMT

morris@aspen.IAG.HP.COM (Dale Morris) writes:

>  if(a==b)
>    c--;
>  else 
>    d+=10;
>
>could be coded in PA instructions without any branches, as follows:
>(for clarity, let me assume that a,b,c, and d are already in registers
>1,2,3, and 4)
>	
>	sub,<>	r1,r2,r0	; compare a and b, nullify next if not equal
>	addi	-1,r3,r3	; c <- c-1
>	sub,=	r1,r2,r0	; compare a and b, nullify next if equal
>	addi	10,r4,r4	; d <- d+10
>
>The comparison here is done with a normal subtract, and the difference is
>discarded.  Any computational instruction can be used to control
>nullification.  Any instruction can be nullified.

This seems very special-case-like to me.
It works ok here because a and b aren't modified
in the THEN clause and because you've only got 1 instruction
in the THEN and ELSE clauses and perhaps more conditions.

Looks like lots of special-cases for the compiler to catch.
Is there a general mechanism or are they handled via peephole
optimization at the last second?  Or perhaps during instruction 
scheduling?  Or at all?

I don't see how you could really manage before register allocation due
to the possibility of spill code being inserted or copy instructions
being deleted.

How often are they used in practice, say across the SPEC benchmarks,
versus ordinary conditional branches?

Preston Briggs
Newsgroups: comp.arch
From: kludge@grissom.larc.nasa.gov ( Scott Dorsey)
Subject: Re: Cyrix 486
Organization: NASA Langley Research Center And Storm Door Company
Date: Tue, 14 Apr 1992 15:06:53 GMT

In article <1992Apr13.194941.4113@crd.ge.com> davidsen@crd.ge.com (bill davidsen) writes:
>  The discussion in the rest of my posting was mainly about the DX,
>sorry I confused you. And yes, you could use that description, although
>I prefer the term "capon" for the 486SX.

I presume that a capon is just a very small canard?
--scott
From: limes@straylight.Eng.Sun.COM (Greg Limes)
Newsgroups: comp.arch
Subject: Re: Chip timing issues
Date: 10 Apr 92 01:33:11 GMT
Organization: Sun Microsystems, Inc.
NNTP-Posting-Host: straylight

In article <s1uqsINNqht@cs.widener.edu> YOUNG@tattoo.cs.widener.edu (Rob Young) writes:
>From 3 years
>ago I remember reading that the SPARC architecture uses "overlapping
>registers" as a technique.  What exactly are overlapping registers?  
>Are overlapping registers timing dependent?  

I think you are referring to the "overlapping register windows". No,
this is not timing dependent. Anyone have a good description on
tap? I work with 'em all the time, but writing coherent explanations
of this sort of thing is not my strong point ...
From: davidsen@yeti.crd.GE.COM (william E Davidsen)
Newsgroups: comp.arch
Subject: Re: Microcoded processors?
Date: 13 Apr 92 20:00:49 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

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

  It was an option on the VAX 11/780 (and at least some of the newer
models). A friend of mine did his master's thesis by implementing FFT as
a single instruction. As I recall the speedup was on the order of 20%. I
believe that at boot time the writable control store was loaded by a
PDP-11, and something tells me that it may even have some off a floppy,
because I remember getting LCS updates on floppy.

  That was a long time ago, so I can't swear that the floppy was used
every time.
-- 
	- bill davidsen (davidsen@crd.ge.com)
	GE Corp. R&D Center; Box 8; Schenectady NY 12345
By analysis of usenet source, the hardest part of C to use is the comment
From: u9dmlb@ohm.york.ac.uk (Duncan McL Barclay)
Newsgroups: comp.arch
Subject: Pipelined 6502
Date: 6 Apr 92 15:43:50 GMT
Organization: Electronics Department, University of York, UK


Thanks to all those who replied to my plea for references, I havent thanked
you by e-mail because our off-sie seems to be broken...

A couple of you wanted some more info...

(I know the 6502 has a pre-fetech stage) I have designed a six stage pipe:
  IF: instruction and opcode fetch
  ID: instruction decode unit.
  EA: resolve indexed and indirect addresses.
  DF: fetch data
  EX: alu stage, does condiion code check here too.
  WB: write back stage.

The majority of instructions are completed in one machine cycle, but some
(eg JSR/RTS) require two or more instructions to be fed from the ID stage
down the rest of the processor.

Data hazards are dealt with using stall, again generated in the ID stage.

The main crux that screws performance is that need to access memory a lot.
In each machine cycle four of the six stages MAY access memory, the way
I arbitrate this is to use a SEVEN(!) phase clock (well a counter)
and each of the required stages can use the bus if it needs to on
different phases. This aint the best way, but it does work.

Raggy
u9dmlb@ohm.york.ac.uk
Newsgroups: comp.arch
From: rcain@netcom.com (Robert Cain)
Subject: Re: Magnetic bubbles
Date: Thu, 16 Apr 92 20:40:15 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 

It was simple cost per bit.  The technology stayed alive for "hard" markets
where near absolute shock insensitivity was required.  Another place they
found a niche was very hi-rel applictions.

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

"There are some strings.  They're just not attached."
                                                    Victoria Roberts
From: p45dpmg@bigbrd.UUCP (Peter Graw)
Newsgroups: comp.arch
Subject: Re: Whence Andy?
Date: 15 Apr 92 15:19:24 GMT
Reply-To: p45dpmg@bigbrd.UUCP (Peter Graw)
Organization: Esso Chemical Canada, Agricultural Chemicals Complex

>When Andy Heller, spearhead of the IBM RS/6000 system, was politically
>offed he quit IBM and a year or so later appeared as CEO of a new company
>that, believe it or not, was named HAL.  Does anyone know what has come
>of that startup?  It was heavily funded by a major Japanese firm and
>he was real secretive about the product except that it was SparkLike.
>-- 
>Bob Cain    rcain@netcom.com   408-358-2007
>
>"There are some strings.  They're just not attached."
>                                                    Victoria Roberts

One of the latest issues (which month I'm not sure, it's at home)
of Unix World has an article on him and HAL.
-- 
-----------------------------------------------------------------------------
Peter Graw    (peter@iol.ca)
Information Management 
Esso Chemical Canada
From: chanl@bali.amd.com (Chan Lee)
Newsgroups: comp.arch
Subject: WANTED: architecture simulator
Date: 15 Apr 92 15:08:40 GMT
Distribution: usa
Organization: Advanced Micro Devices, Inc., Austin, Texas

Months ago, an article(from a university) was posted to inform that
an architecture simulator has been developed and is available for
distribution.  I thought I saved that piece but can't find it.  Is
there anyone who keeps the article or remembers what that was?
I'd appreciate any leads into that simulator offering.


Chan Lee(chanl@bali.amd.com)

Am29000 Systems Engineering
Advanced Micro Devices, MS 573
5900 E. Ben White Blvd
Austin, TX 78741
Xref: sparky comp.arch:4927 comp.lang.lisp:1363
From: gaynor@brushfire.rutgers.edu (Silver)
Newsgroups: comp.arch,comp.lang.lisp
Subject: Re: Ideas for new LISP Machines
Date: 11 Apr 92 11:17:21 GMT
Followup-To: comp.arch
Organization: Rutgers Univ., New Brunswick, N.J.

wilson@cs.utexas.edu (Paul Wilson) writes:
> I'm not sure I follow this.  A high-performance implementation (read:
> anything with an optimizing compiler) is going to have raw nonpointer values
> in registers and/or the stack anyway, because keeping everything tagged at
> all times is expensive.  Floats can be treated like any other nonpointers
> (say, a word full of ASCII characters) in that respect.

I can even see untagged cells in the heap.  Suppose an implementation ...

1.  ... plays with a static stack window, which are swapped in and out of the
    heap as the stack window underflows and overflows.  These, as you mention,
    might contain raw pointers.

2.  ... stores a reference to a referenced object's class as the first part of
    its value.  Because its tag can be inferred, I can see the tag bits being
    used, perhaps for playing various GC games.  Hmph.  Awkward.

        referential object
        [xxx11]

        object's value, location xxx00
        [yyy11]                        <----- <O> <O>  These tag bits might
        [other data of object's value]...              be able to be inferred

        object's class, location yyy00
        ...

    Hmph.  Still awkward.  Hope you get my drift.

Regards, [Ag]
From: mslater@mpr.com (Michael Slater)
Newsgroups: comp.arch
Subject: Re: 88110
Date: Wed, 15 Apr 92 09:56:22 PST
Organization: Microprocessor Report
Reply-To: mslater@mpr.com (Michael Slater)
X-Mailer: uAccess - Macintosh Release: 1.5v4


In article <1992Apr14.232340.12475@slate.mines.colorado.edu> (comp.arch), mfriedel@monolith.rmnug.org writes:
> Where can I find some extensive information on the motorola 88110 ? Ultimately  
> I would like to see the spec sheets.
> 
The 88110 is still not officially announced, so data sheets are under
NDA.  There were several papers at the recent Compcon conference that
have the most public details I've seen.

Michael Slater, Microprocessor Report              mslater@mpr.com
P.O. Box 2438, Sebastopol CA 95473  707/823-4004  fax 707/823-0504
Newsgroups: comp.arch
From: sef@kithrup.COM (Sean Eric Fagan)
Subject: Re: Ideas for new LISP Machines
Organization: Kithrup Enterprises, Ltd.
Date: Thu, 16 Apr 1992 20:02:27 GMT

In article <1034@armltd.uucp> abaum@armltd.uucp (Allen Baum) writes:
>-is it Sparc's implementation that is a bad idea, or the whole
> concept of overlapped, automatically pushed windows? For example,
> what if the overlap size was variable (i.e. you push exactly what
> you need)? Does the fixed set of globals still make this a bad
> idea?

The 29k does that.  It has 192 general-purpose registers.  Sixty-four of
them are 'global,' and are named, appropriately enough, gr64-gr127.  One
hundred twenty-eight of them are 'local' (lr0-lr127, of course 8-)).  One of
the special-purpose registers (gr0 or gr1, I forget which) points to which
register is really lr0; that is used as the base for all of the local
registers (distinguished by having the high-bit set in the register number),
and it wraps.  When entering a function, the standard calling sequence has
one compute how many local registers are needed, adjust gr0 (or gr1,
whichever it is 8-)), and trap if you need to spill.

One of the advantages of the 29k is that the traps can be in user mode, and
are *cheap*.  (Something like a three-cycle overhead.)  This means that you
don't incur a horrible penalty each time you spill some registers to memory
(which, of course, you might not do anyway).

-- 
Sean Eric Fagan  | "One form to rule them all, one form to find them, one
sef@kithrup.COM  |  form to bring them all and in the darkness rewrite the
-----------------+  hell out of them" -- sendmail ruleset 3 comment from DEC.
Any opinions expressed are my own, and generally unpopular with others.
Xref: sparky comp.arch:5115 comp.ai:2047
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.arch,comp.ai
Subject: Re: Voice Recog. on Desktop
Date: 17 Apr 92 05:48:57 GMT
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Organization: Commodore, West Chester, PA

glew@pdx007.intel.com (Andy Glew) writes:
>Finally, just think of the market in those "Press 1 to get sales" type
>phone answering systems. Wouldn't you prefer to hear "Welcome to XYZ
>corp. Do you wish to call sales or service?" and replay "sales"?
>
>Yes, I know that's speaker independent. By the way, the above system
>already exists.  I received a collect call from Canada the other day,
>where I was asked to accept the charges by a computer, I said "huh?",
>the computer repeated the question, I said "yes", and the computer
>connected the call.

	Actually, this is nothing unusual now.  The AT&T 3210 DSP supports
both trained-discrete and untrained-continuous speech recognition (larger/
faster vocabularies with trained, of course).  I understand this will be
one of the standard MML modules available for the chip.  Also, it appears
that Apple is using the 3210 from the reports about Casper (their speaker-
independant discrete large-vocabulary recognition software that they've
been showing off in unfinished form).

-- 
"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: dg@dgupta.hpl.hp.com (Dipankar Gupta)
Date: Tue, 14 Apr 1992 13:47:12 GMT
Subject: Re: Condition Codes and RISC arch.
Organization: Hewlett-Packard Laboratories, Bristol, UK
Newsgroups: comp.arch

(Preston Briggs) asks:


   >(Dale Morris) posts:
   >> 
   >>   if(a==b)
   >>     c--;
   >>   else 
   >>     d+=10;
[deleted]
   >>	
   >> 	sub,<>	r1,r2,r0	; compare a and b, nullify next if not equal
   >> 	addi	-1,r3,r3	; c <- c-1
   >> 	sub,=	r1,r2,r0	; compare a and b, nullify next if equal
   >> 	addi	10,r4,r4	; d <- d+10

   linley@hpcuhe.cup.hp.com (Linley Gwennap) writes:
   >Actually, the example can be coded in three instructions:
   >
   > 	sub,<>	r1,r2,r0	; compare a and b, nullify next if not equal
   > 	addi,tr	-1,r3,r3	; c <- c-1, always nullify next instruction
   > 	addi	10,r4,r4	; d <- d+10
   >

   Can the compiler find either of these solutions from the source code?


Compiling this :
void foo (a, b, c, d)
int a, b, c, d;

{
  if (a != b)
    c--;
  else
    d += 10;

  <Some other stuff to avoid the entire function being optimised away>
}

yields

1.       COMCLR,<>       %r26,%r31,%r0
[ nullifies the next instruction if a <> b ]


2.       ADDI,TR -1,%r25,%r25    ;offset 0x18
[ Add-immediate (c--), nullify the load always ] 


3.       LDO     10(%r24),%r24   ;offset 0x1c
[ d += 10 ]

More elegant, if anything...

Dipankar Gupta
HP Labs Bristol UK
--
--
Xref: sparky comp.arch:5044 comp.lang.lisp:1398 comp.lang.misc:1718
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Newsgroups: comp.arch,comp.lang.lisp,comp.lang.misc
Subject: Re: Ideas for new LISP Machines
Date: 15 Apr 92 14:46:10 GMT
Followup-To: comp.arch
Organization: Purdue University Statistics Department

In article <GUMBY.92Apr14021204@Cygnus.COM> gumby@Cygnus.COM (David V. Wallace) writes:

			........................

>   >                                                     (I think most
>   >   of the costs of floats are the compiler's problem, not the hardware's;
>   >   with good inlining, dataflow analysis, etc., most floats can be raw
>   >   untagged values on the stack or in registers.
>   >
>   >This makes scavenging the stack painful if you're doing realtime gc in
>   >another execution thread.

>   The easy way to do this is to partition the register set into pointer
>   registers and nonpointer registers, as is done in Yale's T compiler.

>This doesn't work on current architectures (and I apologize that I had
>forgotten that this discussion is on _future_ architectures).  The two
>problems are:
> o - on a register-poor architecture (such as the sparc) the cost of
>     untagging may still be lower than the cost of all the reloads
>     you'll have to do because you don't have enough free registers of
>     the proper type.  Judicious tag choice and bibop-ing is needed to
>     make this true, of course.
> o - You can't intercall with functions written in other languages
>     unless you inhibit the GC.

Most architectures are register-poor.  Partitioning the registers into pointer
registers and non-pointer registers, or having separate floating-point registers,
makes for problems of all kinds.  

The idea of making things easy for the compiler rather than efficient is a 
clear indication that the language/compiler combination used is bad, not
allowing a programmer to do intelligent things.  This then results in the
present approaches to making sure that the programmer does not know of the
machine capabilities, and then the machine designer leaves them out because
"nobody" uses them, etc.
                                                                                
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@pop.stat.purdue.edu (Internet, bitnet)  
{purdue,pur-ee}!pop.stat!hrubin(UUCP)
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.arch
Subject: Re: Ideas for new LISP Machines
Date: 10 Apr 92 09:47:01 GMT
Organization: Comp Sci, RMIT, Melbourne, Australia

In article <1992Apr9.181037.25520@PA.dec.com>, haddad@pa.dec.com (Ramsey Haddad) writes:
> In article <10156@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
> >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.
> 
> Why does everyone seem to be ignoring the cost of doing a variable length
> shift?

Since this was a follow-up to my posting, I'll speak for myself.
I didn't ignore the _cost_ of doing a variable-length shift, I ignored
the variable-length shift case entirely, and concentrated on [R1+R2+Offset]
only.  As Andy Glew noted, all you need is one more row of 3:2 full adders.
As Mashey noted, you also need another set of wires.  (Will optical systems
change this tradeoff (:-) (:-)?)

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