HDTenEightyP/NetNews huggingface dataset:
From: djaggar@armltd.uucp (Dave Jaggar)
Newsgroups: comp.arch
Subject: Re: Condition Codes and RISC arch.
Date: 8 Apr 92 09:00:04 GMT
Distribution: comp
Organization: Advanced RISC Machines Ltd

se@IKP.Uni-Koeln.DE (Stefan Esser) writes:
>In article <1992Apr4.173725.11509@vax5.cit.cornell.edu>, r4ty@vax5.cit.cornell.edu writes:
>|>   if(a==b)
>|>     c--;
>|>   else 
>|>     d+=10;
>|> 
>|> which would normally be compiled like so:
>|> 
>|>        cmp a, b
>|>        bne ELSE
>|>        dec c
>|>        bra END
>|> ELSE:  add 10, d
>|> END:   ...
>|> 
>|> would now be compiler like this:
>|> 
>|>        cmp a, b
>|>        dec.eq c
>|>        add.ne 10, d

>Hmm, does 'dec.eq c' clear the ZERO flag if 'c' comes out != 0 ???
>Then 'd+=10' would be errenously executed after decrementing 'c' ...

>... just to remind you, that conditional execution has its advantages,
>but can't be applied everywhere ...

>Some questions:

>Does the ARM processor set the flags after each instruction, or after 
>each arithmetik operation (like intel processors) or after operations 
>working on 'data' registers (like the 68k family) ?

>Is there any processor that has a general 'set condition codes' bit
>in each instruction ?
>-- 

Good questions :-) One answer.

In fact ARM has a bit in every instruction that can affect the condition
codes (ADD, ADC, SUB, SBC, RSB, RSC, MOV, MVN, CMP, CMN, TST, TEQ, AND,
ORR, EOR, BIC, MUL and MLA).  So you can write the code described above,
and it will work as expected.  Furthermore the compiler makes very good
use of this feature.  Here is a piece of C

int gcd(int a, int b) 
{
 while (a != b)
   if (a > b)
     a -= b ;
   else
     b -= a ;
 return a ;    
}

cc -S produces (some assembler support gunk removed)
	
	; note there is no stack frame
	
gcd     B       gcd3
gcd2    SUBLE   a2,a2,a1
        SUBGT   a1,a1,a2
gcd3    CMP     a1,a2
        BNE     gcd2
        MOV     pc,lr ; this is a procedure return
	
mybrain -S gives

gcd     CMP     a1,a2
        SUBLT   a2,a2,a1
        SUBGT   a1,a1,a2
        BNE     gcd
        MOV     pc,lr
	
By the way, there are 16 conditions on each instruction (4 bits) they
are : AL, NV, EQ, NE, LT, LE, GT, GE, VC, VS, CC (or LO), CS (or HS),
HI, LS, MI, PL. So you use LT, LE, GT, GE for signed compares, LO, LS,
HI, HS for unsigned ones. NV is NeVer, and is reserved. 

The CoMPare instruction above always sets the CC flags (as do CoMpare
Negative, TeST (AND) and Test EQuivalent (EOR)), others need an S
appenped to the mnemonic to alter the CC flags.
	
Fun isn't it.
Dave

--------------------------------------------------------------------------
Dave Jaggar					Advanced RISC Machines Ltd
djaggar@armltd.co.uk		 		Swaffham Bulbeck
Phone: (+44 223) 813 000 Extn 210		Cambridge CB5 0NA
Fax: (+44 223) 812 800                 		England
--------------------------------------------------------------------------
From: tolk@opal.cs.tu-berlin.de (Robert Tolksdorf)
Subject: Microcoded processors?
Organization: Techn. University of Berlin, Germany
Date: Fri, 10 Apr 1992 21:41:50 GMT

Hi there,

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

Furthermore I would be glad if someone could give me pointers to
microcode programming systems.

And as a last question: Are there any approaches that use GALs as
storage for microcode?

The reason, I am asking is my desire to investigate if micro-processor
technology could be seen or described as a reflexive system in some
sense. 

Ciao Robert



