Features/ARM/SVE: Difference between revisions

From QEMU
(Add a note on known issues)
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.


==In Development ==
==Current Status==


Support for linux-user mode was merged in the 3.0 cycle. Work on System Emulation mode is ongoing.
As of 3.0 there is full support for user-mode SVE programs. System Emulation is still a work in progress but should be ready by 3.1
 
===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


== 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

Revision as of 15:19, 2 August 2018

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.0 there is full support for user-mode SVE programs. System Emulation is still a work in progress but should be ready by 3.1

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

More Information