GCC SPARC FPU issue status

_______________________________________________
rtems-users mailing list
rtems-users@...
http://www.rtems.org/mailman/listinfo/rtems-users

Memory usage

Hi,

I'm a bit paranoid about memory usage on my system. Are there means within rtems to see amount of memory used
or still free?

Martin

--

-- 

ir. W.M. Grim
SRON Netherlands Institute for Space Research
Sorbonnelaan 2
3584 CA Utrecht, The Netherlands
www.sron.nl 

_______________________________________________
rtems-users mailing list
rtems-users@...
http://www.rtems.org/mailman/listinfo/rtems-users

Re: Memory usage

Hi,

you may have a look at the malloc_* functions in libcsupport.h.

CU

Martin Grim wrote:
>  
> Hi,
> 
> I'm a bit paranoid about memory usage on my system. Are there means within rtems to see amount of memory used
or still free?
> 
> Martin
> 

--

-- 
Sebastian Huber, embedded brains GmbH

Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone   : +49 89 18 90 80 79-6
Fax     : +49 89 18 90 80 79-9
E-Mail  : sebastian.huber@...
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
rtems-users mailing list
rtems-users@...
http://www.rtems.org/mailman/listinfo/rtems-users

Re: GCC SPARC FPU issue status

Manuel Coutinho wrote:
>
> Hi
>
>  
>
> Was checking some mails exchanged in this mailing list a while ago 
> (2006) (http://www.rtems.com/ml/rtems-users/2006/may/msg00040.html) 
> and would like to know if the issue concerning GCC and SPARC floating 
> point registers is now solved or not. Does anybody know the status of 
> this issue? Is there a bug in GCC bugzilla so that we can track this? 
> try to find but with no luck :(
>
>  
>
> Briefly, the problem, as far as I understood, occurs when a function 
> receives multiple arguments: GCC might store some arguments on FPU 
> registers, which could cause all sort of problems, like an invalid FPU 
> trap, or an erroneous result on a thread that uses FPU (because the 
> register was changed).
>
> This problem could be solved by compiling RTEMS with –msoft-float flag 
> and the application without this flag (for the sections that want to 
> use floating point).
>
>  
>
This is fundamentally an incorrect thing to do and why this solution has
never been merged.  You should never never never mix multilib variants
in the same executable. 

If GCC is generating FPU instructions in unexpected places, then there
are two solutions:

+ Fix GCC.  This is (in general) a cross target issue which may end up 
having
    to be fixed in a target specific manner.  I don't know of a PR or 
anyone who
    is interested in working on this.  It is an issue on at least the 
PowerPC as
    well and that hasn't attracted any coders willing to address it.

+ Make all tasks in RTEMS FP.  We have resisted this solution because it
    takes time to save the FP state and increases the context switch time.
    But on PowerPC's with FPU, this is how this problem is solved.

So the proper solution until GCC is fixed is to turn on the cpu.h define
that says all tasks are floating point.
>
> It also seams that ERC32 has a different behavior than Leon2 and 
> Leon3: for Leon2 and Leon3, RTEMS does not save/restore hardware FPU 
> during a context switch. Is this correct? Shouldn’t the 3 BSPs have 
> the same behavior? Shouldn’t leon2 and leon3 save/restore the FPU 
> hardware during a context switch?
>
>  
>
I don't see how they could be different.  They use the same context 
switch code. 
Unless you are using some patches we won't merge.
>
> (I’m looking at RTEMS 4.8.0)
>
>  
>
> Thanks in advance
>
> Kind regards
>
> Manuel Coutinho
>
>  
>

--

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill@...        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985

_______________________________________________
rtems-users mailing list
rtems-users@...
http://www.rtems.org/mailman/listinfo/rtems-users

Re: GCC SPARC FPU issue status

2009/9/1 Joel Sherrill <joel.sherrill@...>:
> So the proper solution until GCC is fixed is to turn on the cpu.h define
> that says all tasks are floating point.

... and don't write ISRs, right?

Ingolf
_______________________________________________
rtems-users mailing list
rtems-users@...
http://www.rtems.org/mailman/listinfo/rtems-users

Re: GCC SPARC FPU issue status

Ingolf Steinbach wrote:
> 2009/9/1 Joel Sherrill <joel.sherrill@...>:
>   
>> So the proper solution until GCC is fixed is to turn on the cpu.h define
>> that says all tasks are floating point.
>>     
>
> ... and don't write ISRs, right?
>   
:)  Until GCC is fixed, you just have to be careful.  And if
you are concerned, object dump the code in question and
look for FPU instructions.  The PowerPC treats all tasks as FP
and disables the FPU on ISRs. 

The true proper solution is to fix gcc.  Being cynical, SPARC
RTEMS users are not hobbyists.  The projects are serious
and should have enough money to pay someone to be
interested in addressing this.  Especially since the space
community isn't paying anything for the OS or tools and
very few contribute in anyway to the project or get
support.

> Ingolf
>   

--

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill@...        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985

_______________________________________________
rtems-users mailing list
rtems-users@...
http://www.rtems.org/mailman/listinfo/rtems-users

AW: GCC SPARC FPU issue status

Hi,

I would say that the RTEMS needs to be compiled with -msoft-float. Also all
ISRs should be compiled with -msoft-float. If the ISR and the RTEMS kernel
does not make use of any floating point operations, this should not be a
problem with lib variants.

The application code can still be compiled without -msoft-float, especially
when it relies on using the FPU due to performance reasons. The task in my
applications have to be flagged RTEMS FP of course.

That's the way I want to do it at OHB.

Regards

Detlev

> -----Ursprüngliche Nachricht-----
> Von: rtems-users-bounces@... [mailto:rtems-users-
> bounces@...] Im Auftrag von Joel Sherrill
> Gesendet: Dienstag, 1. September 2009 15:07
> An: Manuel Coutinho
> Cc: rtems-users@...
> Betreff: Re: GCC SPARC FPU issue status
> 
> Manuel Coutinho wrote:
> >
> > Hi
> >
> >
> >
> > Was checking some mails exchanged in this mailing list a while ago
> > (2006) (http://www.rtems.com/ml/rtems-users/2006/may/msg00040.html)
> > and would like to know if the issue concerning GCC and SPARC floating
> > point registers is now solved or not. Does anybody know the status of
> > this issue? Is there a bug in GCC bugzilla so that we can track this?
> > try to find but with no luck :(
> >
> >
> >
> > Briefly, the problem, as far as I understood, occurs when a function
> > receives multiple arguments: GCC might store some arguments on FPU
> > registers, which could cause all sort of problems, like an invalid
> FPU
> > trap, or an erroneous result on a thread that uses FPU (because the
> > register was changed).
> >
> > This problem could be solved by compiling RTEMS with –msoft-float
> flag
> > and the application without this flag (for the sections that want to
> > use floating point).
> >
> >
> >
> This is fundamentally an incorrect thing to do and why this solution
> has
> never been merged.  You should never never never mix multilib variants
> in the same executable.
> 
> If GCC is generating FPU instructions in unexpected places, then there
> are two solutions:
> 
> + Fix GCC.  This is (in general) a cross target issue which may end up
> having
>     to be fixed in a target specific manner.  I don't know of a PR or
> anyone who
>     is interested in working on this.  It is an issue on at least the
> PowerPC as
>     well and that hasn't attracted any coders willing to address it.
> 
> + Make all tasks in RTEMS FP.  We have resisted this solution because
> it
>     takes time to save the FP state and increases the context switch
> time.
>     But on PowerPC's with FPU, this is how this problem is solved.
> 
> So the proper solution until GCC is fixed is to turn on the cpu.h
> define
> that says all tasks are floating point.
> >
> > It also seams that ERC32 has a different behavior than Leon2 and
> > Leon3: for Leon2 and Leon3, RTEMS does not save/restore hardware FPU
> > during a context switch. Is this correct? Shouldn’t the 3 BSPs have
> > the same behavior? Shouldn’t leon2 and leon3 save/restore the FPU
> > hardware during a context switch?
> >
> >
> >
> I don't see how they could be different.  They use the same context
> switch code.
> Unless you are using some patches we won't merge.
> >
> > (I’m looking at RTEMS 4.8.0)
> >
> >
> >
> > Thanks in advance
> >
> > Kind regards
> >
> > Manuel Coutinho
> >
> >
> >
> 
> 
> --
> Joel Sherrill, Ph.D.             Director of Research & Development
> joel.sherrill@...        On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>    Support Available             (256) 722-9985
> 
> 
> _______________________________________________
> rtems-users mailing list
> rtems-users@...
> http://www.rtems.org/mailman/listinfo/rtems-users

_______________________________________________
rtems-users mailing list
rtems-users@...
http://www.rtems.org/mailman/listinfo/rtems-users

Re: AW: GCC SPARC FPU issue status

Hi,

In the Aeroflex Gaisler toolchain for RTEMS we have added the attached 
patch, written by Konrad Eisele (konrad@...), to avoid the 
problem. The patch adds an optional -ffloat_int_mode flag to GCC which 
disables the strange GCC Floating point behaviour. Function calls with 
more arguments than the argument registers and the low globals are fixed.

The attached patch works for GCC 4.3.3. We are not GCC gurus, I hope 
that someone could rewrite this patch if needed and insert it into GCC 
main line in a clean way.

Please let me know what you think about this patch.

Best Regards,
Daniel Hellstrom
Aeroflex Gaisler

Detlev Schümann wrote:

>Hi,
>
>I would say that the RTEMS needs to be compiled with -msoft-float. Also all
>ISRs should be compiled with -msoft-float. If the ISR and the RTEMS kernel
>does not make use of any floating point operations, this should not be a
>problem with lib variants.
>
>The application code can still be compiled without -msoft-float, especially
>when it relies on using the FPU due to performance reasons. The task in my
>applications have to be flagged RTEMS FP of course.
>
>That's the way I want to do it at OHB.
>
>Regards
>
>Detlev
>
>  
>
>>-----Ursprüngliche Nachricht-----
>>Von: rtems-users-bounces@... [mailto:rtems-users-
>>bounces@...] Im Auftrag von Joel Sherrill
>>Gesendet: Dienstag, 1. September 2009 15:07
>>An: Manuel Coutinho
>>Cc: rtems-users@...
>>Betreff: Re: GCC SPARC FPU issue status
>>
>>Manuel Coutinho wrote:
>>    
>>
>>>Hi
>>>
>>>
>>>
>>>Was checking some mails exchanged in this mailing list a while ago
>>>(2006) (http://www.rtems.com/ml/rtems-users/2006/may/msg00040.html)
>>>and would like to know if the issue concerning GCC and SPARC floating
>>>point registers is now solved or not. Does anybody know the status of
>>>this issue? Is there a bug in GCC bugzilla so that we can track this?
>>>try to find but with no luck :(
>>>
>>>
>>>
>>>Briefly, the problem, as far as I understood, occurs when a function
>>>receives multiple arguments: GCC might store some arguments on FPU
>>>registers, which could cause all sort of problems, like an invalid
>>>      
>>>
>>FPU
>>    
>>
>>>trap, or an erroneous result on a thread that uses FPU (because the
>>>register was changed).
>>>
>>>This problem could be solved by compiling RTEMS with –msoft-float
>>>      
>>>
>>flag
>>    
>>
>>>and the application without this flag (for the sections that want to
>>>use floating point).
>>>
>>>
>>>
>>>      
>>>
>>This is fundamentally an incorrect thing to do and why this solution
>>has
>>never been merged.  You should never never never mix multilib variants
>>in the same executable.
>>
>>If GCC is generating FPU instructions in unexpected places, then there
>>are two solutions:
>>
>>+ Fix GCC.  This is (in general) a cross target issue which may end up
>>having
>>    to be fixed in a target specific manner.  I don't know of a PR or
>>anyone who
>>    is interested in working on this.  It is an issue on at least the
>>PowerPC as
>>    well and that hasn't attracted any coders willing to address it.
>>
>>+ Make all tasks in RTEMS FP.  We have resisted this solution because
>>it
>>    takes time to save the FP state and increases the context switch
>>time.
>>    But on PowerPC's with FPU, this is how this problem is solved.
>>
>>So the proper solution until GCC is fixed is to turn on the cpu.h
>>define
>>that says all tasks are floating point.
>>    
>>
>>>It also seams that ERC32 has a different behavior than Leon2 and
>>>Leon3: for Leon2 and Leon3, RTEMS does not save/restore hardware FPU
>>>during a context switch. Is this correct? Shouldn’t the 3 BSPs have
>>>the same behavior? Shouldn’t leon2 and leon3 save/restore the FPU
>>>hardware during a context switch?
>>>
>>>
>>>
>>>      
>>>
>>I don't see how they could be different.  They use the same context
>>switch code.
>>Unless you are using some patches we won't merge.
>>    
>>
>>>(I’m looking at RTEMS 4.8.0)
>>>
>>>
>>>
>>>Thanks in advance
>>>
>>>Kind regards
>>>
>>>Manuel Coutinho
>>>
>>>
>>>
>>>      
>>>
>>--
>>Joel Sherrill, Ph.D.             Director of Research & Development
>>joel.sherrill@...        On-Line Applications Research
>>Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>>   Support Available             (256) 722-9985
>>
>>
>>_______________________________________________
>>rtems-users mailing list
>>rtems-users@...
>>http://www.rtems.org/mailman/listinfo/rtems-users
>>    
>>
>
>_______________________________________________
>rtems-users mailing list
>rtems-users@...
>http://www.rtems.org/mailman/listinfo/rtems-users
>
>
>  
>

_______________________________________________
rtems-users mailing list
rtems-users@...
http://www.rtems.org/mailman/listinfo/rtems-users

Re: AW: GCC SPARC FPU issue status

I would suggest that the flag is enabled by default, by changing

+int flag_ffloat_int_mode = 0;

to

+int flag_ffloat_int_mode = 1;

In this way, we would not need to update the make scripts for SPARC.

Jiri.

Daniel Hellstrom wrote:
> Hi,
> 
> In the Aeroflex Gaisler toolchain for RTEMS we have added the attached 
> patch, written by Konrad Eisele (konrad@...), to avoid the 
> problem. The patch adds an optional -ffloat_int_mode flag to GCC which 
> disables the strange GCC Floating point behaviour. Function calls with 
> more arguments than the argument registers and the low globals are fixed.
> 
> The attached patch works for GCC 4.3.3. We are not GCC gurus, I hope 
> that someone could rewrite this patch if needed and insert it into GCC 
> main line in a clean way.
> 
> Please let me know what you think about this patch.
> 
> Best Regards,
> Daniel Hellstrom
> Aeroflex Gaisler
> 
> 
> 
> Detlev Schümann wrote:
> 
>> Hi,
>>
>> I would say that the RTEMS needs to be compiled with -msoft-float. 
>> Also all
>> ISRs should be compiled with -msoft-float. If the ISR and the RTEMS 
>> kernel
>> does not make use of any floating point operations, this should not be a
>> problem with lib variants.
>>
>> The application code can still be compiled without -msoft-float, 
>> especially
>> when it relies on using the FPU due to performance reasons. The task 
>> in my
>> applications have to be flagged RTEMS FP of course.
>>
>> That's the way I want to do it at OHB.
>>
>> Regards
>>
>> Detlev
>>
>>  
>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: rtems-users-bounces@... [mailto:rtems-users-
>>> bounces@...] Im Auftrag von Joel Sherrill
>>> Gesendet: Dienstag, 1. September 2009 15:07
>>> An: Manuel Coutinho
>>> Cc: rtems-users@...
>>> Betreff: Re: GCC SPARC FPU issue status
>>>
>>> Manuel Coutinho wrote:
>>>   
>>>> Hi
>>>>
>>>>
>>>>
>>>> Was checking some mails exchanged in this mailing list a while ago
>>>> (2006) (http://www.rtems.com/ml/rtems-users/2006/may/msg00040.html)
>>>> and would like to know if the issue concerning GCC and SPARC floating
>>>> point registers is now solved or not. Does anybody know the status of
>>>> this issue? Is there a bug in GCC bugzilla so that we can track this?
>>>> try to find but with no luck :(
>>>>
>>>>
>>>>
>>>> Briefly, the problem, as far as I understood, occurs when a function
>>>> receives multiple arguments: GCC might store some arguments on FPU
>>>> registers, which could cause all sort of problems, like an invalid
>>>>     
>>> FPU
>>>   
>>>> trap, or an erroneous result on a thread that uses FPU (because the
>>>> register was changed).
>>>>
>>>> This problem could be solved by compiling RTEMS with –msoft-float
>>>>     
>>> flag
>>>   
>>>> and the application without this flag (for the sections that want to
>>>> use floating point).
>>>>
>>>>
>>>>
>>>>     
>>> This is fundamentally an incorrect thing to do and why this solution
>>> has
>>> never been merged.  You should never never never mix multilib variants
>>> in the same executable.
>>>
>>> If GCC is generating FPU instructions in unexpected places, then there
>>> are two solutions:
>>>
>>> + Fix GCC.  This is (in general) a cross target issue which may end up
>>> having
>>>    to be fixed in a target specific manner.  I don't know of a PR or
>>> anyone who
>>>    is interested in working on this.  It is an issue on at least the
>>> PowerPC as
>>>    well and that hasn't attracted any coders willing to address it.
>>>
>>> + Make all tasks in RTEMS FP.  We have resisted this solution because
>>> it
>>>    takes time to save the FP state and increases the context switch
>>> time.
>>>    But on PowerPC's with FPU, this is how this problem is solved.
>>>
>>> So the proper solution until GCC is fixed is to turn on the cpu.h
>>> define
>>> that says all tasks are floating point.
>>>   
>>>> It also seams that ERC32 has a different behavior than Leon2 and
>>>> Leon3: for Leon2 and Leon3, RTEMS does not save/restore hardware FPU
>>>> during a context switch. Is this correct? Shouldn’t the 3 BSPs have
>>>> the same behavior? Shouldn’t leon2 and leon3 save/restore the FPU
>>>> hardware during a context switch?
>>>>
>>>>
>>>>
>>>>     
>>> I don't see how they could be different.  They use the same context
>>> switch code.
>>> Unless you are using some patches we won't merge.
>>>   
>>>> (I’m looking at RTEMS 4.8.0)
>>>>
>>>>
>>>>
>>>> Thanks in advance
>>>>
>>>> Kind regards
>>>>
>>>> Manuel Coutinho
>>>>
>>>>
>>>>
>>>>     
>>> -- 
>>> Joel Sherrill, Ph.D.             Director of Research & Development
>>> joel.sherrill@...        On-Line Applications Research
>>> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>>>   Support Available             (256) 722-9985
>>>
>>>
>>> _______________________________________________
>>> rtems-users mailing list
>>> rtems-users@...
>>> http://www.rtems.org/mailman/listinfo/rtems-users
>>>   
>>
>> _______________________________________________
>> rtems-users mailing list
>> rtems-users@...
>> http://www.rtems.org/mailman/listinfo/rtems-users
>>
>>
>>  
>>
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> rtems-users mailing list
> rtems-users@...
> http://www.rtems.org/mailman/listinfo/rtems-users
_______________________________________________
rtems-users mailing list
rtems-users@...
http://www.rtems.org/mailman/listinfo/rtems-users

RES: AW: GCC SPARC FPU issue status

Hi,

Nice patch.

What if the flag "int flag_ffloat_int_mode = 1" instead of "int flag_ffloat_int_mode = 0" by default? So,
updating in the makefiles is not need. 

Regards,

Wendell Pereira da Silva

COMPSIS... Computadores e Sistemas Ind. e Com. Ltda.
Aerospace Systems
Site: www.compsisnet.com.br
E-mail: wendell.silva@...
Phone: +55 12-2139-3966, ext. 977

-----Mensagem original-----
De: rtems-users-bounces@...
[mailto:rtems-users-bounces@...] Em nome de Daniel Hellstrom
Enviada em: terça-feira, 1 de setembro de 2009 11:04
Para: Detlev Schümann
Cc: rtems-users@...
Assunto: Re: AW: GCC SPARC FPU issue status

Hi,

In the Aeroflex Gaisler toolchain for RTEMS we have added the attached 
patch, written by Konrad Eisele (konrad@...), to avoid the 
problem. The patch adds an optional -ffloat_int_mode flag to GCC which 
disables the strange GCC Floating point behaviour. Function calls with 
more arguments than the argument registers and the low globals are fixed.

The attached patch works for GCC 4.3.3. We are not GCC gurus, I hope 
that someone could rewrite this patch if needed and insert it into GCC 
main line in a clean way.

Please let me know what you think about this patch.

Best Regards,
Daniel Hellstrom
Aeroflex Gaisler

Detlev Schümann wrote:

>Hi,
>
>I would say that the RTEMS needs to be compiled with -msoft-float. Also all
>ISRs should be compiled with -msoft-float. If the ISR and the RTEMS kernel
>does not make use of any floating point operations, this should not be a
>problem with lib variants.
>
>The application code can still be compiled without -msoft-float, especially
>when it relies on using the FPU due to performance reasons. The task in my
>applications have to be flagged RTEMS FP of course.
>
>That's the way I want to do it at OHB.
>
>Regards
>
>Detlev
>
>  
>
>>-----Ursprüngliche Nachricht-----
>>Von: rtems-users-bounces@... [mailto:rtems-users-
>>bounces@...] Im Auftrag von Joel Sherrill
>>Gesendet: Dienstag, 1. September 2009 15:07
>>An: Manuel Coutinho
>>Cc: rtems-users@...
>>Betreff: Re: GCC SPARC FPU issue status
>>
>>Manuel Coutinho wrote:
>>    
>>
>>>Hi
>>>
>>>
>>>
>>>Was checking some mails exchanged in this mailing list a while ago
>>>(2006) (http://www.rtems.com/ml/rtems-users/2006/may/msg00040.html)
>>>and would like to know if the issue concerning GCC and SPARC floating
>>>point registers is now solved or not. Does anybody know the status of
>>>this issue? Is there a bug in GCC bugzilla so that we can track this?
>>>try to find but with no luck :(
>>>
>>>
>>>
>>>Briefly, the problem, as far as I understood, occurs when a function
>>>receives multiple arguments: GCC might store some arguments on FPU
>>>registers, which could cause all sort of problems, like an invalid
>>>      
>>>
>>FPU
>>    
>>
>>>trap, or an erroneous result on a thread that uses FPU (because the
>>>register was changed).
>>>
>>>This problem could be solved by compiling RTEMS with -msoft-float
>>>      
>>>
>>flag
>>    
>>
>>>and the application without this flag (for the sections that want to
>>>use floating point).
>>>
>>>
>>>
>>>      
>>>
>>This is fundamentally an incorrect thing to do and why this solution
>>has
>>never been merged.  You should never never never mix multilib variants
>>in the same executable.
>>
>>If GCC is generating FPU instructions in unexpected places, then there
>>are two solutions:
>>
>>+ Fix GCC.  This is (in general) a cross target issue which may end up
>>having
>>    to be fixed in a target specific manner.  I don't know of a PR or
>>anyone who
>>    is interested in working on this.  It is an issue on at least the
>>PowerPC as
>>    well and that hasn't attracted any coders willing to address it.
>>
>>+ Make all tasks in RTEMS FP.  We have resisted this solution because
>>it
>>    takes time to save the FP state and increases the context switch
>>time.
>>    But on PowerPC's with FPU, this is how this problem is solved.
>>
>>So the proper solution until GCC is fixed is to turn on the cpu.h
>>define
>>that says all tasks are floating point.
>>    
>>
>>>It also seams that ERC32 has a different behavior than Leon2 and
>>>Leon3: for Leon2 and Leon3, RTEMS does not save/restore hardware FPU
>>>during a context switch. Is this correct? Shouldn't the 3 BSPs have
>>>the same behavior? Shouldn't leon2 and leon3 save/restore the FPU
>>>hardware during a context switch?
>>>
>>>
>>>
>>>      
>>>
>>I don't see how they could be different.  They use the same context
>>switch code.
>>Unless you are using some patches we won't merge.
>>    
>>
>>>(I'm looking at RTEMS 4.8.0)
>>>
>>>
>>>
>>>Thanks in advance
>>>
>>>Kind regards
>>>
>>>Manuel Coutinho
>>>
>>>
>>>
>>>      
>>>
>>--
>>Joel Sherrill, Ph.D.             Director of Research & Development
>>joel.sherrill@...        On-Line Applications Research
>>Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>>   Support Available             (256) 722-9985
>>
>>
>>_______________________________________________
>>rtems-users mailing list
>>rtems-users@...
>>http://www.rtems.org/mailman/listinfo/rtems-users
>>    
>>
>
>_______________________________________________
>rtems-users mailing list
>rtems-users@...
>http://www.rtems.org/mailman/listinfo/rtems-users
>
>
>  
>

_______________________________________________
rtems-users mailing list
rtems-users@...
http://www.rtems.org/mailman/listinfo/rtems-users