C compiler bounty: ACLE support?

Quick question – will the ARMv7 code generation bounty include adding support for some/all of the relevant bits of ARM’s C language extensions?

https://developer.arm.com/architectures/system-architectures/software-standards/acle

And for anyone reading the above who is really confused as to why ACLE 2.0 deprecates the DSP style intrinsics for A-series cores, my best guess is that it’s because there aren’t any directly equivalents available in AArch64 (and thus any code which relies on them, instead of the more AArch64-friendly NEON intrinsics, could break or suffer performance issues when recompiled for AArch64). However the wording of the deprecation messages makes the documentation look pretty poor quality.

adding support for some/all of the relevant bits of ARM’s C language extensions?

Both the March and May betas (sign up to get them if you’re brave/dumb enough) have a new section describing the intrinsics, whose syntax matches ARM’s compiler (well, the Cortex-M one I’m more used to seeing as part of MDK5, which has the same syntax as the full fat version anyway), those being:

• __breakpoint();
• __current_pc();
• __current_sp();
• __nop();
• __return_address();
• __schedule_barrier();
• __semihost();

The inference (from ‘around 75 in total’) couldn’t possibly include the NEON/VFP part as there’s many more than 75 of those, so I’m only expecting the main instruction set in the inline assembler, and even then I think I’ll stick to ObjAsm for assembler thanks.

so I’m only expecting the main instruction set in the inline assembler

When talking about the ACLE, inline assembler is irrelevant – the aim of the ACLE is to make it so that people don’t have to use assembler (inline or not) when they want to use special/advanced features. It defines a bunch of intrinsics and data types (and #defines for feature detection) to allow the features to be used directly from C/C++, without a single “asm” in sight.

Of the intrinsics you’ve listed, __nop is the only one defined in ACLE.

Both the March and May betas (sign up to get them if you’re brave/dumb enough)

I figured there wasn’t much point in me signing up, since the only thing I really use Norcroft for is building the OS (and I’d expect ROOL and the bounty claimant to be able to manage testing compatibility with the OS sources themselves). However the (non-OS) code I’m currently working on could make for an interesting performance comparison between Norcroft and (RISC OS) GCC, so I guess it’s worth signing up.