--
| Robert Tolksdorf       | Technical University Berlin | Private:         |
| +30/314-73558 (FR6078) | FB 20 - FLP - FR 6-10       | Koertestr. 30    |
| e-mail:                | Franklinstr. 28/29          | D-1000 Berlin 61 |
| tolk@cs.tu-berlin.de   | D-1000 Berlin 10 / Germany  | +30 / 694 55 97  |
Newsgroups: comp.arch
From: sef@kithrup.COM (Sean Eric Fagan)
Subject: Re: Microcoded processors?
Organization: Kithrup Enterprises, Ltd.
Date: Thu, 16 Apr 1992 21:28:59 GMT

In article <1992Apr16.204142.12420@cs.brown.edu> drb@cs.brown.edu (Dan Bornstein) writes:
>Just a little request for clarification: what's the difference
>between ALPHA's "macro-code atomic instructions" and good old-
>fashioned traps? (If this is obvious, please don't skewer me
>too bad. I'm new at this stuff.)

Nothing, as far as I can tell, except that they seem to be quicker than
"good old-fashioned traps" are (except, of course, on the 29k 8-)).

They're still useful, though.  Even if they are hyped...

-- 
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.
From: mash@mips.com (John Mashey)
Newsgroups: comp.arch
Subject: Re: R5000
Date: 10 Apr 92 20:12:08 GMT
Article-I.D.: spim.kubtkoINN3vk
Organization: MIPS Computer Systems, Inc.
NNTP-Posting-Host: winchester.mips.com

In article <1992Apr10.020017.156952@cs.cmu.edu> lindsay+@cs.cmu.edu (Donald Lindsay) writes:
>"...the company... said it has started work on an R4000 follow-on
>that would likely perform in the 200 Specmarks range. That device
>isn't scheduled to be completed until the 1995 timeframe or later,
>though.

>Until then, the highest-performance MIPS microprocessor would be the
>100 MHz R5000, which would use the underlying R4000 technology and
>thus isn't being portrayed as a full new generation. The R5000 is
>expected to be ready in late 1993 with performance of 125-150
>Specmarks, MIPS said.
.....
Note: everywhere I could, I tried to make sure that any time SPECmark
was used, it said "estimated SPECmarks" or SPECmarks*
	*estimated
or words to that effect....

so:
g/SPECmark/s//estimated &/g
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	 mash@mips.com OR {ames,decwrl,prls,pyramid}!mips!mash 
DDD:  	408-524-7015, 524-8253 or (main number) 408-720-1700
USPS:	MIPS Computer Systems M/S 5-03, 950 DeGuigne, Sunnyvale, CA 94086-3650
Newsgroups: comp.arch
From: preston@dawn.cs.rice.edu (Preston Briggs)
Subject: Re: Voice Recog. on Desktop
Organization: Rice University, Houston
Date: Fri, 10 Apr 1992 02:03:16 GMT

limes@straylight.Eng.Sun.COM (Greg Limes) writes:

>Limited speech recognition is available for the PC for well under
>two hundred bucks. Keyword recognition, and only sixteen active
>templates at a time, but it works

>Why can't we do this on our workstations? The audio is there, the
>processing power is there ...

Is there demand?
Newsgroups: comp.arch
From: dcb@kopachuk.uucp (David Breneman)
Subject: Re: chip-on-chip technology
Organization: Tacoma Screw Products, Inc.
Date: Fri, 10 Apr 1992 22:52:53 GMT

In article <1223@eouk15.abcl.co.uk> pcockere@abcl.co.uk (Pete Cockerell) writes:
>
>Actually working in America taught me all sorts of interesting things,
>like
>
>#define
>
>is pronounced `pound-define' (not `hash-define') and

This is interesting.  I had somehow thought (based, I guess, on looking 
at a Wyse keyboard) that in Britain, the "=||=" pound sign was mapped
to a Pound Sterling sign.

>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...
>
Well, that depends... What part(s) of the US were you in?  I've
heard "dash" and "minus" used interchangeably.  I was taught "minus",
myself.  I would also pronounce char as "char", and I pronounce chmod
as "ch'mod" although I've heard come people say "shmod".

