Problems with starting new BSP

[Ralf Corsepius]

"Correo Fernando-ruiz (E-mail)" wrote:
> 
> Hi Ralf.
> 
> > -----Mensaje original-----
> > De: corsepiu [mailto:corsepiu]En nombre de Ralf Corsepius
> > Enviado el: martes, 10 de julio de 2001 21:17
> > Para: fernando.ruiz at ctv.es
> > CC: 'Radzislaw Galler'; 'Joel Sherrill'; 'Radzislaw Galler';
> > rtems-users at oarcorp.com; jmills at tga.com
> > Asunto: Re: Problems with starting new BSP
> ...
> > > ------------- END OF EXAMPLE ---------------
> > >
> > > And WORKS VERY WELL.
> >
> > <Sigh> this bug finally seems to be fixed </sigh>
> >
> > This will open opportunities for me to clean up some parts of the
> > sh-port's code.
> >
> 
> It's possible including a new include file in order to simplify the life
> at the programmers when a new clean code from the scratch is writed instead
> a
> translation from open source code (linux,Bsd,...)
> 
> I think that the memory mapped registers can be managed in a way more
> comfortable
> that the linux read8() write16() etc macros.

Hmm, I disagree. Though these macros may seem trivial, they actually
form an API, which is highly portable across targets. Under Linux
they even have  been used to hide virtual/physical address mapping.

> With this file we add three ways to make the same thing.
> All the actual code is compatible but
> the original Hitachi EVB registers can be accessed adding a simple '_' at
> end
> of the macro numerical value rewrited by you.
> 
> The bits of the registers can be accessed using bit_fields.
Well, using bitfields is tempting, but I am rather reluctant wrt.
this ...

AFAIK (Anybody with an ANSI, c89, c99 etc. standard at hand
listening?), C-bitfields are considered to be an internal
implementation detail of the compiler. I.e. there is no guarantee
that a C-bitfield bit will match any bit in certain registers or
memory cell (IIRC, on i386's, eg. MSC-6.0 lays out bitfields the
opposite way gcc does). 

[My German K'n'R-book is rather explicit (rough translation):
bitfields are a non-portable method to implement bit access...
Memory layout should be considered entirely implemention dependent.]

Besides this, bitfields are particularily tricky to handle wrt.
endianess. I.e. typically, such bitfields will only work for a given
endianness, ands will require to apply structs simiar to the code
snippet below (from Linux-2.4.4's linux/tcp.h) to allow different
endianesses.

> struct tcphdr {
>   	__u16   source;
>         __u16   dest;
>   	__u32   seq;
>         __u32   ack_seq;
> #if defined(__LITTLE_ENDIAN_BITFIELD)
>   	__u16   res1:4,
>   		doff:4,
>   		fin:1,
>   		syn:1,
>    		rst:1,
>                 psh:1,
>                 ack:1,
> 		urg:1,
>                 ece:1,  
>                 cwr:1;
> #elif defined(__BIG_ENDIAN_BITFIELD)
>         __u16   doff:4,
> 	        res1:4,
> 	        cwr:1,
> 	        ece:1,
> 	        urg:1,  
>                 ack:1,
> 	        psh:1, 
> 		rst:1, 
> 		syn:1,
> 		fin:1;

Note the twists and swappings to ensure correct packing. (This IS
error-prone!)

This is particularily critical for the SHes, because the SHes
support both endianesses (Little endian: -ml), with the default
endianness changing for different OSes (WinCE -> Little endian) and
SH-models (SH1/SH2 big endian, SH3+ little endian). 

At present time, RTEMS/SH is supposed to support both endianness
(Though probably nobody has tried to run little endian RTEMS/SH :).

Furthermore, handling endianness with macros is an evil general
problem which should be avoided whenever possible. 
In this particular case (low-level driver code of an OS, using gcc)
it is technically no problem as gcc provides appropriate defines,
but the behavior of other compilers is hardly predicable (Q: "Do
they define endianness defines?") and detecting target endianness by
autoconf-checks is generally impossible. 
However, we already exploit and rely on other gcc-features for
RTEMS/SH, which voids many of the portability issues mentioned above
:(

> I have used all of this im my implementation and works very well
> (sauf erreur, bien sur)

I have no reason not to trust you :)

>  * Now the old style access adding '_'

Does this mean you broke the API? This would not be acceptable for
me (I didn't check the details).

> ---------------- END OF EXAMPLE ---------------
> I have used your numerical definitions avoiding errors of
> retyping.
>
> The gcc code is very optimized to profite the bitfield feature.
> 
> All the registers have been writed.
> 
> Useful?
I am not sure. 

Though bitfields are convenient and tempting to use, they are a pain
to test, with a large portion of using them being compiler
implementation dependent.

So let me put it this way: 
* Little endian support is a must.
* Breaking the API is not acceptable.
* Files should be portable between compilers.
* SH-Files should be shareable between different SH-variants.

>From this, I conclude that optionally/conditionally having bitfields
in addition to the old macros would be fine, but replacing the
macros with bitfields should not be done.

Ralf