ARMv8-M basic support

[carlescufi]

Add basic support for the ARMv8-M architecture and its cores:

config ARMV8_M
config CPU_CORTEX_M23
config CPU_CORTEX_M33

Including any changes in the conditional compilation of common ARM core to support the new architecture.

[carlescufi]

@ioannisg FYI

[ioannisg]

FYI #5976 brings CMSIS headers for Cortex-M23,M33 (Armv8-M)

[ioannisg]

FYI #5999 is meant to bring in compile-time defines for ARMv8-M (arch/ and include/ in the Zephyr tree)

[ioannisg]

@carlescufi @galak @nashif @SebastianBoe @skordal As soon as #5999 is merged, we will be able to compile for CortexM23/M33. One issue we will run into is the following:

core_cm33.h has the following compile-time check, in case _GCC is used:

  #if defined (__ARM_FEATURE_DSP) && (__ARM_FEATURE_DSP == 1U)
    #if defined (__DSP_PRESENT) && (__DSP_PRESENT == 1U)
      #define __DSP_USED       1U
    #else
      #error "Compiler generates DSP (SIMD) instructions for a devices without DSP extensions (check __DSP_PRESENT)"
      #define __DSP_USED         0U
    #endif
  #else
    #define __DSP_USED         0U
  #endif

If we do not define __DSP_PRESENT (which is an optional feature, or course), we must make sure that __ARM_FEATURE_DSP is not defined.

However: GCC does not support the option to exclude the DSP instructions from the compilation, in a released version, at the moment. In other words, GCC always defines __ARM_FEATURE_DSP=1.

ARM GCC manual refers to +nodsp option of -march, as an option to exclude the DSP instruction set, but this is not yet supported in current GCC versions.

In other words, we would need a workaround, for core_cm33.h, otherwise compilation for CortexM33 fails.

A dirty workaround is to modify the CMSIS and disable this check.

Another hackish workaround is to compile with a -U__ARM_FEATURE_DSP option, or a -D__ARM_FEATURE_DSP=0 option, if we are selecting CORTEX_M33 and CPU_HAS_DSP. In other words, we overwrite the definition of __ARM_FEATURE_DSP (hich compiler defines as __ARM_FEATURE_DSP=1 through built-in checks).

Also, we did some investigation with GCC: turned out that development (non-release) versions of it support the +nodsp option. So we could compile our own GCC and then compile the project with this GCC compiler (and include +nodsp).

Could we think of a better solution to this problem?

[SebastianBoe]

Hi.

After discussing with @ioannisg we agreed that we have two options:

1. Re-compile a development version of GCC and distribute it in a new Zephyr SDK release that supports 1.11.

2. Keep the #error, and communicate somehow that if you want to use M33 without DSP you are going to have to build your own development version of GCC.

I would suggest going for option 1, it is a bigger effort for us, but it is better for the user.

EDIT: To be clear, in both options we do not patch core_cm33.h.

[carlescufi]

Closing this, we can open an issue with the DSP flag if required.