On an unrealted cross-cultural note, there is a current trend in radio
advertising in the US to use Americans doing really bad John Cleese
immitations in spots when they want a "wacky British" touch.  Apparently
an announcer doing a bad John Cleese immitation is more credible as
a pitch man than one doing, say, a bad David Letterman immitation.
Bye.

-- 
David Breneman     Sys Admin, Tacoma Screw Products, Inc. |  ____  ____  ____
dcb@tacoma.uucp              | SCREWIE the TSP CLOWN sez- |   /   /___  /___/ 
 ..!uunet!stephsf!tacoma!dcb |"Stainless steel bolts are  |  /   ____/ / 
CompuServe: 75760,1232       | ferrous but non-magnetic!" |
Newsgroups: comp.arch
From: sproven@cs.strath.ac.uk (Simon B Proven IE91)
Newsgroups: comp.arch
Subject: Re: And now for something completely different...
Date: 8 Apr 92 13:34:24 GMT
Organization: Comp. Sci. Dept., Strathclyde Univ., Glasgow, Scotland.

In article <1992Apr7.203735.9015@nic.unh.edu> tch@kepler.unh.edu (Travis C Hayes) writes:
>
>The traditional shift/add and shift/subtract (for division) method seems to
>be somewhat of a time waster. Could it possibly be enhanced by adding some
>extra hardware to detect when the desired result has been achieved and thus
>avoid shifting and bit testing all the remaining high-order bits (which would
>all be zero anyway after the result was achieved)? Since in many multiplies
>one of the numbers is likely to be small (bits near the msb end not set)
>this idea would seem to save some time. Any ideas? Do any architectures do
>this?

I believe the ARM multiply instruction does this as the execution time of the
instruction varies according to the number of bits in the right hand source
operand.  The worst-case time is 17 cycles, which is whenever the rhs is
-ve.  One optimisation of a 32-by-32 to 64 bit result multiply is when
doing a 16-by-16 multiply where one of the operands may be -ve (and sign
extended to 32 bits) is:

	CMP b,#0       ; check if b -ve
	RSBMI b,b,#0   ; negative so negate both operands
	RSBMI a,a,#0   ;
        MUL   c,a,b    ; do multiply

>| Travis C. Hayes

+-- Simon "Mad@Bike" Proven ---------------------------------------------+
|- _ -  - _ -   .__o    /  <sproven@cs.strath.ac.uk> or                  |
|-  -  - _ -  _-\_<,   /   <caa650@ccsun.strath.ac.uk>                   | 
\____________(*)/'(*)_/____Real_peeps_ride_bike_:)_______________________/
From: sysmgr@king.eng.umd.edu (Doug Mohney)
Newsgroups: comp.arch
Subject: Re: Cyrix 486
Date: 8 Apr 92 14:51:02 GMT
Reply-To: sysmgr@king.eng.umd.edu
Organization: Computer Aided Design Lab, U. of Maryland College Park

In article <1992Apr7.224947.19354@cis.uab.edu>, hyatt@cis.uab.edu (Robert Hyatt) writes:
>
>Peter's right of course.  The idea is great.  it's the calling it a 486
>that sucks with two straws.  I mean, is a 486 a 486 or is it a 16bit-wide
>buss superfast 386sx....  They should have used another number... it;s
>already confusing enough.  Now, when we buy pc's for our lab, we have to
>determine if it's a "real" 486 with a big S on it's chest, or is it an
>imposter.  Much like the damn 486/DX2-50 chip..... that seems to run at
>25mhz (Tandy is shipping) and then doubles internally.  I mean, what the
>hell is it?  is it 25 or 50.  To me, buying one, it's a 25, but to Tandy's
>marketing ads, they call it a 50mhz system.  Boy is all this going to be
>fun when we go out for bids.  Think I'll go puke.

There there <pat-pat>. Let's go get our guns and shoot some marketing people
and we'll both feel better.


  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                        < --
