CW 6.3 librarys and floating point

[johnr]

 After playing around with librarys the last 2 days, here's
what I found.

 If I add C_4i_SZ_MSL.a to the support files, I can use malloc() by
including "stdlib.h" in the source. In order to do this I must
comment out size_t in types.h because stdlib.h defines this as an
unsigned long and we get "size_t redeclacred" errors. When I remove  C_4i_SZ_MSL.a from Support Files, I get an error, "can't find malloc()"
so this tells me I can use MSL libs in the project.

  I modified ansi_prefix_CF.size.h in the FreeScale CW tree as per
a FreeSCale thread and re built MSL_C.CF mcp  by opening up
the project in the FreeScale CW tree.  After adding C_4i_MSL.a
to the Support Files and using the test code I get a "_f_itoa" link
error.



// ansi_prefix_CF.size.h in FreeScale tree
#if !(__COLDFIRE__ == 0x4080 && !__option(fp_library))
////#define _MSL_FLOATING_POINT      0
////#define _MSL_NO_MATH_LIB                    1
#define _MSL_FLOATING_POINT      1
#undef _MSL_NO_MATH_LIB
#endif

////#define _MSL_FLOATING_POINT_IO            0
#define _MSL_FLOATING_POINT_IO      1


// Simple float test code
 float f;
 int i;

 f=i;


 I also tried adding libgcc.a and libm.a from my CodeSourcery 4.11
tree to Support Files and get the same link errors. I called a CW
sales rep and asked if floating point is supported in all the versions
and am waiting to hear back.

 One thing I noticed after adding the C_4i_MSL.a lib to the project is
that the floating point option in the Coldfire Processor property tab
is still disabled. When I flipped around to use other processers it
seems to only get enabled when you specify a chip that has a hardware
FPU


 Thanks,
 John


 

[mark]

Hi John

Here is a guide to using malloc/free in the CW project. I haven't had problems with the typdef for size_t, either set to be unsigned int or unsigned long, however if your project does have a problem then either adapt it in types.h accordingly or else remove it from there and let it be defined for the whole project by stdlib.h.

The following 2 threads may have also something related:
http://www.utasker.com/forum/index.php?topic=44.msg180#msg180
http://www.utasker.com/forum/index.php?topic=30.msg121#msg121


Using malloc/free in the CW project

The size of the CodeWarrior malloc() heap can be defined by HEAP_SIZE in the linker script file (eg. M52235EVB_FLASH.lcf). This defines a fixed block of memory by the heap management software, the end of which is supplied by the linker as a variable extern unsigned char __HEAP_END.

If malloc () and other heap management routines in the CodeWarrior library are not used HEAP_SIZE can be set to 0.
The uTasker uMalloc uses the location of this variable #define HEAP_START_ADDRESS &__HEAP_END to define the start of its own, variable length heap. The uMalloc heap size is defined in TaskConfig.h:

const HEAP_NEEDS ctOurHeap[] = {
    {DEFAULT_NODE_NUMBER, OUR_HEAP_SIZE}, // our node requires this amount of heap space
    {0}                                                                                  // end
};

In this example the size is fixed at OUR_HEAP_SIZE but in a multi-node or multiple configuration system each node can have its own individual heap size.

Thus the memory has the following construction for the M5223X with 32k internal SRAM.




To ensure that the CW project operates correctly when using malloc/free from the library observe the following points:

- Add the library C_4i_CF_SZ_MSL.a (deliveres the malloc, free etc.) to the project. (This is suitable for the delivered uTasker project set up).
Note that the Codewarrior project configuration was modified in SP6 to use register passing, which produces smaller and faster code. When using this configuration the library C_4i_CF_RegABI_SZ_MSL.a should be used since it is built to be compatible with this option.

- Make sure that you include <stdlib.h> so that malloc is known (due to the next setting it is imperative that all prototypes are correct).

- In the file \Applications\uTaskerV1.3\CodeWarrior_M5223X\uTaskerV1.3\include\mwerks.h
ensure that the following pragma is set:
#pragma pointers_in_A0
If instead #pragma pointers_in_D0 is defined, change it to the above. This will ensure that the project is compatible with the library as delivered with CW.

Now malloc/free should work correctly and the complete project will use A0 register passing for return pointers, rather than D0 (calling functions must always know whether a pointer or a normal data value is being returned - if the prototype is not exact it can result in a serous error! The project is however set up to demand prototypes and will not build if something is not known.)


Regards

Mark

[mark]

Hi All

Here is an equivalent quide to using malloc/free in the GCC M5223X project:


When the GNU library heap management functions are to be used, it is adequate to define the size of its heap in the project configuration file config.h. This is performed by defining GNU_MALLOC_SIZE, eg. #define GNU_MALLOC_SIZE      1024.

The GNU library code uses an external variable called void *__heap_limit to define how much memory its heap is allocated. If this value is not defined in the project it defaults to taking the memory range from the end of the bss section (extern unsigned char _end; as delivered by the linker – see the linker script file to see how this is made available) up to 256 bytes below the stack pointer. This means that it scales itself to use up all free memory leaving some for working stack (just don’t put anything on the stack which is larger than 256 bytes or it could corrupt memory!!!).

When GNU_MALLOC_SIZE is defined in the uTasker project it creates a variable *__heap_limit which is set to point to GNU_MALLOC_SIZE bytes above the end of the BSS section.

This then results in the following memory map, which is identical to the memory map in the CodeWarrior project but uses slightly different defines.




Regards

Mark

[johnr]

Hi Mark, thanks for the info on the library usage. When I find an answer to
the floating point issue I'll let you know.

 John

[johnr]

Hi, I did receive a response from the FreeScale forum and someone
suggested I include fp_coldfire.a, which is locted in the Freescale CW
tree. It did allow me to do some basic operations with floats. I wrote
2 functions that converted from strings<--> floats with a 1 decimal place
preccesion and the .bin file increased about 5K

 Thanks,
 John

[mark]

Hi John

Thanks for reporting on that. I can only assume that this library doesn't have any source code in the project - the library is in ELF format and it is possible to see that it includes routines like _f_neg, _d_neg, d_add, _d_sub etc which were missing from the original tests. I couldn't find any assember source for these using a search.

Knowing what the library needed is called is certainly a big help!!

Regards

Mark