From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: Date: Mon, 14 Sep 2015 14:18:46 +0100 Message-ID: From: Charles Forsyth To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=f46d04426ca6c502a4051fb4e7f6 Subject: Re: [9fans] kenc vlong double Topicbox-Message-UUID: 6a8e7406-ead9-11e9-9d60-3106f5b1d025 --f46d04426ca6c502a4051fb4e7f6 Content-Type: text/plain; charset=UTF-8 On 14 September 2015 at 13:59, wrote: > is there any reason to handle the as single operations instead > of breaking it down into separate and operations? that is, > is (a = b) always equivalent to (a = a b)? > you then have to fuss whether the evaluation of a has side-effects, and if so, add an assignment to a temporary. it turns out that the existing code needs only a little more care about which type is used to allocate registers, and on the RISCy machines it will then work. 8c is a little more involved because of the 387's architecture. there probably won't be much code, but it's fiddly. it would be nice finally to switch to SSE but i suppose there might still be some SSE-less x86/32 processors. --f46d04426ca6c502a4051fb4e7f6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On 14 September 2015 at 13:59, <cinap_lenrek@felloff.net> wrote:
is there any reason to handle the <asop>= as single operations instead
of breaking it down into separate <as> and <op> operations? tha= t is,
is (a <op>=3D b) always equivalent to (a =3D a <op> b)?

you then have to fuss whether the evaluation of a has = side-effects, and
if so, add an assignment = to a temporary. it turns out that the existing
code needs only a little more care about which type is used to allocate=
registers, and on the RISCy machines it wi= ll then work. 8c is a little more
involved = because of the 387's architecture. there probably won't be much cod= e,
but it's fiddly. it would be nice fi= nally to switch
to SSE but i suppose there = might still be some SSE-less x86/32 processors.
--f46d04426ca6c502a4051fb4e7f6--