Xref: sparky comp.arch:4777 comp.lang.lisp:1318
From: jinx@zurich.ai.mit.edu (Guillermo J. Rozas)
Newsgroups: comp.arch,comp.lang.lisp
Subject: Re: Ideas for new LISP Machines
Date: 6 Apr 92 16:04:27 GMT
Article-I.D.: chamarti.JINX.92Apr6120427
Reply-To: jinx@zurich.ai.mit.edu
Followup-To: comp.arch
Organization: M.I.T. Artificial Intelligence Lab.
In-reply-to: glew@pdx007.intel.com's message of 2 Apr 92 06:04:16 GMT

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

*     One suggestion made in comp.lang.lisp is tag bits.  But how would one
*     add tag bits to a architecture while maintaining a RISC-style?  Are
*     there any other ideas?

* By now, people are pretty good at placing tags in the upper bits of a
* pointer, and/or in the lower bits of a pointer where misaligned
* address traps can be used to do some tag checking.

* SUN has some tagged instructions in SPARC.

* One idea I've always been fond of is to provide an architectural mask,
* part of process context, that is ANDed with all virtual addresses, so
* software doesn't need to mask off the tag before addressing.
* --

There is a better hack for high-tagged pointers, namely XOR, and it
need not be part of a process context, but part of the instruction.
Loads and Stores currently have many bits of offset (typically 16),
and it would be easy to reuse some of them.

Consider two new instructions

    load-tagged		tag,offset(base),destination
    store-tagged	tag,offset(base),source

Where base, source, and destination are registers, and tag and offset
are constants.

The operation of load-tagged is equivalent to

    add		#offset,base,temp
    xor		#tag<<datum-length,temp,temp
    load	0(temp),destination

which is similar to the operation of a normal load, except for the xor
in the high bits.

Similarly for store-tagged.

The advantage of XOR over AND is that if you allocate your address
space correctly, you will get a trap when you are using the wrong type
(e.g. CAR of an ARRAY), and since the trap handler can XOR the tag
right back, it can even recover trivially what object was being
incorrectly manipulated.

Although this would be nice, support for generic arithmetic is even
more important.  The Sparc's add and subtract tagged are along the
right direction, but condition codes are considered harmful nowadays.

Consider a new pair of instructions:

    add-ok	addend,augend,condition
    sub-ok	minuend,subtrahend,condition

Where all operands are registers, and condition gets a 0 if the
operands are both fixnums and the operation does not overflow, and a 1
otherwise.  The instructions would work differently depending on where
the tags lived, but the concept works for either scheme (for high
tags, fixnums would be tagged with 0 and -1, depending on their sign).

A generic add would then become

    add-ok	addend,augend,condition
    add		addend,augend,result
    jne		condition,do_generic_case

Of course, this only improves the performance of fixnums, and not of
flonums, but it is pretty RISC-y.
From: henry@zoo.toronto.edu (Henry Spencer)
Newsgroups: comp.arch
Subject: Re: Microcoded processors?
Date: 13 Apr 92 22:36:21 GMT
Organization: U of Toronto Zoology

In article <5AQHBXFJ@cc.swarthmore.edu> gessel@cs.swarthmore.edu (Daniel Mark Abrahams-Gessel) writes:
>... if you're running out of
>a cache, it seems that a programmable microcode processor would be
>useful, the idea being to shrink your code enough to fit in the cache.
>Now I realize that shrinking can be done with subroutines, but subroutines
>have a lot of overhead as I understand it.

Not on well-designed modern machines they don't.
-- 
GCC 2.0 is to C as SVR4 is to Unix.     | Henry Spencer @ U of Toronto Zoology
                             -Dick Dunn |  henry@zoo.toronto.edu  utzoo!henry
From: tim@parcplace.com (Tim Rowledge)
Newsgroups: comp.arch
Subject: Re: Condition Codes and RISC arch.
Date: 8 Apr 92 16:00:07 GMT
Distribution: comp


