Re: Byte Addressability And Beyond

Stefan Monnier wrote:

IBM has, for a long time, combined commonly occuring sequences of
instructions into single instructions.  I don't know the tradeoffs
here.

I don't know either, but it's hard to believe that it's *just*
marketing
because there is an actual design and implementation cost involved and
even marketing needs some "hard" data to make a good sell.

My guess is that they have gotten their implementation to a point where
adding instructions is fairly painless (plenty of space in the
instruction encoding, pre-existing micro/milli-code setup where the
size of the micro/milli-code has a negligible impact on cycle time,
chip size, and yield, ...).

Yes, as long as the new instruction is "like" other already existing
instructions.

Then they use that flexibility to go after specific benchmarks they got
from some important customers.  Even if it speeds up the code of
a single customer, it might be worth the effort if it's a large enough
customer and it increases the chances of keeping them on
that architecture.

Maybe each of those cases could be solved about as efficiently by
rewriting part of the code, but we're talking about a market where many
of the customers are here specifically because they don't want to
rewrite their code.

A lot of the added instructions support OS-like features--I infer that
many of these require some kind of atomic activities not easily
achieved
with the existing ISA itself.

For the case in point, I haven't seen problems where a UTF-32 encoding
is the overall best solution, but I can easily believe that there are
cases where some poorly thought out (but entrenched) API ends up
imposing (directly or not) the use of UTF-32 and makes UTF-8 <-> UTF-32
conversions very frequent.

30 years ago you could say the same thing about encryption.

        Stefan