Compiling for boards/chips with the zmmul (m) instruction extension (e.g., CH32V002) on Intel macOS (x86_64) leads to the following error:
cc1: error: -march=rv32ec_zmmul_xw: unsupported ISA substring '_zmmul_xw'
Findings
It seems to be related to these issues:
Latest WCH provided toolchain files seem to only have the files needed to compile for _zmmul_ on the GCC12 directory, but it's only available for Apple Silicon (ARM64) macOS.
As already stated in other issues, support for legacy Intel-based macs is not on their roadmap, so it seems there’s not much we can do.
Workaround
Defining board_build.march = rv32ecxw in platformio.ini compiles successfully, with the drawback that multiplication operations will be unoptimized being performed by software instead of on hardware (similar to the CH32V003 behavior), also occupying more flash and so on.
This is not a blocker for me as I have access to other build environments; I'm documenting this as it may help someone else. Also, it can be of interest to the maintainers to document this limitation, provide a more user friendly error message or automatic fallback (though this may be undesirable due to subtle behavior differences depending implicitly on the build host).
Compiling for boards/chips with the
zmmul(m) instruction extension (e.g., CH32V002) on Intel macOS (x86_64) leads to the following error:Findings
It seems to be related to these issues:
Latest WCH provided toolchain files seem to only have the files needed to compile for
_zmmul_on the GCC12 directory, but it's only available for Apple Silicon (ARM64) macOS.As already stated in other issues, support for legacy Intel-based macs is not on their roadmap, so it seems there’s not much we can do.
Workaround
Defining
board_build.march = rv32ecxwinplatformio.inicompiles successfully, with the drawback that multiplication operations will be unoptimized being performed by software instead of on hardware (similar to the CH32V003 behavior), also occupying more flash and so on.This is not a blocker for me as I have access to other build environments; I'm documenting this as it may help someone else. Also, it can be of interest to the maintainers to document this limitation, provide a more user friendly error message or automatic fallback (though this may be undesirable due to subtle behavior differences depending implicitly on the build host).