You're not completely crazy - the Acorn Risc Machine (now owned/developed by
A.R.M Ltd, a joint subsidiary of Acorn, Apple & VLSI Technology, plus maybe
Sanyo) uses such a scheme.  It works very nicely indeed and provides some interesting optimization chances particularly for those small branches.
It is one of the factors that help the ARM cpus outperform most 'normal'
cpus at equivalent MHz (8MHz cacheless version is about as fast as a 20MHz 
386, 25MHz small cache version about the same as a 25MHz 486)
	Tim Rowledge->tim@parcplace.com

Newsgroups: comp.arch,comp.lang.lisp
From: henry@zoo.toronto.edu (Henry Spencer)
Subject: Re: Ideas for new LISP Machines
Date: Fri, 10 Apr 1992 23:07:37 GMT
Organization: U of Toronto Zoology

In article <GUMBY.92Apr5063926@Cygnus.COM> gumby@Cygnus.COM (David V. Wallace) writes:
>... Fortunately register windows are on their
>way out; _those_ can make lexical variables in downward funarg expensive.

Expect to live with it for a longish time.  Register windows may be out
of fashion for new designs, but the SPARC is not going to go away.
-- 
GCC 2.0 is to C as SVR4 is to Unix.     | Henry Spencer @ U of Toronto Zoology
                             -Dick Dunn |  henry@zoo.toronto.edu  utzoo!henry
Xref: sparky comp.arch:5105 comp.sys.dec:2611
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.arch,comp.sys.dec
Subject: Re: Use of "crashme"
Date: 16 Apr 92 23:29:28 GMT
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Organization: Commodore, West Chester, PA

mash@mips.com (John Mashey) writes:
>	c) Please compare the price or expected volumes for:
>		1) We've fixed the bugs that bother most people, and we've
>		not bothered to fix the myriads of odd cases (like
>		fixing ls to defend against every weird input) that are
>		there in the stands distributions.
>	vs
>		2) We've fixed *all* of those weird bugs.
>How much more money do you get for 2)?
>A: customers have voted: $0.

	You're discounting another factor, however.  There are intangible
benefits from "hardening" a piece of software in that way in buyer's and
potential buyer's minds.  If you ask them if they'll pay $1 more for a fix
to "ls -dskfjeiqKDSJF", they may _say_ no.  However, doing the fix may well
be worthwhile as an investment in your reputation.

	We have certainly found in the AmigaOs that most of those sorts of
fixes are worthwhile in the long run, and in increased peace of mind that
problems that crop up are application bugs, not OS bugs.

-- 
"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.
Newsgroups: comp.arch
From: haddad@pa.dec.com (Ramsey Haddad)
Subject: Re: Ideas for new LISP Machines
Organization: DEC Western Research Lab, Palo Alto, CA
Date: Thu, 9 Apr 92 18:10:37 GMT

In article <10156@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
>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?
>
>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?  You can decode the "something" in parallel with the register read,
but nowadays a variable length shift of a 64-bit number can take about the
same time as an ADD.  The cycle-time penalty would be fairly large --- and
not worth it.

-- 
Ramsey Haddad <haddad@decwrl.dec.com>
speaking for myself.
From: hancock@Aero.org (Melody F. Hancock)
Newsgroups: comp.arch
Subject: DASH
Date: 10 Apr 92 15:25:59 GMT
Organization: The Aerospace Corporation


I am interested in looking at some of the tech reports
for the DASH project at Stanford.  Is there an ftp'able
bibliography anywhere?  Are the tech reports available from
an ftp site as well?  

Thanks,
Melody Hancock
The Aerospace Corporation

hancock@aero.org
Newsgroups: comp.arch,comp.ai
From: smith@sctc.com (Rick Smith)
Subject: Re: Voice Recog. on Desktop
Organization: SCTC
Date: Fri, 10 Apr 1992 15:22:04 GMT

glew@pdx007.intel.com (Andy Glew) writes:

>I've seen quite usable speech recognition running on an i486(tm)/25.
>The actual speech recognition code runs on the i486; a DSP board does
>the DFT.  Pretty soon you won't need the DSP. (I'd like to see this on
>an i486DX2/66.)

