On 27 March 2017 at 07:58, Honnappa Nagarahalli <honnappa.nagaraha...@linaro.org> wrote: > My answers inline. I was confused as hell just a month back :) > > On 23 March 2017 at 06:28, Francois Ozog <francois.o...@linaro.org> 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 < >> honnappa.nagaraha...@linaro.org> 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. >>> >>> Thank you, >>> Honnappa >>> >> >> >> >> -- >> [image: Linaro] <http://www.linaro.org/> >> François-Frédéric Ozog | *Director Linaro Networking Group* >> T: +33.67221.6485 >> francois.o...@linaro.org | Skype: ffozog >> >>
