ARM ACLE headers

Modern compilers for ARM often implement the Arm C Language Extensions, which is a set of headers that provide intrinsic functions that map onto specific assembly instructions. Are there any plans to support this with Norcroft?

There was some discussion about this a few years ago, but I can’t find it now! I don’t think anything came of it.

Edit: Seems I was wrong! See below :)

Interestingly, between 2021 and 2023 it went from closed source to open source (Creative Commons if I skim read right)

Are there any plans to support this with Norcroft?

ACLE support (of the various applicable feature defines in the section ssec-ATisa) was added to cc 5.90 18-Sep-22.

That’s not the intrinsics mind, but from a quick skim those mostly have inline assembler equivalents so could be emulated by writing yourself a header file and calling it arm_acle.h and including that. ie. I think you already have the airfix parts to do it today. Just to check my sanity I scrolled to a random page in the DSP section and picked:

#include <stdint.h>
#include <stdio.h>

static inline int32_t __qadd(int32_t arg1, int32_t arg2)
{
  int32_t result;
  __asm { QADD result, arg1, arg2 }
  return result;
}

int main(void)
{
  printf("Saturated %d\n", __qadd(123, 5));
  return 0;
}

and inspection of the output in DecAOF has done what you think and there’s a QADD instruction there just as the __qadd intrinstic would.

Thank you for this example, this is very interesting, intrinsics with DDE.

That’s not the intrinsics mind, but from a quick skim those mostly have inline assembler equivalents so could be emulated by writing yourself a header file and calling it arm_acle.h and including that. ie. I think you already have the airfix parts to do it today.

Sounds good. I had a go at doing this a while ago, but hit a roadblock due to a bug with inlining functions with 64-bit parameters. My attempt can be found here and just covers the CRC32 instructions from ARMv8 (which is what GCC did at first). Would there be any objections to integrating this officially and continuing to extend it via GitLab merge requests?

One question: does there need to be any special handling for types in arm_neon.h, or can that be implemented with cc 5.90 as well?

added to cc 5.90 18-Sep-22.

Possibly needs a little more advertising.

Just to check my sanity

I find it’s always best to avoid questions like that. I think I know the answer, but there’s not a lot I can do about it.

That’s not the intrinsics mind, but from a quick skim those mostly have inline assembler equivalents so could be emulated by writing yourself a header file and calling it arm_acle.h and including that. ie. I think you already have the airfix parts to do it today.

I had a go at doing this a while ago, but hit a roadblock due to a bug with inlining functions with 64-bit parameters. My attempt can be found here and just covers the CRC32 instructions from ARMv8 (which is what GCC did at first). Would there be any objections to integrating this officially and continuing to extend it via GitLab merge requests?

The compiler itself is trying to be a reasonably strict ANSI/ISO implementation, that’s why it has the standard headers built in but not (for example) the RISC OS specific kernel.h which are provided on disc.

So if ACLE intrinsics are what you fancy (I must say I find all the double underscores a bit ugly…) then that’d be something provided as an extension on disc. Through the magic of include search paths you might put them in an ACLELib as a separate entity, or if it’s literally just 1 header file it could live alongside kernel.h in RISC_OSLib.

I’m sure the 64b inlining issue could be worked around with a bit of brain effort – when I commented on ticket 589 it was from the point of view of reducing the problem to help ROOL rather than coming up with a workaround.

One question: does there need to be any special handling for types in arm_neon.h, or can that be implemented with cc 5.90 as well?

There’s no NEON in the inline assembler. You might be able to frig something with CDPNV instructions, but that feels like a level of source code obfuscation too far and you’d be better off just writing stuff in ObjAsm. Except of course then it doesn’t get inlined directly, you’d BL to a leaf function, and as you say there’s nothing doing anything clever with register allocation.

That aside, I worry the NEON intrinsics would lull you into a false sense of security in porting other code which uses them. In RISC OS you need to claim and release the SIMD register bank via VFPSupport SWIs – so even if it were possible to make something that looked right it wouldn’t work (or would stamp on another thread’s use of the registers).

As a first pass I’d just leave __ARM_NEON undefined and focus on the integer stuff first.