Problems with starting new BSP

[fernando.ruiz at ctv.es]

Hi.

> -----Mensaje original-----
> De: corsepiu [mailto:corsepiu]En nombre de Ralf Corsepius
> Enviado el: miercoles, 11 de julio de 2001 10:17
> Para: correo at fernando-ruiz.com; rtems-users at oarcorp.com
> CC: 'Radzislaw Galler'; 'Joel Sherrill'; jmills at tga.com; Silverio
> Diquigiovanni (E-mail)
> Asunto: Re: Problems with starting new BSP
>
>
> "Correo Fernando-ruiz (E-mail)" wrote:
> >
> > Hi Ralf.
> >
...
> > >
> > > 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.
>

I can't change the actual way.
This will continue working in the same way that now.

The suggestion is only for to add a new methode to access at the register.
The actual code can be compiled without problems.

The new code can be optimized using the bitfieds or
the Old Hitachi methode (sh-hms-gcc)

...
> > the original Hitachi EVB registers can be accessed adding a
> simple '_' at
> >
...
> > 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).

Well. I speak in the sh-rtems-gcc case ONLY. The Idea is only to add a new
file in the
sh BSP or right place.

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

I continue speaking for a sh-rtems-gcc compiler.
If you want to use WinCE the you need use another
compiler or developper environment.

In this case a #ifdef is necesary in order to show a error is you want
to use this feature and the model is not correct.

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

NO. Your methode is the same.

The new MACRO adding a '_' at your current macro only redo the
old sh-hms-gcc methode. Your numerical macro is the same.
The new macro with the '_' only makes the access at the old system.
I have a lot of code sh-hms-gcc that need be rewrited with your methode.
With my suggestion onlya a little '_' added in every old macro value
makes compilable the old code in sh-rtems-gcc environment.

I don't have problem if your opinion is don't aggree the file for the RTEMS
source tree.
I can always to place the file in my owner BSP.

>
> > ---------------- 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.
Almost a #error if the model is not correct.
> * Breaking the API is not acceptable.
I don't want this.
> * Files should be portable between compilers.
Why? Another compiler can compile the RTEMS source tree?

> * SH-Files should be shareable between different SH-variants.
For every hitachi model is necesary a new include file.
The porters(users) need to make the new include file
I don't have SH2 . I have at home a DreamCast SH4 but only for enjoy.
>
> >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.
>
IMHO OF COURSE.

Fernando RUIZ CASAS
home:correo at fernando-ruiz.com
work:fernando.ruiz at ctv.es


> Ralf
>