Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Vineet Gupta <vineet.gupta1@synopsys.com>
To:     David Laight <David.Laight@ACULAB.COM>,
        'Arnd Bergmann' <arnd@arndb.de>,
        "jose.abreu@synopsys.com" <jose.abreu@synopsys.com>
CC:     "open list:SYNOPSYS ARC ARCHITECTURE" 
        <linux-snps-arc@lists.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        "alexey.brodkin@synopsys.com" <alexey.brodkin@synopsys.com>,
        Joao Pinto <joao.pinto@synopsys.com>,
        "Vitor Soares" <vitor.soares@synopsys.com>
Subject: Re: [PATCH v2] ARC: io.h: Implement reads{x}()/writes{x}()
Thread-Topic: [PATCH v2] ARC: io.h: Implement reads{x}()/writes{x}()
Thread-Index: AQHUh+/oo0RKKbidaU63fw0ncGEK7A==
Date:   Mon, 3 Dec 2018 17:31:25 +0000
Message-ID: <C2D7FE5348E1B147BCA15975FBA23075014641A923@US01WEMBX2.internal.synopsys.com>
References: <19fb2e394afcb073bbc109e432417fbbc03323f6.1543499759.git.joabreu@synopsys.com>
 <ff1e11923e92405d883474d715008c0a@AcuMS.aculab.com>
 <89122bd8-bca2-2ae1-0dd0-160abbebcace@synopsys.com>
 <d2d133e5-267c-c42a-7329-22892bbbdee4@synopsys.com>
 <CAK8P3a2U3ft3crF2SiAuc=PQdDooEUaVAN9gQDyxsxvBn5+xRw@mail.gmail.com>
 <57437493-31bb-eced-032c-1f54470b030e@synopsys.com>
 <CAK8P3a2mqEb4_F4wB1DvL5jJJobLhOg6-bW3ZDNGhvbv-_qW3A@mail.gmail.com>
 <3afe0e1bbf2d42d3bb178ec789553c28@AcuMS.aculab.com>
 <C2D7FE5348E1B147BCA15975FBA23075014641A413@US01WEMBX2.internal.synopsys.com>
 <a668562bf3cb410e90484eb0d4a436a7@AcuMS.aculab.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 12/3/18 2:10 AM, David Laight wrote:=0A=
> From: Vineet Gupta=0A=
> ...=0A=
>>> It also seems to have used a different type of loop to the=0A=
>>> other example, probably less efficient.=0A=
>>> (Not that I'm an expert on ARC opcodes.)=0A=
>> The difference is due to ISA and ensuing ARC gcc backends. ARCompact bas=
ed cores=0A=
>> don't support unaligned access and the loop there was ZOL (Zero delay lo=
op). In=0A=
>> ARCv2 based cores, the gcc backend has been tweaked to generate fewer ZO=
Ls hence=0A=
>> you see the more canonical tst and branch style loop.=0A=
> Is this another case of the hardware implementing 'hardware' loop=0A=
> instructions that execute slower than ones made of simple instructions?=
=0A=
=0A=
Not really. ZOL allow for hardware loops with no instruction/cycle overhead=
 in=0A=
general. However as micro-arches get more complicated there are newer "gizm=
os"=0A=
added to the machinery which sometimes make it harder for the compliers to=
=0A=
optimize for all the cases. ARCv2 ISA has a new DBNZ instruction (similar t=
o x86=0A=
you refer below) to implement loops and that is preferred over the ZOL.=0A=
=0A=
> The worst example has to be the x86 'loop' (dec cx and jump nz)=0A=
> instruction which is microcoded on intel cpus.=0A=
> That makes it very difficult to use the new addx instruction to=0A=
> get two dependency chains through a loop.=0A=
=0A=