Changing compilation options for BSP building

[Jiri Gaisler]

Ralf Corsepius wrote:

> 1. Here, you have commented out code being shared between all BSPs and
> thereby are breaking the API:


This is indeed a mistake - the shared memory driver was disabled
for debugging. I will fix this are re-generate the patch.

> 2. Can you explain this patch below:
> 
> --- rtems-4.6.5/cpukit/score/cpu/sparc/rtems/score/sparc.h      2003-09-04 20:47:40.000000000 +0200
> +++ rtems-4.6.5.12/cpukit/score/cpu/sparc/rtems/score/sparc.h   2005-10-24 15:34:57.000000000 +0200
> @@ -66,11 +66,7 @@
>   */
> 
> 
> -#if defined(_SOFT_FLOAT)
> -#define SPARC_HAS_FPU 0
> -#else
>  #define SPARC_HAS_FPU 1
> -#endif
> 
>  #if SPARC_HAS_FPU
>  #define CPU_MODEL_NAME "w/FPU"


The sparc port now uses the same code for cpus with and without FPU.
The presence of an FPU is detected at run-time, so SPARC_HAS_FPU is
always enabled. The sparc port and all bsps are always compiled with
-msoft-float, so no FPU instructions are present in the kernel
except in the assembly files for task switching etc. Application
compiled with -msoft-float will run OK since the kernel will detect
that no FPU is in the system and attempt to touch any FPU registers.
Application with FPU instructions will also work OK, and the kernel
will properly save/restore the FPU context if an FPU was detected.
Attempting to run FPU code on FPU-less hardware will give an error.
These modifications allows to reduce the number of sparc bsps, since
separate versions for FPU/no-FPU are no longer needed.

I can agree that  #define CPU_MODEL_NAME "w/FPU" is not necessary
anymore, since the FPU is probed at run-time.

I will re-work the patch at this point as well and remove CPU_MODEL_NAME.

Thanks for the feed-back,

Jiri.