Arm Begins Adding ARMv8.7-A Support In LLVM Clang 12

[phoronix]

Phoronix: Arm Begins Adding ARMv8.7-A Support In LLVM Clang 12

Back in September Arm began talking about their "2020 extensions" for the A-profile architecture. Initial support for these new additions as ARMv8.7-A is beginning to land in the LLVM compiler stack...

http://www.phoronix.com/scan.php?page=news_item&px=ARMv8.7-A-In-LLVM-Starting

[Jumbotron]

I found these small tidbits to be interesting as well. This is from the article on ARM's website linked in Michael's post.

The 2020 extensions also include other small features:

• Support for 52-bit virtual and physical addressing with 4KB and 16KB translation granules
• Enhancements to Privilege Access Never (PAN)
• Support for asymmetric fault handling in MTE
• Enhancements to PMU and SPE

Also was this blurb from the same article which is encouraging from the standpoint of making developing on ARM easier and fruitful.



As part of the 2020 enhancements, Arm is introducing two new extensions as part of the Future Architecture Technologies program. Future Architecture Technologies are not released architectures, but those for which we want to share advance information to enable the ecosystem to prepare.

The Call-Stack Recorder Extension (CSRE) and Branch-Record Buffer Extension (BRBE) aim to improve the experience of developing software for Arm. The experience is improved by providing enhanced visibility of how code is executing. This information can be used for debugging, profiling, identifying hot-spots, Feedback Driven Optimization (FDO), and many other uses.

CSRE provides a low impact mechanism to record and unwind the stack. A live view of the current call stack is recorded in memory, where it can be efficiently captured for performance analysis or interpreted for debug.

BRBE captures a recent sequence of branches in an easily consumable format. This information can be used for debugging or fed into profiling tools for hot-spot analysis and AutoFDO.


https://community.arm.com/developer/...elopments-2020

[Jumbotron]

I also had a look at an article on ARM's dev website linked below the announcement article of the 8.7a version of ARM. It recognizes that the world of Windows is moving inexorably to ARM.

Time to get excited about the growing Windows on Arm Ecosystem

2020 has been a big year for the Windows on Arm (WoA) ecosystem. The new ‘third generation’ of devices reached the market, including the world’s first ever 5G laptop – the Lenovo Yoga 5G – and Samsung Galaxy Book S. However, it is not just the hardware, the WoA developer ecosystem is continuing to advance with some significant developments.

As part of the Snapdragon 8cx gen2 5G chip (which is built on Arm technology) launch at September’s IFA 2020, Qualcomm were joined by Microsoft’s Chief Product Officer, Panos Panay. He announced that the Microsoft App Assure team is working with companies to get their apps running on WoA laptops. The aim, according to Panay, is “to light up so many applications for both consumers and commercial customers alike.” This will make the overall application development and transition process for WoA easier for developers, with Microsoft providing the necessary support when needed.

It is already starting

Alongside the recent commitments from Microsoft, more applications are now being targeted for WoA. One significant development has been Adobe releasing a version of Photoshop for WoA devices. This beta release means WoA users can now run Photoshop natively on their devices, bringing a completely new user experience to WoA devices. This also encourages a brand-new base of users to start using WoA devices.

One such company is LiquidText, which uses a highly visual and innovative touch user interface to allow users to actively review and annotate one or more documents at any one time. With the tools and support provided by Microsoft and Arm, the port from UWP Windows 10 to Arm was quick and painless for LiquidText. The whole process was less than two months’ work. As Craig Tashman, the founder and CEO of LiquidText, said at DevSummit (see previous video), “nothing ‘just works’ but the transition to Arm came very close to that.” LiquidText’s decision to port to focus on WoA devices was due to the thin, lightweight form factor, all-day battery life and ultra-powerful touch and ink-based features of the devices.

Another innovative application feeling the benefits of WoA devices is StaffPad, a music notation app designed to make the process of writing and performing music easier and more natural. The app benefits from the pen and touch capabilities of WoA 2-in-1 laptops, such as the Microsoft Surface Pro X built on an Arm-based custom processor.

Similar to LiquidText, StaffPad had a pain-free transition to WoA after it was built on UWP. As David William Hearn, Founder and Director at StaffPad, says: “Once the toolchain is set up, the process of building for Windows on Arm is painless and low-effort.” On performance, the WoA version is already outperforming other versions of the application, delivering the snappy, glitch-free performance needed during complicated music scores.


