[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
pc386 BSP and PowerPC questions.
- Date: Tue, 23 Feb 1999 10:19:35 -0800
- From: gumby at zembu.com (D. V. Henkel-Wallace)
- Subject: pc386 BSP and PowerPC questions.
Date: Tue, 23 Feb 1999 07:52:10 -0600 (CST)
From: joel at oarcorp.com
On Tue, 23 Feb 1999 robini at icecube-consulting.com wrote:
> 1. Current target is an old 486SX-50 laptop using grub-0.5/1.44Mb
> floppy to boot.
> * I had to manually #ifdef out the floating point setup code in
> _CPU_Initialize in order to bypass the hard wired floating
> point assembler in there (causes exception on my machine).
> Was there a better way to avoid this problem?
RTEMS is based on the concept of CPU families and CPU models. The
pc386 BSP is currently targetting an i386/i387 combination. Other
BSPs (gen68360, mvme162, etc) use a concept of "BSP models" to use
the same BSP with different CPU models. This allows you to (1)
optimize code for a specific CPU model, (2) avoid illegal
instructions, (3) take into account minor hardware variations.
This concept needs to be applied to the pc386 BSP so there are some
variants like pc486sx or (better) pc386sx. This would change the
CPU model, CPU_CFLAGS, and standard libraries for the BSP to avoid
I think it would be simpler to fix x86 and PPC GCC to generate, as
does the MIPS, __soft_float__ or something like it when -msoft-float
is provided (someone not using gcc could just remember to specify
-D__soft_float__). Then that code, context switching code, etc could
be properly conditionalised. The gcc patches would not be major (I
can generate them if you'd like), but someone else would have to make
the concommitant changes to RTEMS.
By the way robini, you are passing -msoft-float to gcc, right?
Note that gcc doesn't multilib for x86, so you might want to think of
building a specific cross toolchain if you anticipate a lot of
development for this 486sx.