[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
pc386 on 386sx
- Date: Thu, 29 Jul 1999 14:29:21 -0700
- From: erik.ivanenko at utoronto.ca (erik.ivanenko)
- Subject: pc386 on 386sx
joel at oarcorp.com wrote:
> 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
I don't follow the notion of "on top of". I thought I got "beside/below", but then got
very confused. What makes a piece of code/module "on top of" another? There is some
sort of dependency, but it is not clear to me. Is it a "used by" relationship? eg.
Suppose routine X is present in libcpu. Routine X is generic to the i386 family, has
no dependence on the RTEMS executive -- it does not use RTEMS routines. Routine X is
"used by" the BSP and also "used by" the executive. Is routine X
"ontop"/"beside"/"below" RTEMS? I'd think "below" both the BSP and RTEMS.
But routine X manipulates vector tables, an operation that you have claimed is "above"
I am missing something!
Also, some routines like irq_init are in libbsp/i386/shared. These could just as
easily be in libcpu could they not? Other routines like printCpuInfo in
libcpu/displayCpu.c should be in libbsp/i386/shared, since printk is available only in
Does this mean printCpuInfo is "above" libbsp?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 291 bytes
Desc: Card for Erik Ivanenko
Url : http://rtems.rtems.org/pipermail/rtems-users/attachments/19990729/9d97969a/attachment.vcf