[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
pc386 on 386sx
- Date: Thu, 29 Jul 1999 13:35:58 -0500 (CDT)
- From: joel at OARcorp.com (joel at OARcorp.com)
- Subject: pc386 on 386sx
On Thu, 29 Jul 1999, erik.ivanenko wrote:
> VALETTE Eric wrote:
> > >>>>> "joel" == <joel at oarcorp.com> writes:
> > joel> On Wed, 28 Jul 1999, erik.ivanenko wrote:
> > joel> The more general solution is to use the cpuModel-like code to determine if
> > joel> the CPU model can support an FPU and use that in ADDITION to the patch I
> > joel> am posting to disable all FP actions on the fly if the FPU is not there.
> > Or use the result stored by cpuModel.S as explained...
> > joel> This does again raise the question about the boundary between libcpu and
> > joel> score/cpu. if the executive needs to know this information, then the
> > joel> cpuModel code is crossing the boundary. :)
> > NO. It is natural for score/cpu/<cpu> to use functions implemented
> > in libcpu/<cpu> as they only depend on processor and not on rtems executive
> > code... The main difference being that score/cpu/<cpu> functions shall
> > not be used by application code...
> I agree with Eric. The code/data located in any lib/lib<name> library
> should be available for use. In particular, lib/libcpu. I see
> nothing to distinguish libcpu from something like libnetworking.
There has been some miscommunication about what libcpu is.
EriC's statement that is code that "only depend on processor and not on
rtems executive code" is very clear.
Unfortunately, this likely means that there are actually two classes of
code in libcpu:
+ EriC's view of libcpu
- reuseable CPU dependent code largely independent of RTEMS
- I think of this as "below" or "beside" RTEMS.
+ code that is "on top of" RTEMS
- numerous clock/timer/interrupt controller drivers and vector
support for the mpc8xx, ppc4xx, MIPS, sh7032, etc.
+ code somewhere in between
- m68040/fpsp. Mostly RTEMS independent but a little bit of code
that is RTEMS dependent to hook in the vectors and vector them.
My original concept of libcpu was "on top of" RTEMS. It was supposed to
be code that was dependent on both RTEMS and the CPU. the "somewhere in
between" code fit in here nicely. But the "below/beside" code is where
the clean concept broke down and trouble crept in. :)
The RTEMS tree is nearly completely "top down", "left to right" buildable
except for a couple of libcpu and bsp warts. I think what EriC's comment
points out (validly I should add), is that there is a body of code like
cpuModel on the i386 which could easily be used by the RTEMS executive
code proper but is "beside/below" rather than "on top of" as libcpu was
EriC's point to me is that there is distinction that should be made
between code in score/cpu which should only be used outside RTEMS with
extreme care and the "below/beside" code which is fairly safe to use in
both RTEMS proper and in applications which are willing to do so.
The original concept of libcpu has been changed/expanded to include
"beside/below" code that is often used in both score/cpu and applications.
In proper left-right, top-down build, the "below/beside" code should be
"to the left" of RTEMS score/cpu somewhere in the build.
I feel like I have finally had an insight. The floor is now open to
convince me I have not had one or to help work out a mechanism to handle
this new "below/beside" code. I realy don't think identifying it is the
problem. cpuModel fits the bill nicely as a test case. :)
Joel Sherrill, Ph.D. Director of Research & Development
joel at OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985