Features/ARM/SVE: Difference between revisions
(initial skeleton) |
No edit summary |
||
| (6 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
ARM's Scalable Vector Extensions are a novel extension to existing NEON and AdvSIMD extensions for providing vector processing. The novel part is the way the instruction set is structured allows for code generation without knowing what the implementation defined total vector length is. | ARM's Scalable Vector Extensions are a novel extension to existing NEON and AdvSIMD extensions for providing vector processing. The novel part is the way the instruction set is structured allows for code generation without knowing what the implementation defined total vector length is. | ||
==Current Status== | |||
As of 3.1 there is full support for user-mode and system emulation. Some kernel use cases (such as KVM with SVE) require additional work to support [[Features/ARM/VHE]] | |||
===Known Issues=== | |||
====Dynamically Linked SVE Binaries==== | |||
According to the [http://infocenter.arm.com/help/topic/com.arm.doc.ecm0665628/abi_sve_aapcs64_100986_0000_00_en.pdf|ABI] calls to library functions should preserve z0-7 and p0-p3 for passing vector parameters. Currently glibc doesn't do this resulting in parameters getting squashed when the smaller q0-7 are stacked and returned. You can work around this by forcing the linker to bind functions at start-up: | |||
${QEMU} -E LD_BIND_NOW=1 ./sveprogram | |||
It is currently being debated if the linker needs updating or if compilers should not be using PLT redirection for SVE functions [https://sourceware.org/ml/libc-alpha/2018-08/msg00017.html see discussion]. | |||
== More Information == | == More Information == | ||
* https://community.arm.com/processors/b/blog/posts/technology-update-the-scalable-vector-extension-sve-for-the-armv8-a-architecture | * https://community.arm.com/processors/b/blog/posts/technology-update-the-scalable-vector-extension-sve-for-the-armv8-a-architecture | ||
[[Category:Completed feature pages]] | |||
Latest revision as of 10:57, 13 March 2019
ARM's Scalable Vector Extensions are a novel extension to existing NEON and AdvSIMD extensions for providing vector processing. The novel part is the way the instruction set is structured allows for code generation without knowing what the implementation defined total vector length is.
Current Status
As of 3.1 there is full support for user-mode and system emulation. Some kernel use cases (such as KVM with SVE) require additional work to support Features/ARM/VHE
Known Issues
Dynamically Linked SVE Binaries
According to the [1] calls to library functions should preserve z0-7 and p0-p3 for passing vector parameters. Currently glibc doesn't do this resulting in parameters getting squashed when the smaller q0-7 are stacked and returned. You can work around this by forcing the linker to bind functions at start-up:
${QEMU} -E LD_BIND_NOW=1 ./sveprogram
It is currently being debated if the linker needs updating or if compilers should not be using PLT redirection for SVE functions see discussion.