pc386 on 386sx

[erik.ivanenko at utoronto.ca (erik.ivanenko)]

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
> conceived.
>
> 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
> 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"
RTEMS.

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
libbsp.

Does this mean printCpuInfo is "above" libbsp?









-------------- next part --------------
A non-text attachment was scrubbed...
Name: vcard.vcf
Type: text/x-vcard
Size: 291 bytes
Desc: Card for Erik Ivanenko
Url : http://rtems.rtems.org/pipermail/rtems-users/attachments/19990729/9d97969a/attachment.vcf