Path: ...!2.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Stefan Monnier <monnier@iro.umontreal.ca>
Newsgroups: comp.arch
Subject: Re: Byte Addressability And Beyond
Date: Thu, 30 May 2024 13:45:41 -0400
Organization: A noiseless patient Spider
Lines: 32
Message-ID: <jwvttifrysb.fsf-monnier+comp.arch@gnu.org>
References: <v0s17o$2okf4$2@dont-email.me> <v31c4r$3u28v$1@dont-email.me>
	<v327n3$1use$1@gal.iecc.com> <BM25O.40665$HBac.4762@fx15.iad>
	<v32lpv$1u25$1@gal.iecc.com> <v33bqg$9cst$11@dont-email.me>
	<v34v62$ln01$1@dont-email.me> <v36bva$10k3v$2@dont-email.me>
	<2024May29.090435@mips.complang.tuwien.ac.at>
	<v38opv$1gsj2$3@dont-email.me> <v38rkd$1ha8a$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Thu, 30 May 2024 19:45:45 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="5521c538e80ffe7fc4dc42f3582f3b0d";
	logging-data="1894947"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/5NtOzUTs8g0ZfR2fY6srA4d3dD0SVNG0="
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:evzvnPxo/O10yDbIqlRFBn2qGCM=
	sha1:sPJGXRyUgjB9UHHmPLruc1ODt5M=
Bytes: 2788

> 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, ...).

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.

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.


        Stefan