Is It Possible To Have Standard C Libraries On The 940?


DrStrider

Still Fresh
Joined
Sep 11, 2006
Messages
13
Is it possible to have Standard C Libraries on the 940, for example memset?

here's my makefile:

Code:
# ---------------------------------------------------------------------

OBJS_940 =\
	940/Main.o \
	940/Stuff.o

Code940.bin : $(OBJS_940)
	$(LD) -e Main940 -Ttext 0 $(OBJS_940) -o Code940.elf -lc
	$(OBJCOPY) -O binary Code940.elf Code940.bin

940/Main.o : 940/Main.c
	$(CC) -O0 -W -Wall -c $< -o $@

Note the addititon of the "-lc" to link in standard C library
However when I tried memset or memcpy is just seemed to stop the 940 from working

Is there some kind of standard library initialisation I need to call first? Or is it not possible to use standard C library functions on the 940?
 
I suggest to use memcpy.S, memset.S, etc...

They are also a lot faster than the standard c library ones...

They can be found in MAME GP2X source code, for example.
 
I suggest to use memcpy.S, memset.S, etc...

They are also a lot faster than the standard c library ones...

They can be found in MAME GP2X source code, for example.

But for example malloc - can the standard C library malloc be set up with a section of the upper 32Meg of memory for the 940, and then work correctly?
 
Last edited by a moderator:
I suggest to use memcpy.S, memset.S, etc...

They are also a lot faster than the standard c library ones...

They can be found in MAME GP2X source code, for example.

But for example malloc - can the standard C library malloc be set up with a section of the upper 32Meg of memory for the 940, and then work correctly?

No, it is not possible, i suggest you to use standard memory allocation...
 
Last edited by a moderator:
I suggest to use memcpy.S, memset.S, etc...

They are also a lot faster than the standard c library ones...

They can be found in MAME GP2X source code, for example.

But for example malloc - can the standard C library malloc be set up with a section of the upper 32Meg of memory for the 940, and then work correctly?

No, it is not possible, i suggest you to use standard memory allocation...

Sure I use memset, memcpy and malloc on the 940 no problem. I use newlib and take control of _sbrk (and all the other platform specific functions, file i/o, etc). Just like any other embedded situation you have to manage your memory space, decide where the heap and stack are, etc. Recently someone said I should have a look at uClibc, but I have not done that yet. And no, I doubt seriously you can use malloc with the GPH gcc developers stuff, search around these forums for my arm gcc compiler or build your own using newlib...Or perhaps some of the others, devkitadv, winarm, etc.





Sure I use memset, memcpy and malloc on the 940 no problem. I use newlib and take control of _sbrk (and all the other platform specific functions, file i/o, etc). Just like any other embedded situation you have to manage your memory space, decide where the heap and stack are, etc. Recently someone said I should have a look at uClibc, but I have not done that yet. And no, I doubt seriously you can use malloc with the GPH gcc developers stuff, search around these forums for my arm gcc compiler or build your own using newlib...Or perhaps some of the others, devkitadv, winarm, etc.

Remember that mallocs are not a good programming style for an embedded platform. You already have the whole memory space, just use it. Same goes for local variables, you have to be super careful...
 
Last edited by a moderator:
Sure I use memset, memcpy and malloc on the 940 no problem. I use newlib and take control of _sbrk (and all the other platform specific functions, file i/o, etc). Just like any other embedded situation you have to manage your memory space, decide where the heap and stack are, etc. Recently someone said I should have a look at uClibc, but I have not done that yet. And no, I doubt seriously you can use malloc with the GPH gcc developers stuff, search around these forums for my arm gcc compiler or build your own using newlib...Or perhaps some of the others, devkitadv, winarm, etc.

Remember that mallocs are not a good programming style for an embedded platform. You already have the whole memory space, just use it. Same goes for local variables, you have to be super careful...


Though so - just after I got the post saying "it's not possible" I managed to link in the standard C library! For some reason doing a -lc didn't work and I had to specify the whole path (devkitgp2x\lib etc...) to the libc library