https://community.arm.com/developer/...-arm-ecosystem


First Apple. Now Microsoft, as had to be expected and I knew all along since that is Microsoft's foundational principle is to copy not lead, and news coming from the ChromeOS/Chromebook world that anywhere from 5-10 models ranging from 3-5 manufacturers will have an ARM SoC in them primarily from Qualcomm and Mediatek.

The Age of ARM is here.

[brucehoult]

So they have an ARMv8.7-A spec but ARM's latest A-78 core is still on 8.2, as are I believe Qualcomm, Samsung, and Fujitsu.

Meanwhile Apples A13, A14, M1 are on 8.4 -- maybe later for the M1 as I haven't actually seen that published anywhere.

[SyXbiT]

So they have an ARMv8.7-A spec but ARM's latest A-78 core is still on 8.2, as are I believe Qualcomm, Samsung, and Fujitsu.

Meanwhile Apples A13, A14, M1 are on 8.4 -- maybe later for the M1 as I haven't actually seen that published anywhere.

I also don't get this. Why create new specs every year and not use them...

[Jumbotron]

So they have an ARMv8.7-A spec but ARM's latest A-78 core is still on 8.2, as are I believe Qualcomm, Samsung, and Fujitsu.

Meanwhile Apples A13, A14, M1 are on 8.4 -- maybe later for the M1 as I haven't actually seen that published anywhere.

AHEM.....let Wikipedia be your guide.



ARM v8-A

X-Gene
Nividia 1 & 2
Cavium ThunderX
AMD K12 (canceled)
Apple Cyclone (A7)
Apple Typhoon (A8 & A8X)
Apple Twister (A9 & A9X)
Apple Hurricane+Zephyr (Big.Little Arch) (A10 & A10X)
Qualcomm Kyro
Samsung M1 & M2 (Mongoose)
Samsung M3 (Meerkat)


ARM v8.1-A

Cavium Thunder X2


ARM v8.2-A

Nvidia Carmel
Samsung M4 (Cheetah)
Fujitsu A64FX (with 512 bit SVE vector extensions)
Apple Monsoon+Mistral (A11)


ARM v8.3-A

Apple Vortex+Tempest (A12, A12X & A12z)
Marvell Thunder X3


ARM v8.4-A

Apple Lightning+Thunder (A13)


ARM v8.5-A

???


ARM v.8.6-A

Apple Firestorm+Icestorm (A14 & M1)

https://en.wikipedia.org/wiki/ARM_architecture

[brucehoult]

AHEM.....let Wikipedia be your guide.

I did. The information conflicts. No reference is given for the information on the A14 and M1 on either page.

https://en.wikipedia.org/wiki/Comparison_of_ARMv8-A_cores

p.s. I believe ThunderX3 was cancelled.

[Sonadow]

The Age of ARM is here.

The age of ARM will only truly be here when there's a standard 'PC platform' for laptops and desktops on ARM, like how ACPI + UEFI makes up this universal generic platform for x64 hardware. I have no frigging wish to see something like this:

1. Windows 10 / Vendor-cutomized Linux kernel for ARM64 for Qualcomm Snapdragon 6xx SoCs
2. Windows 10 / Vendor-cutomized Linux kernel for ARM64 for Qualcomm Snapdragon 7xx SoCs
3. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for Qualcomm Snapdragon 8xx SoCs
4. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for Qualcomm Snapdragon 9xx SoCs
5. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for Microsoft SQ1 SoCs
6. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for Microsoft SQ2 SoCs
7. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for Samsung Exynos 75XX SoCs
8. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for Samsung Exynos 78XX SoCs
9. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for Samsung Exynos 79XX SoCs
10. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for Samsung Exynos 96XX SoCs
11. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for Samsung Exynos 8XX SoCs
12. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for Samsung Exynos 7-series SoCs
13. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for Samsung Exynos 88XX SoCs
14. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for Samsung Exynos 98XX SoCs
15. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for Samsung Exynos 9XX SoCs
16. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for Samsung Exynos 10XX SoCs
17. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for NVidia Tegra X1 SoCs
18. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for NVidia Tegra X2 SoCs
19. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for NVidia Tegra Xavier SoCs
20. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for NVidia Tegra Orin SoCs
21. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for AllWinner A6X SoCs
22. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for AllWinner A7X SoCs
23. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for AllWinner A8X SoCs
24. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for AllWinner A10X SoCs
25. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for AllWinner A20X SoCs
26. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for AllWinner A30X SoCs
27. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for Mediatek MT673X SoCs
28. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for Mediatek MT675X SoCs
29. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for Mediatek Helio X SoCs
30. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for Mediatek Helio A SoCs
31. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for Mediatek Helio P SoCs
32. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for Mediatek Helio G SoCs

