From: mash@mash.engr.sgi.com (John R. Mashey)
Newsgroups: comp.arch,comp.lang.forth
Subject: Re: stack machine characteristics
Date: 25 Mar 1997 06:50:36 GMT

In article <abaum-2003971946280001@terrapin.pa.dec.com>,
abaum@pa.dec.com (Allen J. Baum) writes:

|> Both ARM (and recently, MIPS) have come up with 16 bit subsets of their
|> instructions sets that increase code density much more significanly
|> than 10%. The Thumb variation of ARM increases code density by 25-33%
|> (which is already the densest of the RISCS).
|> 
|> All instructions are subsets of the 32 bit variations. While the code
|> density increases, the number of instructions also increases, up about
|> 15%, as I recall. So, this is a fairly classic speed/size tradeoff.

If you start with a 32-bit-intruction RISC, and do like MIPS-16 does,
i.e., have a mode in which the instruction stream supports 16-bit
versions that are expanded back to the normal 32-bit ones ....

the ISA is *still* much more of a RISC than a CISC, at least according to
that classification analysis posted and reposted here.
While decompression adds a cycle, note that simple ones like this
are far away from having multiple prefixes, or VAX-style long instructions;
one finds resemblance with S/360, or with IBM's RT/PC (which had short
isntructions since it had no I-cache).

Adding simple-compressed versions of RISC instructions doesn't make it
a CISC, although it might move it closer to the border where it gets
harder to describe simply.  AS I said in the old post:

General comment: this may sound weird, but in the long term, it might
be easier to deal with a really complicated bunch of instruction
formats, than with a complex set of addressing modes, because at least
the former is more amenable to pre-decoding into a cache of
decoded instructions that can be pipelined reasonably, whereas the pipeline
on the latter can get very tricky."

-- 
-john mashey    DISCLAIMER: <generic disclaimer: I speak for me only...>
EMAIL:  mash@sgi.com  DDD:    415-933-3090	FAX: 415-967-8496
USPS:   Silicon Graphics/Cray Research 6L-005,
2011 N. Shoreline Blvd, Mountain View, CA 94043-1389

From: mash@mash.engr.sgi.com (John R. Mashey)
Newsgroups: comp.arch,comp.lang.forth
Subject: Re: stack machine characteristics
Date: 27 Mar 1997 02:41:26 GMT

In article <5h7sjs$15i@murrow.corp.sgi.com>, mash@mash.engr.sgi.com (John R. Mashey) writes:

|> While decompression adds a cycle, note that simple ones like this
				   ^in the first implementation
may or may not be intrinsic to the technique, as various folks
have pointed out.

-- 
-john mashey    DISCLAIMER: <generic disclaimer: I speak for me only...>
EMAIL:  mash@sgi.com  DDD:    415-933-3090	FAX: 415-967-8496
USPS:   Silicon Graphics/Cray Research 6L-005,
2011 N. Shoreline Blvd, Mountain View, CA 94043-1389

From: mash@mash.engr.sgi.com (John R. Mashey)
Newsgroups: comp.arch,comp.lang.forth
Subject: Re: stack machine characteristics
Date: 25 Mar 1997 06:54:37 GMT

Oops, more on compressed code: note that MIPS16 tries to have it both
ways: you can compiled either way and mix them in modules,
so that you can compile dense code for most of it, and
less-dense, but faster code, for critical functions.

-- 
-john mashey    DISCLAIMER: <generic disclaimer: I speak for me only...>
EMAIL:  mash@sgi.com  DDD:    415-933-3090	FAX: 415-967-8496
USPS:   Silicon Graphics/Cray Research 6L-005,
2011 N. Shoreline Blvd, Mountain View, CA 94043-1389