X-Received: by 2002:a05:620a:15a3:: with SMTP id f3mr4271518qkk.410.1573674380251;
        Wed, 13 Nov 2019 11:46:20 -0800 (PST)
X-Received: by 2002:aca:110f:: with SMTP id 15mr281682oir.47.1573674380009;
 Wed, 13 Nov 2019 11:46:20 -0800 (PST)
Path: ...!j16no6750085qtl.0!news-out.google.com!p4ni557qtu.1!nntp.google.com!j16no6750080qtl.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Wed, 13 Nov 2019 11:46:19 -0800 (PST)
In-Reply-To: <69fed6e2-4de8-46ee-b133-ed80de32c270@googlegroups.com>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=104.59.204.55;
 posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 104.59.204.55
References: <21dc5d86-4298-40c0-863f-27e65df4237f@googlegroups.com>
 <0e5905c0-14ef-4135-808d-0b1f092d3bb7@googlegroups.com> <qq74k2$3jl$1@dont-email.me>
 <57009c28-2f8b-4aeb-9255-fda49dfbd780@googlegroups.com> <49b35cb4-b226-4c8a-8bed-61583f7cabf2@googlegroups.com>
 <69fed6e2-4de8-46ee-b133-ed80de32c270@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <863dd999-bd97-49eb-977e-b70e9afed2d1@googlegroups.com>
Subject: Re: Tradeoffs in ISA design
From: MitchAlsup <MitchAlsup@aol.com>
Injection-Date: Wed, 13 Nov 2019 19:46:20 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Bytes: 4824
Lines: 85

On Wednesday, November 13, 2019 at 12:51:33 PM UTC-6, Paul A. Clayton wrote=
:
> On Saturday, November 9, 2019 at 6:36:46 PM UTC-5, MitchAlsup wrote:
> > On Saturday, November 9, 2019 at 5:05:07 PM UTC-6, Bruce Hoult wrote:
> [snip]
> >> - reusing one of the operands as the destination
> >=20
> > Several CISC machines recognize::
> >=20
> >      MOV    R5,R7
> >      OP     R5,R3
> > as:
> >      OP     R5,R7,R3
> >=20
> > But, still, to me this seems to be a step backward.
>=20
> Including two address *and* three address forms, even=20
> though redundant, can result in better code density.
> =20
> >> - making an operand or destination implicit (i.e. fixed)
> >=20
> > <Shivering> I just don't know what to say.......
>=20
> Making the destination of a less common operation=20
> fixed (function call is a common example) seems=20
> unlikely to cause major headaches for the compiler.
> (Function calls are a somewhat special case because=20
> ABIs typically constrain register allocation at=20
> function boundaries. I think I would prefer function=20
> specific interfaces as adding such to linking and=20
> debug information would not seem to be a big deal.=20
> I doubt this would be a significant benefit =E2=80=94=20
> possibly converting abstractions like this pointer=20
> to values =E2=80=94 but I believe in the principle of=20
> don't put off to runtime what can be done at=20
> compile time (when such does not introduce excessive=20
> communication overhead).)
> =20
> >> - giving a smaller choice of registers
> >=20
> > <Shivering>
>=20
> In many cases, it seems that having fewer source=20
> options would have little impact. If an operation=20
> is less common, such restrictions would not seem=20
> to be especially burdensome. Yes, the compiler=20
> would be more complicated, but that is mainly a=20
> one-time cost.
>=20
> >> - giving a smaller choice of addressing modes
> >=20
> > Since I only have 2, this bothers me little.
>=20
> Your addressing modes are typically supersets of=20
> the desired modes. I.e., other modes are special=20
> cases of existing modes.
Which is why I can get away with having only 2.....
> =20
> [snip]
> =20
> >> The assembly-language programmer (or compiler) writes=20
> >> code for the full size instruction set and the assembler=20
> >> (and/or linker) selects the smaller encoding when it can.
> >=20
> > Much preferable to having the compiler perform the choice.
>=20
> If the compiler and assembler are integrated, the difference=20
> may not be significant.

In Mc 88K days, we had the linker choose the small forms and
had the compiler/assembler express in the larger form. The
reason is that when one shrinks the code one has a linear=20
problem in optimization, whereas when one expands the code
one has an NP-complete problem in optimization.

>=20
> For certain embedded systems where code storage is a=20
> major cost, sacrificing performance-oriented (or even=20
> energy-efficiency-oriented) ISA design in favor of=20
> code density may be justified. One issue seems to be=20
> that people want one interface to meet all possible=20
> uses. While considering commonalities often helps=20
> improve even localized optimizations and provides=20
> economies of scale, specialization does have actual=20
> value.