Because that is what we're bloody seeing on all those specialized ARM boards. Nvidia's customized Ubuntu images for Tegra contain DTBs and patches which allow them to light up their own Jetson boards but will not work on any other ARM hardware. Raspbian only works on Pis and no other ARM hardware boards.

We desperately need some kind of standard platform to allow generic Linux installations across all ARM64 hardware like what we are currently taking for granted with x64. and the fastest way to achieve that is to adapt SBSA for consumer platforms.

Last but not least, we need Microsoft to drop the 'No user control over Secure Boot for ARM64 computers' if we truly want ARM64 desktop Linux to take off. Because right now, Microsoft mandates that all Windows ARM64 deployments must have Secure Boot permanently set to 'On' with no option to disable it or add additional keys / hashes to the SB database.

[Jumbotron]

I did. The information conflicts. No reference is given for the information on the A14 and M1 on either page.

https://en.wikipedia.org/wiki/Comparison_of_ARMv8-A_cores

p.s. I believe ThunderX3 was cancelled.

Come on dude. You can do better. I'm 57 years old and know how to search better than you.

Go to Apple Designed Processors in Wikipedia

Go down to the section that lists all the "A" SoCs

Look at the section of the chart which lists what version of the ARM ISA is attached to each Apple A series SoC

Look for the linkable footnote number

Click it

Read

Here are the snippets from a change log referenced in the link to the footnote concerning Apple's A13 using ARM's ISA version 8.4

Chapter 1:

• A13 has ARMv8.4, apparently (LLVM project sources, thanks, @Longhorn)

I can confirm that while hunting around for data on the new Matrix Math Processor on Apple's A13 I came across a pull request on LLVM mailing list verifying that ARM v8.4-A was incorporated into the A13. It was long ago and the night too late for me to be bothered finding it.

In addition the above snippet here is another from the change log of the OSX Book referenced that shows a historical chart of versions of iOS and the corresponding Apple Silicon SoCs associated with them




As you can see if you scroll over the time line, you see that the A11 was using ARM v8.1 and the A12 was using ARM v8.3. That's where the timeline ends. So that's a bit of additional corroboration that the A13 is using ARM v8.4 as posted above if you take the progression as stated above.

Now to the fact that the A14 and M1 are using ARM v8.6 I have also seen that with my own eyes on the LLVM mailing list. But don't take my word for it.....seek and you shall find just like I did.

https://en.wikipedia.org/wiki/Apple-designed_processors#cite_note-180

http://newosxbook.com/ChangeLog.html#v2

[brucehoult]

Come on dude. You can do better. I'm 57 years old and know how to search better than you.

Congratulations young fella. Perhaps you'll loosen up and become less unpleasant once you get to my age.

This is not exactly a question that I care about sufficiently to research further than Wikipedia -- which is, after all, what you urged me to do, and which I had in fact already done, even to the point of noting that Apple has not officially said, at least anywhere that I've seen.

As for LLVM:

- Ties Stuij of ARM proposed adding support for v8.6 bfloat16 type on March 20 and posted patches on March 26 and March 31.
- Luke Geeson of ARM added support for v8.6 Matrix Multiplication on April 9.

These commits don't provide evidence for anyone actually using v8.6 in shiping products and I'd suggest that even commits to LLVM by Apple employees (which these aren't) don't say anything about what the A14 or M1 implement unless they explicitly say so, which would be most unusual. Such commits could equally well be for CPUs one or two generations in the future which Apple is already playing with in simulation.

Now, if you provide some source code which tries to use bfloat16 instructions and the code turns out to work (with high performance) on the M1 then that would be evidence.