Do you know how you go about setting the area of memory used by malloc? At the moment I can call sprintf, but calling malloc(123) just hangs the 940. I presume there is some kind of function to call like malloc_set_area(0x00100000,0x01000000); (if the 940 is based at 0x02000000) or something? But what is the name of this function?
 
Last edited by a moderator:
Most of the functions of the standard C library rely on system call (malloc call sbrk, printf call write, etc...).
Those cannot work on the 920. But stand alone functions can (snprintf probably, mathematic functions, etc).
 
Though so - just after I got the post saying "it's not possible" I managed to link in the standard C library! For some reason doing a -lc didn't work and I had to specify the whole path (devkitgp2x\lib etc...) to the libc library

Do you know how you go about setting the area of memory used by malloc? At the moment I can call sprintf, but calling malloc(123) just hangs the 940. I presume there is some kind of function to call like malloc_set_area(0x00100000,0x01000000); (if the 940 is based at 0x02000000) or something? But what is the name of this function?

Download this:

http://www.gigasize.com/get.php/43308/arm-20060802a.zip

And there are examples in there (As well as a compiler to build them), I am pretty sure I have a malloc example in there (or perhaps every one of them does a malloc and then prints hello world first). Near the top of syscalls.c the base address of the heap is hardcoded, change it to whatever you like (this is in the 940 address space).

Trying to use a C library that is setup to build for linux or some other such platform may not work for a non-os platform. So if you are trying to use the same C compiler you use on the 920 you may fail. I am not that familiar with the inner workings of uclibc nor glibc so I dont know how to target those at a platform, and/or what files to seek out and destroy (in the compiler directory). newlib is easy, even if you take devkitadv or perhaps winarm or others that I think use newlib, and have left them targeted to who knows what, I think you can supply a syscalls.o, and of course -nostartfiles allows you to use your own crt0.o startup code.
For my gcc compiler above I have ripped out the guts of syscalls.c. There is just enough there to malloc, and printf. Printf calls a user supplied function that gets one byte/character at a time. I have examples that send that text to the display and examples that send it to the uart.

BTW I have started using -Ic:\arm\arm-thumb-elf-include on the gcc command line. I guess all these years I have been relying on files the compiler finds in the mingw directory. Better to dance with the one that brung you than someone elses include files. (I dont know if the above has it setup that way in the makefiles)

I use printf and sprintf often (for debugging) as well as memset, memcpy (for day to day use), etc. No problems there. Well, on the GBA or other ROM based platforms (or the GP2X if you are doing a bootloader I assume), you have to be careful where the format string is stored if it is in .data instead of .text make sure that crt0 initializes .data and .bss. For the 940 the only thing you have to worry about is remembering the physical 940 address is not the systems (920) physical address. Oh wait, you should look for the memcpy thread around here somewhere. Within minutes of trying I found at least 4 memset and memcpy implementations (winarm, mine, gph, ? ). One was byte based, very slow, and at least one did 16 bytes per transfer, which is about as good as you are going to get. So make sure you disassemble memset and memcpy no matter whos compiler/library you use to make sure they are using four register ldm/stm pairs. this will literally define success or failure. Another note, I have been using -O3 with gcc for years and not had problems. Not to say there should be, but other compilers will fall apart once you start to optimize. If you are not that brave go with -O2 at least, here again you dont want to throw away performance.

The floating point math libraries are compiled in (soft float) to my gcc build, if you really need them. you get that typical library complaint that no web page seems to have a good answer for. I figured it out one day and I think it is as simple as -nointerwork or some such thing, of course I wrote the answer on the back of an envelope and the envelope is long gone...There was no magic to it at all, no re-writing code or anything just a single command line switch in gcc...As far as that goes I kept gcc and newlib almost untouched, thumb might even work but it just serves to slow you down on this platform so dont bother...
 
Last edited by a moderator:
Back
Top