FW: MIPS BSPs

[Wayne Bullaughey]

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

> 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. Calling a function or
procedure provided by an encapsulation is one way. Importing global variable
is another. 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.

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