Path: ...!news-out.netnews.com!s1-1.netnews.com!feeder.usenetexpress.com!tr3.iad1.usenetexpress.com!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: anton@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.arch
Subject: Re: architectural goals, Byte Addressability And Beyond
Date: Thu, 30 May 2024 12:27:17 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 64
Message-ID: <2024May30.142717@mips.complang.tuwien.ac.at>
References: <v0s17o$2okf4$2@dont-email.me> <v36bva$10k3v$2@dont-email.me> <2024May29.090435@mips.complang.tuwien.ac.at> <v38opv$1gsj2$3@dont-email.me> <v38riq$1aqo$1@gal.iecc.com>
Injection-Date: Thu, 30 May 2024 14:47:17 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="46db1f935b2b8b941d470a80861909b8"; logging-data="1792926"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+w8xx5GyG/NsnOvJMhNi2B"
Cancel-Lock: sha1:Qm2+iwsyohK3xJTqI+6kOCUfHes=
X-newsreader: xrn 10.11
Bytes: 4007

John Levine <johnl@taugh.com> writes:
>According to Lawrence D'Oliveiro  <ldo@nz.invalid>:
>>On Wed, 29 May 2024 07:04:35 GMT, Anton Ertl wrote:
>>
>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>
>>>>Isn’t the point of RISC that these complex operations are
>>>>more efficiently performed by a sequence of simpler instructions?
>>> 
>>> The IBM z series are not RISCs.
>>
>>Doesn’t matter. The principles of designing high-performance architectures 
>>still apply: simpler instructions are better than more complex ones.
>
>Nobody buys a mainframe just for its compute speed. 
>
>I do not entirely understand why IBM keeps adding special purpose
>instructions to z. Maybe it's partly marketing, but they have a
>largely captive audience so it has to be more than that.

It's still marketing.  I have listened to several talks about
converting S/360 programs to C code that can be run on arbitrary
hardware, and IBM's audience hears about such things, too, so IBM's
sales force has to provide reasons for not jumping ship.  And all
these new features that sound like they are useful are such reasons.
Things like decimal FP and CU14.

The fact that these feature provide no actual benefit is their best
property: When Intel and ARM evaluate whether they should implement
these features in their architectures, they find that the benefits of
these features do not justify their costs, so they refrain from adding
them to their architectures, preserving the marketing value of the
feature to IBM.

>Given the
>millicode design, a lot of the instructions are basically microcoded
>subroutines that may well run faster than the normal code equivalent
>because the have access to more machine state.

Maybe IBM adds a microarchitectural stream buffer to allow efficient
implementation of CU14, but I doubt it.  The marketing value of CU14
is there whether there is such a stream buffer or not, so why go to
the expense.  If they already have such a stream buffer for other
features, they might as well use it, though.

Maybe they internally do the SIMDified RISCy variant I outlined, and
then have a microcode loop.  The SIMDified RISCy variant should be
cheap enough to implement.

Or maybe they just have a microcode routine that does what a C program
would do.  In that case there is no performance benefit to having a
separate instruction, but the marketing benefit is still there.

>If you want something that gives you more MIPS/$, IBM is happy to sell
>you POWER systems.

If you want something that gives you more MIPS (as well as more
MIPS/$), lots of companies will be happy to sell you gear with AMD or
Intel CPUs.

- anton
-- 
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
  Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>