FW: MIPS BSPs

[Joel Sherrill]

Wayne Bullaughey wrote:
> 
> -----Original Message-----
> From: Joel Sherrill [mailto:joel.sherrill at oarcorp.com]
> 
> > The general overriding design philosophy is that the score/cpu code
> > only depends on mips ISA level.
> 
> I don't really understand why you want the ISA level to be the only
> attribute to depended on.  Why can't you define a new way to categorize MIPS
> processors which is not based on the compiler but is an attribute which is
> defined by the BSP configuration? This would be a documented classification
> which allows for extension. The ISA level really only describes the
> instruction set which is something that is almost completely hidden from the
> source code by the compiler and assembler.

Because the ultimate goal is to be able to provide a prebuilt
RTEMS (ala libc.a) that is augmented by a BSP Kit to be specific
to your hardware.  At that point, libcpu and libbsp will be
foundation of the BSP Kit the main things a user builds locally.
Everything else will have been prebuilt.

There is a documented classification now "RTEMS_CPU_MODEL" which is
used in the libcpu code to distinguish which set of code to use
to augment the basic CPU port. libcpu already includes cache
management and interrupt vectoring code for the mips.

The ISA is not completely hidden because there are issues of
branch delay, register sizes (to save/restore), FPU presence/abscence,
etc. This covers most of the code in score/cpu.  Interrupt dispatching
and cache management tend to be CPU model dependent so we have
that in libcpu.
 
> > Another example is that from the executive's viewpoint,
> > the maximum number of vectors on the mips port is variable based upon
> > the contents of a variable initialized (constant) by the CPU model
> > code.
> 
> There are different ways to encapsulate concepts. (1) Calling a function or
> procedure provided by an encapsulation is one way. (2) Importing global variable
> is another. (3) Another way that seems reasonable is to include source
> definitions supplied by an encapsulation providing compile time bound
> encapsulations.  The way I was suggesting getting defines via standardly
> named include files from a BSP defined search path seams to retain the
> desired independence of the score/cpu code.

But all of the options are not equivalent from a build viewpoint.  Some
introduce dependencies that force libcpu to be there when score/cpu is
built.  We are trying to get away from that.  

(1) and (2) are OK and we do them today to glue libcpu and score/cpu.
I think the last two sentences are (3) and if the source definitions are
in a libcpu .h file, then libcpu must be there and the knowledge that
we are building only for CPU mdoel X is there.  We want to avoid that
knowledge and build dependency.


> >> I have been feeling that a complete architectural re-mapping of RTEMS
> (for
> >> true 64-bit use) is required in order to take advantage of what the
> 64-bit
> >> MIPS architecture is intended to provide.
> 
> > I don't doubt that but the mips port has some items on the mips
> > already at least partially addressed.  For example, the size of
> > the registers is conditional based on the mips ISA level.
> 
> Before I started using RTEMS I wrote an operating system for MIPS processors
> which had dynamically loaded applications instead of application and kernel
> code bound together. Originally it only supported 32 bit applications. Later
> I enhanced it to support 64 bit applications. There were amazingly few
> changes necessary. Internally the 64 bit compatible processors are always
> running in 64 bit mode. Compilers generate either 32 bit or 64 bit loads and
> stores depending on the model you specify. The main place you need to make
> changes is when you do conversions between pointers and values explicitly
> declared as 32 bits. One of the compiler modes is to make all ints 64 bits.
> In this mode implicit conversions don't change sizes.

Cool.  Then only the context switch and register save/restore in 
interrupt dispatching has to be conditional. :)

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