AsmJit Ports & Future Development

This issue provides an insight into new ports that are either in development or that were requested, but are either not in development or not planned. The purpose of this meta-issue is to have all ports mentioned in a single meta-issue instead of having them spread across multiple issues.

Additionally, this meta-issue provides a feature matrix of supported architectures and extensions and discusses a long-term commitment and development sustainability.

Please don't use this meta-issue to start discussions. Use the Discussions panel instead or create a separate Issue if you would like to discuss something regarding the architectures and extensions supported by AsmJit.

List of Supported Architectures

• X86 & X86_64 - This platform has been supported from the beginning
• AArch64 - Supported, except SVE/SVE2; recent extensions such as CSSC are not supported yet

List of Unsupported Architectures

• AArch32 - ARM32 and Thumb are in a32_port branch, testing is welcome, nobody seems to be using this port (Branch: https://github.com/asmjit/asmjit/tree/a32_port - currently not mergeable)
• RISC-V - Planned in the future, no commercial interest
• PPC64 - Considering, no commercial interest
• LoongArch - Considering, no commercial interest (PR: Add loongarch architecture support #441 - currently not mergeable)
• MIPS - Not planned, no commercial interest

No commercial interest means that there is no company or multiple companies that would want to sponsor the development and maintenance of the port.

Feature Matrix of Supported Architectures / Extensions

• X86 & X86_64

  • Baseline GP instructions and extensions (ADX, BMI, CMOV, CMPXCHG[8|16]B, POPCNT, ...)
  • System instructions
  • Virtualization instructions
  • FPU instructions
  • MMX extensions (MMX, MMX2, 3DNOW, ...)
  • SSE extensions (SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, PCLMULQDQ, ...)
  • AVX extensions (AVX, AVX2, F16C, FMA, FMA4, XOP, VAES, ...)
  • AVX-512 extensions (AVX512_[F|BW|DQ|CD|VBMI|...)
  • AMX extensions (AMX_TILE, AMX_FP16, AMX_INT8, ...)
  • (future) APX extensions
  • (future) AMX extensions (AMX_TRANSPOSE, AMX_AVX512, AMX_FP8, ...)
  • (future) AVX10 extensions (AVX10.1, AVX10.2)

• AArch64:

  • Baseline GP instructions
  • System instructions
  • Virtualization instructions
  • Baseline VFP/NEON instructions and extensions (ASIMD, DOTPROD, ...)
  • New GP extensions (CSSC)
  • SVE extensions (SVE, SVE2, ...)
  • SME extensions (SME, SME2, ...)
  • (future) extensions not tracked at the moment

Note that APX and AVX10 are future CPU extensions that are not present in today's CPUs, so X86 backend can be considered complete at the moment.

Long Term Commitment

In general, AsmJit's long-term commitment is to support 32-bit and 64-bit X86 and 64-bit ARM (AArch64). These two architectures are the most important for AsmJit users at the moment and AsmJit commits to supporting them long-term.

Other architectures seem to not be that much important and there is currently no long term commitment to provide and maintain them unless a company or multiple companies would want to support the development and future maintenance of these ports.

Supporting Future Extensions

Currently the most supported architecture is X86 & X86_64, because AsmJit supports basically the whole instruction set as of 2024. AArch64 support should be considered a baseline only as AsmJit doesn't support SVE and SME extensions, which are massive (larger than NEON).

There is currently no commitment to supporting future extensions such as APX and AVX10 (X86 backend) and existing and future extensions such as CSSC, SVE, SVE2, SME (AArch64 backend). The reason is lack of time.

Maintenance and Development of New Ports and ISA Extensions

AsmJit team is currently 1 person doing all the work, which can be divided into the following categories:

• Maintenance
  • Build system and CI related work (CMake and CI updates, dealing with CI failures, etc...)
  • Maintaining the current codebase (removing compile-time warnings/errors introduced by new C++ compilers, refactoring, writing more tests, etc...)
  • Bug fixing (there are multiple categories, the most severe bugs are wrongly encoded instructions and crashes - fortunately both are rare thanks to the extensive test suite AsmJit has)
  • Writing more documentation to make https://asmjit.com/doc/index.html better for newcomers
• New Features
  • Writing new features that were not previously part of AsmJit. Could be supporting more platforms or adding features such as huge-pages support, or simply using some platform API to make something faster, etc...
  • Adding more instructions to existing ports (this work involves updating AsmJit instruction database, assemblers, etc...)
  • Adding new ports (writing whole new ports from scratch - for example the whole AArch64 port)
• Community
  • Issues, feature requests, bug reports, ...
  • Available to the community on AsmJit's Chat Channel (https://app.gitter.im/#/room/#asmjit:gitter.im)
  • Running the AsmJit website, making AsmJit available for users, possibly supporting AsmJit in package managers such as vcpkg, ...

In a nutshell it's a lot of work to do to just maintain a project such as AsmJit. There is always something that requires the attention even if it's not writing new C++ code - bugs, CI problems, brief documentation, website issues, outdated packages in vcpkg/conan, etc... And this is just about the maintenance and not writing new features.

But that's not all of it. For example in order to support new CPU extensions of supported architectures, it requires to check and to "process" all the documentation and architecture manuals that are released by Intel, AMD, and ARM, which means hours and hours of work and testing to add new instructions and test cases to verify that AsmJit handles them correctly.

Sustainable Development Model

AsmJit project is currently exploring a better development model, which would make the project more sustainable and would guarantee a future development and maintenance of AsmJit. The reason is that it's currently very difficult to implement new features due to lack of time of AsmJit developers.

It would be nice if companies that use AsmJit also supported its developers, because without this support AsmJit can start lacking support of new extensions and future architectures that can become important (such as RISC-V).

Supporting AsmJit doesn't have to be just sponsorship - commercial support for AsmJit is also an option, so companies can get something back for their support.