On Mon, Mar 27, 2017 at 10:11 PM, Honnappa Nagarahalli < [email protected]> wrote:
> On 27 March 2017 at 08:36, Ola Liljedahl <[email protected]> wrote: > > On 27 March 2017 at 07:58, Honnappa Nagarahalli > > <[email protected]> wrote: > >> My answers inline. I was confused as hell just a month back :) > >> > >> On 23 March 2017 at 06:28, Francois Ozog <[email protected]> > wrote: > >> > >>> The more I dig the less I understand ;-) > >>> > >>> Let me ask a few questions: > >>> > >>> - in the future, when selling 32 bit silicon, which architecture > version > >>> will it be ARMv7 or ARMv8 ? > > AFAIK, future 32-bit ARM cores (from ARM) will be ARMv8. But people > > are still building SoC's with e.g. ARM920 which is ARMv4T or > > something. > > > >>> > >> > >> What you are referring to is ISA version, not architecture. AArch32 and > >> AArch64 are architectures. ARMv8 also supports AArch32 (i.e. AArch32 > with > >> ARMv8 ISA) > > ARMv8 has two architectural states, AArch32 and AArch64. An ARMv8 > > implementation can implement either-or or both. There are already > > examples out there of all these different combinations. > > > > AAarch32 supports the A32 and T32 ISA's, these are closely related to > > (basically extensions of) the corresponding ARMv7a ARM and Thumb(-2) > > ISA's. > > The A32 (and T32?) ISA's have some of the ARMv8 extensions, e.g. > > load-acquire, store-release, crypto instructions, simplified WFE > > support etc. > > A user space ARMv7a image should run unmodified on ARMv8/AArch32, I > > don't know about other privilege levels but I can imagine an ARMv7a > > kernel running in AArch32 with an AArch64 hypervisor. > > > > AArch64 supports the A64 ISA. This ISA actually supports both 32-bit > > and 64-bit operations (although all addresses are 64-bit AFAIK). > > 32-bit operations use Wn registers and 64-bit operations use Xn > > registers. It's the same register set, Wn just denotes the lower 32 > > bits. > > > >> > >> - is the target solution will be running ALL in 32 bits? (boot in 32 > bits, > >>> Linux 32 bits, 32 bits apps)? > >>> - or is the target solution will be hybrid (64 bits Linux and some 32 > bits > >>> apps). > > I think this is the more likely path. If you have >= than 4GB of RAM > > (and also other stuff that needs physical addressing), you want a > > 64-bit kernel. > > > >>> > >> > >> The target solution could be Hybrid. Linux could be 64b, the > applications > >> could be 32b. It is my understanding that everything 32b is also > possible > >> using AArch32. > >> > >> > >>> When I read "AArch64 was designed to remove known implementation > >>> challenges of AArch32 cores" on http://infocenter.arm.com/ > >>> help/index.jsp?topic=/com.arm.doc.dai0490a/ar01s01.html > >>> I wonder if stating we support AArch32 is a good idea... > >>> > >>> So what is the best way to describe what we want? > >>> - ARMv8 LP64 or ILP32 ? > >>> - AArch64 LP64 or ILP32 ? > >>> - LP64 or ILP32? > >>> > >>> I think the best way to say is 'we support AArch64 and AArch32'. > > Re AArch64, LP64 or ILP32 applications? > > > > AArch32 or ARMv7a? > > > >> > >> > >>> FF > >>> > >>> > >>> On 23 March 2017 at 04:57, Honnappa Nagarahalli < > >>> [email protected]> wrote: > >>> > >>>> Hi Bill / Matt and others, > >>>> What I was trying to say in our discussion is that, the > >>>> ODP-Cloud code should not be pointer heavy. > >>>> > >>>> Please take a look at this video from BUD17: > >>>> http://connect.linaro.org/resource/bud17/bud17-101/ (unfortunately > >>>> there are no slides, I am trying to get them). This talks about the > >>>> performance of the 32b application on AArch64. One of the > >>>> applications, has huge performance improvement while running in 32b > >>>> mode (ILP32 in this particular case) on AArch64 (when compared to the > >>>> same application compiled for 64b mode running on AArch64 i.e. in 64b > >>>> compilation it performed very poorly). My understanding is that this > >>>> particular application is a pointer chasing application. Other > >>>> applications which are not pointer heavy, do not have this behavior. > > Isn't the problem with LP64 that if you have a lot of pointers stored > > in data structures, these take 2x the space of ILP32 pointers and thus > > increases the cache pressure. > > > > I don't think it is the pointer chasing itself that is penalised by > > 64-bit pointers. Pointer chasing apps are penalised by long > > load-to-use latencies (L1 cache hit latency, L2/L3 latencies, DRAM > > latency). > > > >>>> > >>>> So, we need to make sure ODP-Cloud is not pointer heavy and does not > >>>> force the application to be pointer heavy, to get good performance out > >>>> of 64b systems. > > Even with LP64, ODP could use 32-bit handles for ODP objects. The > > address lookup of the handle needs to be efficient (from a cache > > perspective) though, already now I can see hotspots in the function > > that returns an address from a handle. > > > > Yes, this is what I am trying to convey. If we have 32-bit handles, it > does not matter whether it is Aarch32 or Aarch64, the performance will > be optimized. > The only way we've been able to achieve strong typing with ODP is if the handles are of size sizeof(void *). This isn't the case in AArch64, so I don't think this will hold. Obviously when ODP is compiled for AArch32 pointers (and hence handles) are 32-bits. > > >>>> > >>>> Thank you, > >>>> Honnappa > >>>> > >>> > >>> > >>> > >>> -- > >>> [image: Linaro] <http://www.linaro.org/> > >>> François-Frédéric Ozog | *Director Linaro Networking Group* > >>> T: +33.67221.6485 > >>> [email protected] | Skype: ffozog > >>> > >>> >