I think you'll always need the DSP or the computer will have to run a
sort of "half duplex" where it either does useful work or it listens
to what you're saying. Listening will be a fulltime job.

It will also be memory intensive. As I recall, an isolated word
pattern was an 8x12 array of 16 bit numbers. That's somewhat less than
6 MB for a 30K vocabulary. And you'll want them changable so they can
adapt to individual pronunciation and inflection. So that's 6 meg of
NVRAM dedicated to speech recognition.

In an earlier post I underlined the word pattern matching as the big
problem. Are _all_ 30,000 word patterns available at all times? Does
it take special hardware to manage these 30,000 words?  I'd really
want to do parallel pattern checking to do a really big vocabulary in
real time.

I honestly have to wonder about bait-and-switch with this kind of demo
report, though. One can put on a zinger of a speech recognition demo
without really demonstrating a very large vocabulary.  Fifteen years
ago we "structured" our vocabularies to minimize the number of
patterns that we had to match.  This structuring meant that the
machine wouldn't recognize words out of context. That's a tradeoff to
increase speed and recognition accuracy for "expected" words that
reduces speed and accuracy for "unexpected" words. This makes it hard
to say arbitrary things since the computer won't be comparing the
right patterns with what you're saying.

>Usable = speaker adaptive (little need for explicit, exhausting,
>    training; adapts to the speaker as it goes), discrete speech
>    (slight pause between every word, but not enough to be really
>    annoying), large vocabulary (30,000 words) voice typewriting.

Discrete speech means - that - you - talk - like - a - computer - when
- talking - to - a - computer. That's slower than the way real people
talk, so it doesn't compete with normal dictation. There are a whole
bunch of other issues, too, concerning errors and how it "adapts to
the speaker" without doing anything damaging.

Rick.
smith@sctc.com         arden hills, minnesota
From: se@IKP.Uni-Koeln.DE (Stefan Esser)
Newsgroups: comp.arch
Subject: Re: Condition Codes and RISC arch.
Date: 6 Apr 92 19:29:40 GMT
Article-I.D.: rrz.1992Apr06.192940.169927
Distribution: comp
Organization: Institute of Nuclear Physics, University of Cologne, Germany

In article <1992Apr4.173725.11509@vax5.cit.cornell.edu>, r4ty@vax5.cit.cornell.edu writes:
|>   if(a==b)
|>     c--;
|>   else 
|>     d+=10;
|> 
|> which would normally be compiled like so:
|> 
|>        cmp a, b
|>        bne ELSE
|>        dec c
|>        bra END
|> ELSE:  add 10, d
|> END:   ...
|> 
|> would now be compiler like this:
|> 
|>        cmp a, b
|>        dec.eq c
|>        add.ne 10, d

Hmm, does 'dec.eq c' clear the ZERO flag if 'c' comes out != 0 ???
Then 'd+=10' would be errenously executed after decrementing 'c' ...

... just to remind you, that conditional execution has its advantages,
but can't be applied everywhere ...

Some questions:

Does the ARM processor set the flags after each instruction, or after 
each arithmetik operation (like intel processors) or after operations 
working on 'data' registers (like the 68k family) ?

Is there any processor that has a general 'set condition codes' bit
in each instruction ?
-- 
 Stefan Esser,  Institute of Nuclear Physics,  University of Cologne,  Germany
 se@IKP.Uni-Koeln.DE                                           [134.95.192.50]
From: rcain@netcom.com (Robert Cain)
Newsgroups: comp.arch
Subject: Re: Ideas for new LISP Machines
Date: 10 Apr 92 17:55:42 GMT
Article-I.D.: netcom.l_tjr+j.rcain
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

Yes, bit addressing *please*. It's time has come. Anybody who has coded
a TMS34010 knows how easy it is to work with.  "Bytes" make absolutely
no architectural sense as the finest resolution, they are just vestigial.

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

"There are some strings.  They're just not attached."
                                                    Victoria Roberts
Newsgroups: comp.arch,comp.sys.dec,comp.unix.sysv386,comp.unix.misc