Menu
▾
▴
avr32-libc-devel — Mailing list for developers.
You can subscribe to this list here.
| 2010 |
Jan
|
Feb
|
Mar
(13) |
Apr
(2) |
May
|
Jun
(3) |
Jul
(20) |
Aug
(2) |
Sep
(33) |
Oct
(2) |
Nov
|
Dec
|
|---|
|
From: SourceForge.net <no...@so...> - 2010-09-30 08:13:15
|
To Do item #3078531, was opened at 2010-09-30 13:43 Message generated for change (Tracker Item Submitted) made by usha-gupta You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1478956&aid=3078531&group_id=251959 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Usha Gupta (usha-gupta) Assigned to: Nobody/Anonymous (nobody) Summary: libm : tanh Initial Comment: Yet to be implemented ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1478956&aid=3078531&group_id=251959 |
|
From: SourceForge.net <no...@so...> - 2010-09-30 08:12:50
|
To Do item #3078530, was opened at 2010-09-30 13:42 Message generated for change (Tracker Item Submitted) made by usha-gupta You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1478956&aid=3078530&group_id=251959 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Usha Gupta (usha-gupta) Assigned to: Nobody/Anonymous (nobody) Summary: libm : sinh function Initial Comment: Yet to be implemented ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1478956&aid=3078530&group_id=251959 |
|
From: SourceForge.net <no...@so...> - 2010-09-30 08:11:53
|
To Do item #3078529, was opened at 2010-09-30 13:41 Message generated for change (Tracker Item Submitted) made by usha-gupta You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1478956&aid=3078529&group_id=251959 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Usha Gupta (usha-gupta) Assigned to: Nobody/Anonymous (nobody) Summary: libm : cosh function Initial Comment: Yet to be implemented ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1478956&aid=3078529&group_id=251959 |
|
From: SourceForge.net <no...@so...> - 2010-09-30 08:11:09
|
To Do item #3078527, was opened at 2010-09-30 13:41 Message generated for change (Tracker Item Submitted) made by usha-gupta You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1478956&aid=3078527&group_id=251959 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Usha Gupta (usha-gupta) Assigned to: Nobody/Anonymous (nobody) Summary: libm : atan2 function Initial Comment: Yet to be implemented ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1478956&aid=3078527&group_id=251959 |
|
From: SourceForge.net <no...@so...> - 2010-09-30 08:09:49
|
To Do item #3078525, was opened at 2010-09-30 13:39 Message generated for change (Tracker Item Submitted) made by usha-gupta You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1478956&aid=3078525&group_id=251959 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Usha Gupta (usha-gupta) Assigned to: Nobody/Anonymous (nobody) Summary: libm : atan function Initial Comment: Yet to be implemented ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1478956&aid=3078525&group_id=251959 |
|
From: SourceForge.net <no...@so...> - 2010-09-30 08:08:48
|
To Do item #3078524, was opened at 2010-09-30 13:38 Message generated for change (Tracker Item Submitted) made by usha-gupta You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1478956&aid=3078524&group_id=251959 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Usha Gupta (usha-gupta) Assigned to: Nobody/Anonymous (nobody) Summary: libm : acos function Initial Comment: Yet to be implemented ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1478956&aid=3078524&group_id=251959 |
|
From: SourceForge.net <no...@so...> - 2010-09-30 08:07:53
|
To Do item #3078521, was opened at 2010-09-30 13:37 Message generated for change (Tracker Item Submitted) made by usha-gupta You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1478956&aid=3078521&group_id=251959 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Usha Gupta (usha-gupta) Assigned to: Nobody/Anonymous (nobody) Summary: libm : asin function Initial Comment: Yet to be implemented ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1478956&aid=3078521&group_id=251959 |
|
From: SourceForge.net <no...@so...> - 2010-09-30 08:06:34
|
To Do item #3078520, was opened at 2010-09-30 13:36 Message generated for change (Tracker Item Submitted) made by usha-gupta You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1478956&aid=3078520&group_id=251959 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Usha Gupta (usha-gupta) Assigned to: Nobody/Anonymous (nobody) Summary: libm: tan function Initial Comment: Yet to be implemented ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1478956&aid=3078520&group_id=251959 |
|
From: SourceForge.net <no...@so...> - 2010-09-30 08:05:27
|
To Do item #3078519, was opened at 2010-09-30 13:35 Message generated for change (Tracker Item Submitted) made by usha-gupta You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1478956&aid=3078519&group_id=251959 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Usha Gupta (usha-gupta) Assigned to: Nobody/Anonymous (nobody) Summary: libm: sin function Initial Comment: Yet to be implemented ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1478956&aid=3078519&group_id=251959 |
|
From: SourceForge.net <no...@so...> - 2010-09-30 08:00:10
|
To Do item #3078512, was opened at 2010-09-30 13:30 Message generated for change (Tracker Item Submitted) made by usha-gupta You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1478956&aid=3078512&group_id=251959 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Usha Gupta (usha-gupta) Assigned to: Nobody/Anonymous (nobody) Summary: libm: cos function Initial Comment: Yet to be implemented ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1478956&aid=3078512&group_id=251959 |
|
From: Weddington, E. <Eri...@at...> - 2010-08-22 17:50:41
|
Hi Usha, Praveen, For the avr32-libc project, I'd like for you both to work on the following items: 1. Create a 'bootstrap' script for the top-level directory. This should be like the bootstrap script in avr-libc. This should run the auto* tools correctly. I want to make sure that the COPYING file does not get created as the license for avr32-libc is the BSD license (not GPL). 2. Integrate the existing libm work into the build system and commit it to the repository. 3. Doxygen documentation. See here: http://www.stack.nl/~dimitri/doxygen/ We need to start documenting avr32-libc using doxygen, and make sure that it can be built. See the avr-libc project on how it is done there. The documents don't have to look exactly like avr-libc, but we need to able to build the documents and start documenting the existing functionality. 4. Verify that the BSD license is on all of the source code files. This should be committed in the repository. Thanks, Eric Weddington |
|
From: Mainchain, S. <ste...@at...> - 2010-08-05 12:43:13
|
Hi, > I would think that the math library for avr32-libc does NOT need to be > multi-standard compliant; It will be used in embedded systems with > typically a single application run on the AVR32 processor. But of course > we need to be compliant to SOME standard. > > Because we're not particularly tied to any thing with Unix, I would think > that we should comply to the IEEE standard. But I would like to hear > thoughts from others on this, especially from the folks in Nantes > (Stephane?). Yes, I agree, IEEE 754 compliance would be enough from what I've seen. This seems to be also the case in IAR EW32. > Eric Weddington Stephane. |
|
From: Weddington, E. <Eri...@at...> - 2010-07-30 00:51:39
|
> -----Original Message----- > From: Gupta, Usha [mailto:Ush...@at...] > Sent: Thursday, July 29, 2010 6:09 AM > To: avr...@li... > Subject: [avr32-libc-devel] Libm algorithms > > Hi All, > > > > While looking for algorithms for libm routines, I came across > those based on Polynomial approximations. > > > > For trigonometric functions we can use > > 1) Range reduction (i.e from [-pi,pi] to [-pi/4,pi/4]) > along with table lookup for the smaller range. > > The range is reduced using the periodicity and symmetry > found in these trigonometric functions. > > 2) Range reduction and polynomial approximation for the > smaller range. > > > > Kindly provide me with suggestions on this. IMO, code size will be the most important priority. So select whichever algorithm that provides the best accuracy at the smallest size. Eric Weddington |
|
From: Gupta, U. <Ush...@at...> - 2010-07-29 12:38:28
|
Hi All, While looking for algorithms for libm routines, I came across those based on Polynomial approximations. For trigonometric functions we can use 1) Range reduction (i.e from [-pi,pi] to [-pi/4,pi/4]) along with table lookup for the smaller range. The range is reduced using the periodicity and symmetry found in these trigonometric functions. 2) Range reduction and polynomial approximation for the smaller range. Kindly provide me with suggestions on this. Thanks and Regards Usha Gupta |
|
From: Weddington, E. <Eri...@at...> - 2010-07-29 03:16:43
|
> -----Original Message----- > From: Gupta, Usha [mailto:Ush...@at...] > Sent: Wednesday, July 28, 2010 2:27 AM > To: avr...@li... > Cc: Mainchain, Stephane > Subject: Re: [avr32-libc-devel] Summary of functions > innewlib'slibmandfloating point support in AVR32 > > > > >From the above, it looks like the default library > version would be > > IEEE. > > > Can you verify this? Remember that we're using a patched Newlib > > > 1.16.0, not the latest version of Newlib. If we are using > the IEEE > > > version by default, then this would simplify > implementation of the > > > math library for avr32-libc. > > Does math library for avr32-libc need to be multi-standard > compliant as Newlib?? That's a very good question. I would think that the math library for avr32-libc does NOT need to be multi-standard compliant; It will be used in embedded systems with typically a single application run on the AVR32 processor. But of course we need to be compliant to SOME standard. Because we're not particularly tied to any thing with Unix, I would think that we should comply to the IEEE standard. But I would like to hear thoughts from others on this, especially from the folks in Nantes (Stephane?). Eric Weddington |
|
From: Gupta, U. <Ush...@at...> - 2010-07-28 08:27:12
|
> > >From the above, it looks like the default library version would be > IEEE. > > Can you verify this? Remember that we're using a patched Newlib > > 1.16.0, not the latest version of Newlib. If we are using the IEEE > > version by default, then this would simplify implementation of the > > math library for avr32-libc. Does math library for avr32-libc need to be multi-standard compliant as Newlib?? > > > The versions of the library differ only in how errors are handled. This webpage gives information on Standards Compliance. Table E-1(Exceptional cases and libm functions) shows the exceptional input values for libm functions and their return values under different standards. http://docs.sun.com/source/806-3568/ncg_compliance.html This is how Newlib also handles exceptional input values. > -----Original Message----- > From: Gupta, Usha [mailto:Ush...@at...] > Sent: Tuesday, July 27, 2010 12:36 PM > To: Weddington, Eric; usha gupta; avr...@li... > Cc: Mainchain, Stephane > Subject: Re: [avr32-libc-devel] Summary of functions in > newlib'slibmandfloating point support in AVR32 > > > > > -----Original Message----- > > From: Weddington, Eric [mailto:Eri...@at...] > > Sent: Tuesday, July 27, 2010 2:51 AM > > To: usha gupta; avr...@li... > > Cc: Mainchain, Stephane > > Subject: Re: [avr32-libc-devel] Summary of functions in newlib's > > libmandfloating point support in AVR32 > > > > > > > > > > > -----Original Message----- > > > From: usha gupta [mailto:ush...@gm...] > > > Sent: Monday, July 26, 2010 6:24 AM > > > To: avr...@li... > > > Subject: [avr32-libc-devel] Summary of functions in newlib's > > > libm andfloating point support in AVR32 > > > > > > Hi All, > > > > > > I have been investigating newlib's libm and floating point > > > support in AVR32 .Here is the information that i have got so > > > far. I would like to discuss on implementation of libm for > > > avr32-libc. > > > > > > > <snip> > > > > > Newlib's libm > > > > > > > > > > > > There are four different versions of the math library > > > routines: IEEE, POSIX, X/Open, or SVID. The version may be > > > selected at runtime by setting the global variable > > > {_LIB_VERSION}, defined in {math.h}. It may be set to one of > > > the following constants defined in {math.h}: {_IEEE_}, > > > {_POSIX_}, {_XOPEN_}, or {_SVID_}. > > > > > > The versions of the library differ only in how errors are handled. > > > > > > Default version is X/Open. > > > > > > > I see that you got the above information from the Newlib manual (recent > > version online). However, compare that to what is found in the actual > > math.h that is being used for the AVR32: > > > > ============================================ > > > > /* Global control over fdlibm error handling. */ > > > > enum __fdlibm_version > > { > > __fdlibm_ieee = -1, > > __fdlibm_svid, > > __fdlibm_xopen, > > __fdlibm_posix > > }; > > > > #define _LIB_VERSION_TYPE enum __fdlibm_version > > #define _LIB_VERSION __fdlib_version > > > > extern __IMPORT _LIB_VERSION_TYPE _LIB_VERSION; > > > > #define _IEEE_ __fdlibm_ieee > > #define _SVID_ __fdlibm_svid > > #define _XOPEN_ __fdlibm_xopen > > #define _POSIX_ __fdlibm_posix > > > > ============================================ > > > > >From the above, it looks like the default library version would be > IEEE. > > Can you verify this? Remember that we're using a patched Newlib 1.16.0, > > not the latest version of Newlib. If we are using the IEEE version by > > default, then this would simplify implementation of the math library for > > avr32-libc. > > Looking at file "newlib-1.16.0/newlib/libm/common/s_lib_ver.c", the > default is _IEEE_ but it includes fdlibm.h which defines _XOPEN_MODE which > makes _XOPEN_ as default. > > ========================================================================== > == > /*s_lib_ver.c*/ > > #include "fdlibm.h" > > /* > * define and initialize _LIB_VERSION > */ > #ifdef _POSIX_MODE > _LIB_VERSION_TYPE _LIB_VERSION = _POSIX_; > #else > #ifdef _XOPEN_MODE > _LIB_VERSION_TYPE _LIB_VERSION = _XOPEN_; > #else > #ifdef _SVID3_MODE > _LIB_VERSION_TYPE _LIB_VERSION = _SVID_; > #else /* default _IEEE_MODE */ > _LIB_VERSION_TYPE _LIB_VERSION = _IEEE_; > #endif > #endif > #endif > ========================================================================== > == > ========================================================================== > == > /* fdlibm.h*/ > /* REDHAT LOCAL: Default to XOPEN_MODE. */ > #define _XOPEN_MODE > ========================================================================== > == > > All the functions in Newlib's libm includes "fdlibm.h". I have verified in > the patched version of Newlib for avr32. > > -------------------------------------------------------------------------- > ---- > The Palm PDK Hot Apps Program offers developers who use the > Plug-In Development Kit to bring their C/C++ apps to Palm for a share > of $1 Million in cash or HP Products. Visit us here for more details: > http://ad.doubleclick.net/clk;226879339;13503038;l? > http://clk.atdmt.com/CRS/go/247765532/direct/01/ > _______________________________________________ > avr32-libc-devel mailing list > avr...@li... > https://lists.sourceforge.net/lists/listinfo/avr32-libc-devel |
|
From: Kaushik, P. <Pra...@at...> - 2010-07-27 10:58:21
|
> -----Original Message----- > From: Weddington, Eric > Sent: Saturday, July 24, 2010 2:54 AM > To: Kaushik, Praveen_Kumar; 'avr...@li...' > Subject: RE: [avr32-libc-devel] Memory allocation design for AVR32 Libc > > > > > -----Original Message----- > > From: Kaushik, Praveen_Kumar > > Sent: Friday, July 23, 2010 3:29 AM > > To: Weddington, Eric; 'avr...@li...' > > Subject: RE: [avr32-libc-devel] Memory allocation design for > > AVR32 Libc > > > > As each OS handles the memory allocation in different manner, > > so we need to look at their memory management techniques. So > > can you provide me a list of all the operating systems > > supported by our tool chain? > > I'm not sure that there is a comprehensive list. Looking at the Atmel web > site, I see that uCOS/II is available for the AVR32. I seem to recall > FreeRTOS is available for the AVR32. > > But we shouldn't tailor the memory allocation routines for just those > operating systems. I wouldn't want to limit the customers choice in > operating systems for the future. We need to come up with a decent, > generic memory allocation routines that will work for RTOSes as well as > applications that don't use an RTOS. > > Do you think that this could be done? > I am not sure if a single implementation can work for all RTOS and no OS situations as well. I went through uC/OS-II and freeRTOS's way of handling dynamic memory allocation. uC/OS-II provides alternatives to malloc () and free () and freeRTOS provides three ways of handling this. First one simply allows you to allocate memory but not freeing them up. Second way is we can allocate and free but in fixed size block and not in random size. Third one just provides the wrapper functions to the memory allocation functions which are same as implemented for no OS case. I am not much familiar with RTOSes so I am not sure whether all the supported RTOS provide their own alternatives to allocation functions. If they do, we can skip these functions while building library for these OS. Can anyone provide me with the pointers for further information on dynamic memory allocation in case of RTOS or should I first work on the implementation of allocation functions for no OS and Linux only and we can add support for RTOS afterwards. Regards, Praveen Kaushik |
|
From: Gupta, U. <Ush...@at...> - 2010-07-27 07:06:02
|
> -----Original Message-----
> From: Weddington, Eric [mailto:Eri...@at...]
> Sent: Tuesday, July 27, 2010 2:51 AM
> To: usha gupta; avr...@li...
> Cc: Mainchain, Stephane
> Subject: Re: [avr32-libc-devel] Summary of functions in newlib's
> libmandfloating point support in AVR32
>
>
>
>
> > -----Original Message-----
> > From: usha gupta [mailto:ush...@gm...]
> > Sent: Monday, July 26, 2010 6:24 AM
> > To: avr...@li...
> > Subject: [avr32-libc-devel] Summary of functions in newlib's
> > libm andfloating point support in AVR32
> >
> > Hi All,
> >
> > I have been investigating newlib's libm and floating point
> > support in AVR32 .Here is the information that i have got so
> > far. I would like to discuss on implementation of libm for
> > avr32-libc.
> >
>
> <snip>
>
> > Newlib's libm
> >
> >
> >
> > There are four different versions of the math library
> > routines: IEEE, POSIX, X/Open, or SVID. The version may be
> > selected at runtime by setting the global variable
> > {_LIB_VERSION}, defined in {math.h}. It may be set to one of
> > the following constants defined in {math.h}: {_IEEE_},
> > {_POSIX_}, {_XOPEN_}, or {_SVID_}.
> >
> > The versions of the library differ only in how errors are handled.
> >
> > Default version is X/Open.
> >
>
> I see that you got the above information from the Newlib manual (recent
> version online). However, compare that to what is found in the actual
> math.h that is being used for the AVR32:
>
> ============================================
>
> /* Global control over fdlibm error handling. */
>
> enum __fdlibm_version
> {
> __fdlibm_ieee = -1,
> __fdlibm_svid,
> __fdlibm_xopen,
> __fdlibm_posix
> };
>
> #define _LIB_VERSION_TYPE enum __fdlibm_version
> #define _LIB_VERSION __fdlib_version
>
> extern __IMPORT _LIB_VERSION_TYPE _LIB_VERSION;
> #define _IEEE_ __fdlibm_ieee
> #define _SVID_ __fdlibm_svid
> #define _XOPEN_ __fdlibm_xopen
> #define _POSIX_ __fdlibm_posix
>
> ============================================
>
> >From the above, it looks like the default library version would be IEEE.
> Can you verify this? Remember that we're using a patched Newlib 1.16.0,
> not the latest version of Newlib. If we are using the IEEE version by
> default, then this would simplify implementation of the math library for
> avr32-libc.
Looking at file "newlib-1.16.0/newlib/libm/common/s_lib_ver.c", the default is _IEEE_ but it includes fdlibm.h which defines _XOPEN_MODE which makes _XOPEN_ as default.
============================================================================
/*s_lib_ver.c*/
#include "fdlibm.h"
/*
* define and initialize _LIB_VERSION
*/
#ifdef _POSIX_MODE
_LIB_VERSION_TYPE _LIB_VERSION = _POSIX_;
#else
#ifdef _XOPEN_MODE
_LIB_VERSION_TYPE _LIB_VERSION = _XOPEN_;
#else
#ifdef _SVID3_MODE
_LIB_VERSION_TYPE _LIB_VERSION = _SVID_;
#else /* default _IEEE_MODE */
_LIB_VERSION_TYPE _LIB_VERSION = _IEEE_;
#endif
#endif
#endif
============================================================================
============================================================================
/* fdlibm.h*/
/* REDHAT LOCAL: Default to XOPEN_MODE. */
#define _XOPEN_MODE
============================================================================
All the functions in Newlib's libm includes "fdlibm.h". I have verified in the patched version of Newlib for avr32.
|
|
From: Weddington, E. <Eri...@at...> - 2010-07-26 21:21:12
|
> -----Original Message-----
> From: usha gupta [mailto:ush...@gm...]
> Sent: Monday, July 26, 2010 6:24 AM
> To: avr...@li...
> Subject: [avr32-libc-devel] Summary of functions in newlib's
> libm andfloating point support in AVR32
>
> Hi All,
>
> I have been investigating newlib's libm and floating point
> support in AVR32 .Here is the information that i have got so
> far. I would like to discuss on implementation of libm for
> avr32-libc.
>
<snip>
> Newlib's libm
>
>
>
> There are four different versions of the math library
> routines: IEEE, POSIX, X/Open, or SVID. The version may be
> selected at runtime by setting the global variable
> {_LIB_VERSION}, defined in {math.h}. It may be set to one of
> the following constants defined in {math.h}: {_IEEE_},
> {_POSIX_}, {_XOPEN_}, or {_SVID_}.
>
> The versions of the library differ only in how errors are handled.
>
> Default version is X/Open.
>
I see that you got the above information from the Newlib manual (recent version online). However, compare that to what is found in the actual math.h that is being used for the AVR32:
============================================
/* Global control over fdlibm error handling. */
enum __fdlibm_version
{
__fdlibm_ieee = -1,
__fdlibm_svid,
__fdlibm_xopen,
__fdlibm_posix
};
#define _LIB_VERSION_TYPE enum __fdlibm_version
#define _LIB_VERSION __fdlib_version
extern __IMPORT _LIB_VERSION_TYPE _LIB_VERSION;
#define _IEEE_ __fdlibm_ieee
#define _SVID_ __fdlibm_svid
#define _XOPEN_ __fdlibm_xopen
#define _POSIX_ __fdlibm_posix
============================================
>From the above, it looks like the default library version would be IEEE. Can you verify this? Remember that we're using a patched Newlib 1.16.0, not the latest version of Newlib. If we are using the IEEE version by default, then this would simplify implementation of the math library for avr32-libc.
Eric Weddington
|
|
From: usha g. <ush...@gm...> - 2010-07-26 12:23:37
|
Hi All,
I have been investigating newlib's libm and floating point support in AVR32
.Here is the information that i have got so far. I would like to discuss on
implementation of libm for avr32-libc.
**
*AVR32 Floating point support*
Three revisions of the AVR32UC CPU currently exist:
• Revision 1 implementing revision 1 of the AVR32 architecture.
• Revision 2 implementing revision 2 of the AVR32 architecture, and with a
faster divider.
• Revision 3 implementing revision 3 of the AVR32 architecture, and with
optional floating-point hardware.
*Floating-Point Hardware in AVR32UC*
-AVR32UC optionally supports Floating-Point Hardware implemented as
coprocessor instructions.(coprocessor 0)
-The CONFIG0 system register F bit indicates if floating-point hardware is
present on a specific AVR32 device.
-Floating-point compare updates the flags in the AVR32 Status Register, so
that the regular AVR32 branch
instructions can be used directly after a floatingpoint compare.
-The floating-point hardware consists of a fused multiply-accumulate unit.
- Hardware is also provided to convert between integer and floating-point,
- to compare floating-point values
- and to provide initial approximations for reciprocal and reciprocal square
root
-The round-to-nearest, ties to even rounding mode is used for all
instructions except float-to-integer conversions. Float-to-integer
conversions use the round-to-zero mode.
-The hardware supports denormal numbers.
-Signalling NaN are not provided, all NaN are non-signalling (quiet). NaNs
are not propagated, the default quiet NaN is always returned (0x7FC00000).
-No floating-point exceptions are generated
*Floating point Operations*
-no special floating-point data transfer instructions are required
*NOTE:*
Section 4.2 and 4.3 of AVR32UC Technical Reference Manual can be looked into
for instruction set and compare and check operations provided by AVR32UC
*AVR32AP *doest not have an fpu implemented
* *
*Standard Math library routines*
Trigonometric functions:
cos Compute cosine (function)
sin Compute sine (function)
tan Compute tangent (function)
acos Compute arc cosine (function)
asin Compute arc sine (function)
atan Compute arc tangent (function)
atan2 Compute arc tangent with two parameters (function)
Hyperbolic functions:
cosh Compute hyperbolic cosine (function)
sinh Compute hyperbolic sine (function)
tanh Compute hyperbolic tangent (function)
Exponential and logarithmic functions:
exp Compute exponential function (function)
frexp Get significand and exponent (function)
ldexp Generate number from significand and exponent (function)
log Compute natural logarithm (function)
log10 Compute common logarithm (function)
modf Break into fractional and integral parts (function)
Power functions
pow Raise to power (function)
sqrt Compute square root (function)
Rounding, absolute value and remainder functions:
ceil Round up value (function)
fabs Compute absolute value (function)
floor Round down value (function)
fmod Compute remainder of division (function)
* *
*Newlib’s libm*
* *
There are four different versions of the math library routines: IEEE, POSIX,
X/Open, or SVID. The version may be selected at runtime by setting the
global variable {_LIB_VERSION}, defined in {math.h}. It may be set to one
of the following constants defined in {math.h}: {_IEEE_}, {_POSIX_},
{_XOPEN_}, or {_SVID_}.
The versions of the library differ only in how errors are handled.
Default version is X/Open.
*Standard Math library routines in Newlib*
The list below gives the functions present in different directories. Two
directories namely math/ and mathfp/ has different implementation for the
same functions. The function names are listed along with the directory
names.
*cos()
math/*
*k_cos.c- _kernel_cos()* – * *The range is [-pi/4,pi/4]; function returning
double
*kf_cos.c- _kernel_cosf()* – * *The range is [-pi/4,pi/4] ;function
returning float
*s_cos.c- cos()* – * *The range is [-pi,pi]
*sf_cos.c- cosf()* – * *The range is [-pi,pi]
*mathfp/*
*s_cos.c- cos()* –* *It calls sine(x,1) which is declared in zmath.h.
*sf_cos.c- cosf()* – calls sinef(x,1)
*sin()*
*math/*
*k_sin.c- _kernel_sin()* – * *The range is [-pi/4,pi/4]; function returning
double
*kf_sin.c- _kernel_sinf()* – * *The range is [-pi/4,pi/4] ;function
returning float
*s_sin.c- sin()* – * *The range is [-pi,pi]
*sf_sin.c- sinf()* – * *The range is [-pi,pi]
*mathfp/*
*s_sin.c- sin()* –* *It calls sine(x,0) which is declared in zmath.h.
*sf_sin.c- sinf()* – calls sinef(x,0)
*tan()*
*math/*
*k_tan.c- _kernel_tan()* – * *takes 3 arguments. The range is [-pi/4,pi/4];
function returning double
*kf_tan.c- _kernel_tanf()* – * *The range is [-pi/4,pi/4] ;function
returning float
*s_tan.c- tan()* – * *The range is [-pi,pi]
*sf_tan.c- tanf()* – * *The range is [-pi,pi]
*mathfp/*
*s_tan.c- tan()*
*sf_tan.c- tanf()*
*acos()*
*math/*
*e_acos.c- __ieee754_acos()*
*ef_acos.c- __ieee754_acosf()*
*w_acos.c- acos()*
*wf_acos.c- acosf()*
*mathfp/*
*s_acos.c- acos()* –* *It calls asine(x,1) which is declared in zmath.h.
*sf_acos.c- acosf()* – calls asinef(x,1)
* *
*asin()*
*math/*
*e_asin.c- __ieee754_asin()*
*ef_asin.c- __ieee754_asinf()*
*w_asin.c- asin()*
*wf_asin.c- asinf()*
*mathfp/*
*s_asin.c- asin()* –* *It calls asine(x,0) which is declared in zmath.h.
*sf_asin.c- asinf()* – calls asinef(x,0)
* *
*atan()*
*math/*
*s_atan.c- atan()*
*sf_atan.c- atanf()*
*mathfp/*
*s_atan.c- atan()- *calls atangent(x,0,0,0)
*sf_atan.c- atanf()* - calls atangentf(x,0,0,0)
*atan2()*
*math/*
*e_atan2.c- __ieee754_atan2()*
*ef_atan2.c- __ieee754_atan2f()*
*w_atan2.c- atan2()*
*wf_atan2.c- atan2f()*
*mathfp/*
*s_atan2.c- atan2()* –* *It calls atangent (0.0, v, u, 1) which is declared
in zmath.h.
*sf_atan2.c- atan2f()* – calls atangentf(0.0, v, u, 1)
*cosh()*
*math/*
*e_cosh.c- __ieee754_cosh()*
*ef_cosh.c- __ieee754_coshf()*
*w_cosh.c- cosh()*
*wf_cosh.c- coshf()*
*mathfp/*
*s_cosh.c- cosh()* –* *It calls sineh ((float) x, 1) which is declared in
zmath.h.
*sf_cosh.c- coshf()* – calls sinehf ((float) x, 1)
*sinh()*
*math/*
*e_sinh.c- __ieee754_sinh()*
*ef_sinh.c- __ieee754_sinhf()*
*w_sinh.c- sinh()*
*wf_sinh.c- sinhf()*
*mathfp/*
*s_sinh.c- sinh()* –* *It calls sineh ((float) x) which is declared in
zmath.h.
*sf_sinh.c- sinhf()* – calls sinehf ((float) x)
*tanh()*
*math/*
*s_tanh.c- tanh()*
*sf_tanh.c- tanhf()*
*mathfp/*
*s_tanh.c- tanh()*
*sf_tanh.c- tanhf()*
*exp()*
*math/*
*e_exp.c- __ieee754_exp()*
*ef_exp.c- __ieee754_expf()*
*w_exp.c- exp()*
*wf_exp.c- expf()*
*w_exp2.c- exp2()- *return pow(2,x)
*wf_exp2.c- exp2f()*
*mathfp/*
*s_exp.c- exp()*
*sf_exp.c- expf()*
*s_exp2.c- exp2()*
*sf_exp2.c- exp2f()*
*frexp()*
*math/*
*s_frexp.c- frexp()*
*sf_frexp.c- frexpf()*
*mathfp/*
*s_frexp.c- frexp()*
*sf_frexp.c- frexpf()*
*ldexp()*
*math/*
*s_ldexp.c- ldexp()*
*sf_ldexp.c- ldexpf()*
*mathfp/*
*s_ldexp.c- ldexp()*
*sf_ldexp.c- ldexpf()*
*log()*
*math/*
*e_log.c- __ieee754_log()*
*ef_log.c- __ieee754_logf()*
*w_log.c- log()*
*wf_log.c- logf()*
*mathfp/*
*s_log.c- log()*
*sf_log.c- logf()*
* *
*log10()*
*math/*
*e_log10.c- __ieee754_log10()*
*ef_log10.c- __ieee754_log10f()*
*w_log10.c- log10()*
*wf_log10.c- log10f()*
*mathfp/*
*s_log10.c- log10()*
*sf_log10.c- log10f()*
*modf()*
*commom/*
*s_modf.c*
*sf_modf.c*
* *
*pow()*
*math/*
*e_pow.c- __ieee754_pow()*
*ef_pow.c- __ieee754_powf()*
*w_pow.c- pow()*
*wf_pow.c- powf()*
*mathfp/*
*s_pow.c- pow()*
*sf_pow.c- powf()*
* *
*sqrt()*
*math/*
*e_sqrt.c- __ieee754_sqrt()*
*ef_sqrt.c- __ieee754_sqrtf()*
*w_sqrt.c- sqrt()*
*wf_sqrt.c- sqrtf()*
*mathfp/*
*s_sqrt.c- sqrt()*
*sf_sqrt.c- sqrtf()*
* *
*ceil()*
*math/*
*s_ceil.c- ceil()*
*sf_ceil.c- ceilf()*
* *
*mathfp/*
*s_ceil.c- ceil()*
*sf_ceil.c- ceilf()*
* *
*floor()*
*math/*
*s_floor.c- floor()*
*sf_floor.c- floorf()*
*mathfp/*
*s_floor.c- floor()*
*sf_floor.c- floorf()*
* *
*fabs()*
*math/*
*s_fabs.c- fabs()*
*sf_fabs.c- fabsf()*
*mathfp/*
*s_fabs.c- fabs()*
*sf_fabs.c- fabsf()*
*fmod()*
*math/*
*e_fmod.c- __ieee754_fmod()*
*ef_fmod.c- __ieee754_fmodf()*
*w_fmod.c- fmod()*
*wf_fmod.c- fmodf()*
*mathfp/*
*s_fmod.c- fmod()*
*sf_fmod.c- fmodf()*
*List of non-standard functions in newlib*
Other functions include
1) Bessel functions – jN, jNf, yN, yNf
2) cbrt, cbrtf
3) copysign, copysignf
4)erf, erff, erfc, erfcf – error functions
5)expm1, expm1f – exponential minus 1
6)gamma, gammaf, lgamma, lgammaf, gamma_r
7)hypot, hypotf
8)ilogb, ilogbf – get exponent of floating point number
9)infinity, infinityf- representation of infinity.
10) isnan, isnanf, isinf, isinff, finite,finitef
11)log1p, log1pf- log of 1+x
12)matherr – modifiable math error handler
13) nan, nanf
14)nextafter, naxtafterf - get next number
15)remainder, remainderf
16)scalbn, scalbnf –scale by power of 2
*Avr-libc*
*List of non-standard functions in avr-libc*
1)isnan
2)isinf
3)square
4)copysign
5)fdim – returns max of (x-y,0)
6)fma – floating point multiply-add ((x*y)+z) operation
7)fmax
8)fmin
9)signbit
10)trunc
11)isfinite
12)hypot
13)round
14)lround
15)lrint
--
Thanks and Regards
Usha Gupta
|
|
From: Weddington, E. <Eri...@at...> - 2010-07-23 21:23:54
|
> -----Original Message----- > From: Kaushik, Praveen_Kumar > Sent: Friday, July 23, 2010 3:29 AM > To: Weddington, Eric; 'avr...@li...' > Subject: RE: [avr32-libc-devel] Memory allocation design for > AVR32 Libc > > As each OS handles the memory allocation in different manner, > so we need to look at their memory management techniques. So > can you provide me a list of all the operating systems > supported by our tool chain? I'm not sure that there is a comprehensive list. Looking at the Atmel web site, I see that uCOS/II is available for the AVR32. I seem to recall FreeRTOS is available for the AVR32. But we shouldn't tailor the memory allocation routines for just those operating systems. I wouldn't want to limit the customers choice in operating systems for the future. We need to come up with a decent, generic memory allocation routines that will work for RTOSes as well as applications that don't use an RTOS. Do you think that this could be done? Eric Weddington |
|
From: Kaushik, P. <Pra...@at...> - 2010-07-23 09:28:56
|
Hi Eric, > -----Original Message----- > From: Weddington, Eric > Sent: Wednesday, July 21, 2010 6:07 PM > To: Kaushik, Praveen_Kumar; avr...@li... > Subject: RE: [avr32-libc-devel] Memory allocation design for AVR32 Libc > > More importantly, most if not all UC3 devices won't be using Linux at all. > It will either be a "bare metal" application (i.e. no OS), or typically > some RTOS such as FreeRTOS, or perhaps some other commercial RTOS. > > So the memory allocation functions need to be generic enough to handle > this. As each OS handles the memory allocation in different manner, so we need to look at their memory management techniques. So can you provide me a list of all the operating systems supported by our tool chain? Regards, Praveen Kaushik |
|
From: Kaushik, P. <Pra...@at...> - 2010-07-23 07:19:51
|
>-----Original Message----- >From: Joerg Wunsch [mailto:j...@ur...] >Sent: Friday, July 23, 2010 12:26 AM >To: Weddington, Eric >Cc: Kaushik, Praveen_Kumar; avr...@li... >Subject: Re: [avr32-libc-devel] Building AVR32-Libc with GNU tool chain >As Weddington, Eric wrote: >> Ah! I wasn't aware of this. We, the avr-libc developers, were never >> able to successfully build the C++ compiler, partially due to the >> fact that we could not build libstdc++. I'm now wondering if this >> issue was a contributing factor. >If I remember correctly, it's more like things as the absence of a >full standard IO library, but it's been a long time since I've tried >it for the last time. Yes thats true that absence of full standard IO library is one of the reason why libstdc++ is not built in AVR tool chain. But if you look at the file <GCC Source Dir>/libstdc++-v3/configure.ac, you will find a test for 'with_newlib'. It says that if --with-newlib is given then we do not need to check for dlopen() support and the link tests are avoided this way. I am not sure if there is any other way of avoiding these tests. Thanks and Regards, Praveen Kaushik |
|
From: Kaushik, P. <Pra...@at...> - 2010-07-23 07:15:33
|
Hi Eric, >-----Original Message----- >From: Weddington, Eric >Sent: Thursday, July 22, 2010 9:53 PM >To: Kaushik, Praveen_Kumar >Cc: 'avr...@li...'; Joerg Wunsch >Subject: RE: [avr32-libc-devel] Building AVR32-Libc with GNU tool chain >> -----Original Message----- >> From: Kaushik, Praveen_Kumar >> Sent: Thursday, July 22, 2010 12:56 AM >> To: Weddington, Eric >> Cc: avr...@li... >> Subject: RE: [avr32-libc-devel] Building AVR32-Libc with GNU >> tool chain >> >> The switch name --with-newlib might not be appropriate but >> this does not say that we are going to use Newlib as C >> library but instead it is for because the libstdc++ depends >> on certain functions provided by Newlib which might not be >> part of standard C library. >You said that libstdc++ depends on certain functions provided by Newlib >which might not be part of the standard C library. Do you know exactly >which functions libstdc++ needs from Newlib that aren't part of the >standard C library? When I was building avr32-libc for first time, I got errors for absence of few functions while building libstdc++. When I looked for those functions few of those were not part of the standard C library but were still provided by Newlib. I gave dummy declarations for those functions and went on building the library. The following header files are also not part of standard C library: unistd.h: required for declaration of lseek() sys/types.h: required for various 'type' definitions sys/stat.h: required for definitions of some macros and declaration of fstat() Apart from these, In stdio.h: function fdopen() is required but is not a part of standards. function vsnprintf() conforms to C99 but not to C89. The above list might not be comprehensive but with the inclusion of these files, I was able to build libstdc++ and AVR32 tool chain using avr32-libc. I came across the discussion on GCC's mailing list about the name of the switch '--with-newlib'. The discussion is very long but I think the following pages can be a quick reference for why the name --with-newlib is used, http://www.mailinglistarchive.com/gc...@gc.../msg18539.html Only the last two paragraphs on this page will be useful:- http://www.mailinglistarchive.com/gc...@gc.../msg18544.html Regards, Praveen Kaushik |
|
From: Joerg W. <j...@ur...> - 2010-07-22 18:56:39
|
(Someone might approve that to the avr32-libc-devel list if you feel it appropriate; I'm not subscribed there.) As Weddington, Eric wrote: > Ah! I wasn't aware of this. We, the avr-libc developers, were never > able to successfully build the C++ compiler, partially due to the > fact that we could not build libstdc++. I'm now wondering if this > issue was a contributing factor. If I remember correctly, it's more like things as the absence of a full standard IO library, but it's been a long time since I've tried it for the last time. > You said that libstdc++ depends on certain functions provided by > Newlib which might not be part of the standard C library. Do you > know exactly which functions libstdc++ needs from Newlib that aren't > part of the standard C library? That confuses me a bit. I thought Newlib just *is* a standard C library, nothing more and nothing less? (Just smashed together from various opensource but non-GPLed software collections they seemed fit.) -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) |
1 message has been excluded from this view by a project administrator.
