OESF Portables Forum
Everything Else => Zaurus - Everything Development => Distros, Development, and Model Specific Forums => Archived Forums => Qt/Qtopia => Topic started by: iamasmith on November 24, 2004, 03:30:56 pm
-
Hi,
Through a couple of threads I stumbled on the fact that it is actually possible to build binaries with soft fload using libfloat and gcc-2.95.
The only problem seemed to be that the Embedix/Qtopia dev stuff didn't contain libfloat.
Well actually that wasn't a problem because the Sharp/Cacko ROM on the 860 DOES.
After copying this lib over to my dev kit, taking the PDAXROM quake source, adding the -msoft-fload gcc flags and the -lfloat linker flags I can quite happily build a quake binary with softfloat for the Cacko ROM.
BTW: It's not a source dependency on PDAX either, I have previously compiled this source for Cacko with exception float but it was desperately slow.
However, what I find is that when I do try to run it I get a blank screen, no graphics (plenty of sound though) and quake bombs out with...
Error: D_SCAlloc: bad cache size 0
I tried updating from gcc-2.95.2 to gcc-2.95.3 and had exactly the same results.
BTW: I HAVE verified that the soft float mechanism does work using more simple floating point samples.
Anyone got any ideas ? I'm really keen to see how many FPS we can get out of Quake on Cacko using this method.
BTW: Haven't tried recompiling libSDL to soft-float yet, I guess most of the maths is in the quake engine.
- Andy
-
Once you solve the video problem you might want to try using the gcc options:
-03 -march=armv4 -mtune=strongarm
To optimize the binary for strongarm processors. GCC 2.95.3 doesn't optimize for xscale unfortunately.
Sounds like a cool project!
-
I have been researching this as well. Won't you have to recompile all the libraries that quake uses using a toolchain that has softfloat enabled? Then if you wish to run it in an environment where the dynamic libs are not compiled with softfloat (like sharp rom), then the quake binary must have the recompiled libs statically linked? I think quake uses zlib and sdl and sdl uses qtopia.
I am investigating the possibility of creating a binary for the sharp rom. Unless one is already available that I dont know about.
Seems to be an enormous task. I am currently trying to create the toolchain.
-
I have been researching this as well. Won't you have to recompile all the libraries that quake uses using a toolchain that has softfloat enabled?
No, shouldn't need to do this.
The main program that seems to use libfloat is the Java PersonalProfile which is why libfloat is in the SL-C860 Sharp and Cacko ROMs.
Math will be self contained within the user application so you should be able to exploit soft FP functions in your application with library sets that use exception floating point and vica-versa.
Since my original post I have rebuild zports libSDL with -msoft-float and it runs all my other SDL applications fine. + as I say I have built some FP test stuff as well and that all seems to work well.
Now obviously there is something else going on with Quake and it is indeed a symptom caused by the compilation but it all seems to be related to SDL initialisation at the moment.... I can feel a remote gdb session coming on.
- Andy
-
Another thing you might do is to compile the C stuff with gcc 3 to get better optimizations. This should work because IIRC the C ABI hasn't changed between versions, only the C++ ABI.
-
This should work because IIRC the C ABI hasn't changed between versions, only the C++ ABI.
That sounds sensible, thanks I might give that a go. I can't change libfloat though so I'm just hoping that libfloat ABI is compatible using -msoft-float on GCC 3.....
-
Hmm, I'll build a newer GCC toolchain later.
I tried patching in the PDAXROM 3.2 gcc and ld and hacking a specs file into shape but even with the --no-warn-mismatch it still doesn't link the objects
My next step is to trace the 2.95.2 build.
-
It was zlib that was killing it. zlib links statically and it was compiled for FP exception not softfloat.
It's way too slow still with libfloat.
The search continues...
-
Have you looked at the fixed point modifications that were made to the Quake engine for PocketQuake? That'd be a big win.....
It's possible that using the PocketQuake codebase as a startpoint is a better idea than using the standard Linux versions if you're looking for decent performance on a PDA......
-
I might look into the fixed point stuff but I have a feeling the PDAXROM sources (which is what I'm using) is derived from this source. Hint, talks about turning your PocketPC into a Palm when you quit
-
Are you sure we dont need to recompile the libraries? I managed to create a soft float toolchain with gcc-3.4.1-glibc-2.3.3. I think it is working although I have not really created any useful binaries with it. At the end of the build for quake1src, It complains about a mismatch in FPU between Quake and SDL (my SDL was compiled using the sharp toolchain).
/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.4.1-glibc-2.3.3/bin/arm-softfloat-linux-gnu-gcc -s -o quake console.o d_sky.o menu.o pr_edict.o r_misc.o snd_mix.o wad.o cd_sdl.o crc.o d_sprite.o model.o pr_exec.o r_part.o snd_sdl.o world.o chase.o cvar.o d_surf.o net_bsd.o r_aclip.o r_sky.o sv_main.o zone.o cl_demo.o d_edge.o d_vars.o net_dgrm.o r_alias.o r_sprite.o sv_move.o cl_input.o d_fill.o d_zpoint.o net_loop.o r_bsp.o r_surf.o sv_phys.o cl_main.o d_init.o draw.o net_main.o r_draw.o r_vars.o sv_user.o cl_parse.o d_modech.o host.o net_udp.o r_edge.o sbar.o sys_sdl.o cl_tent.o d_part.o host_cmd.o net_vcr.o r_efrag.o screen.o cmd.o d_polyse.o keys.o nonintel.o r_light.o snd_dma.o vid_sdl.o common.o d_scan.o mathlib.o pr_cmds.o r_main.o snd_mem.o view.o `/home/cmisip/develop/usr/local/bin/sdl-config --libs` -lpthread -lz
/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.4.1-glibc-2.3.3/lib/gcc/arm-softfloat-linux-gnu/3.4.1/../../../../arm-softfloat-linux-gnu/bin/ld: ERROR: /home/cmisip/develop/usr/local/lib/libSDLmain.a(SDL_Qtopia_main.o) uses hardware FP, whereas quake uses software FP
/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.4.1-glibc-2.3.3/lib/gcc/arm-softfloat-linux-gnu/3.4.1/../../../../arm-softfloat-linux-gnu/bin/ld: failed to merge target specific data of file /home/cmisip/develop/usr/local/lib/libSDLmain.a(SDL_Qtopia_main.o)
/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.4.1-glibc-2.3.3/lib/gcc/arm-softfloat-linux-gnu/3.4.1/../../../../arm-softfloat-linux-gnu/bin/ld: ERROR: /home/cmisip/develop/usr/local/lib/libSDL.so uses hardware FP, whereas quake uses software FP
/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.4.1-glibc-2.3.3/lib/gcc/arm-softfloat-linux-gnu/3.4.1/../../../../arm-softfloat-linux-gnu/bin/ld: failed to merge target specific data of file /home/cmisip/develop/usr/local/lib/libSDL.so
/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.4.1-glibc-2.3.3/lib/gcc/arm-softfloat-linux-gnu/3.4.1/../../../../arm-softfloat-linux-gnu/bin/ld: ERROR: /opt/Qtopia/sharp/lib/libqpe.so uses hardware FP, whereas quake uses software FP
/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.4.1-glibc-2.3.3/lib/gcc/arm-softfloat-linux-gnu/3.4.1/../../../../arm-softfloat-linux-gnu/bin/ld: failed to merge target specific data of file /opt/Qtopia/sharp/lib/libqpe.so
/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.4.1-glibc-2.3.3/lib/gcc/arm-softfloat-linux-gnu/3.4.1/../../../../arm-softfloat-linux-gnu/bin/ld: ERROR: /opt/Qtopia/sharp/lib/libqte.so uses hardware FP, whereas quake uses software FP
/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.4.1-glibc-2.3.3/lib/gcc/arm-softfloat-linux-gnu/3.4.1/../../../../arm-softfloat-linux-gnu/bin/ld: failed to merge target specific data of file /opt/Qtopia/sharp/lib/libqte.so
/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.4.1-glibc-2.3.3/lib/gcc/arm-softfloat-linux-gnu/3.4.1/../../../../arm-softfloat-linux-gnu/bin/ld: ERROR: /home/cmisip/develop/usr/local/lib/libz.so uses hardware FP, whereas quake uses software FP
/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.4.1-glibc-2.3.3/lib/gcc/arm-softfloat-linux-gnu/3.4.1/../../../../arm-softfloat-linux-gnu/bin/ld: failed to merge target specific data of file /home/cmisip/develop/usr/local/lib/libz.so
collect2: ld returned 1 exit status
make: *** [quake] Error 1
So I decided to recompile SDL and it complains:
/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.4.1-glibc-2.3.3/bin/arm-softfloat-linux-gnu-gcc -shared SDL.lo SDL_error.lo SDL_fatal.lo SDL_getenv.lo SDL_loadso.lo -Wl,--whole-archive main/.libs/libarch.al audio/.libs/libaudio.al video/.libs/libvideo.al events/.libs/libevents.al joystick/.libs/libjoystick.al cdrom/.libs/libcdrom.al thread/.libs/libthread.al timer/.libs/libtimer.al endian/.libs/libendian.al file/.libs/libfile.al -Wl,--no-whole-archive -lm -lc -Wl,-soname -Wl,libSDL-1.2.so.0 -o .libs/libSDL-1.2.so.0.0.5
/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.4.1-glibc-2.3.3/lib/gcc/arm-softfloat-linux-gnu/3.4.1/../../../../arm-softfloat-linux-gnu/bin/ld: ERROR: video/.libs/libvideo.al(SDL_QWin.lo) uses hardware FP, whereas .libs/libSDL-1.2.so.0.0.5 uses software FP
/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.4.1-glibc-2.3.3/lib/gcc/arm-softfloat-linux-gnu/3.4.1/../../../../arm-softfloat-linux-gnu/bin/ld: failed to merge target specific data of file video/.libs/libvideo.al(SDL_QWin.lo)
/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.4.1-glibc-2.3.3/lib/gcc/arm-softfloat-linux-gnu/3.4.1/../../../../arm-softfloat-linux-gnu/bin/ld: ERROR: video/.libs/libvideo.al(SDL_sysmouse.lo) uses hardware FP, whereas .libs/libSDL-1.2.so.0.0.5 uses software FP
/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.4.1-glibc-2.3.3/lib/gcc/arm-softfloat-linux-gnu/3.4.1/../../../../arm-softfloat-linux-gnu/bin/ld: failed to merge target specific data of file video/.libs/libvideo.al(SDL_sysmouse.lo)
/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.4.1-glibc-2.3.3/lib/gcc/arm-softfloat-linux-gnu/3.4.1/../../../../arm-softfloat-linux-gnu/bin/ld: ERROR: video/.libs/libvideo.al(SDL_sysvideo.lo) uses hardware FP, whereas .libs/libSDL-1.2.so.0.0.5 uses software FP
/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.4.1-glibc-2.3.3/lib/gcc/arm-softfloat-linux-gnu/3.4.1/../../../../arm-softfloat-linux-gnu/bin/ld: failed to merge target specific data of file video/.libs/libvideo.al(SDL_sysvideo.lo)
/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.4.1-glibc-2.3.3/lib/gcc/arm-softfloat-linux-gnu/3.4.1/../../../../arm-softfloat-linux-gnu/bin/ld: ERROR: video/.libs/libvideo.al(SDL_syswm.lo) uses hardware FP, whereas .libs/libSDL-1.2.so.0.0.5 uses software FP
/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.4.1-glibc-2.3.3/lib/gcc/arm-softfloat-linux-gnu/3.4.1/../../../../arm-softfloat-linux-gnu/bin/ld: failed to merge target specific data of file video/.libs/libvideo.al(SDL_syswm.lo)
/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.4.1-glibc-2.3.3/lib/gcc/arm-softfloat-linux-gnu/3.4.1/../../../../arm-softfloat-linux-gnu/bin/ld: ERROR: video/.libs/libvideo.al(SDL_sysevents.lo) uses hardware FP, whereas .libs/libSDL-1.2.so.0.0.5 uses software FP
/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.4.1-glibc-2.3.3/lib/gcc/arm-softfloat-linux-gnu/3.4.1/../../../../arm-softfloat-linux-gnu/bin/ld: failed to merge target specific data of file video/.libs/libvideo.al(SDL_sysevents.lo)
collect2: ld returned 1 exit status
make[2]: *** [libSDL.la] Error 1
make[2]: Leaving directory `/home/cmisip/developfloat/SDL-1.2.5/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/cmisip/developfloat/SDL-1.2.5/src'
make: *** [all-recursive] Error 1
If I remove the configure option that enables qtopia in SDL, it compiles cleanly.
I suspect that quake doesn't like SDL built using the sharp toochain (non soft float) and SDL(soft float) it doesn't like the qtopia libs (non soft float) which are compiled with hard FPU support.
Man, do I need to recompile the qtopia libs with soft-fpu?
Of course, I could be completely off track here.
-
cmisip,
Yep, been there too. Even using --no-warn-mismatch on ld doesn't get around that.
My best luck so far is just using the Embedix 2.95.2 toolchain, copying libfloat.so.1 off the Sharp ROM into the /opt/Qtopia/sharp/libs location, specifying -msoft-float on the gcc -o <mod> -s <source> lines and linking with -lfloat.
However, what I previously said about zlib screwing it up was false. I was tired and I had the wrong switches in my Makefile so I build an FPA rather than softfp build.
SO the problem remains... I CAN build quake with softfp but it crashes with error D_SCAlloc and displays no graphics (sound does seem to be running though).
It seems that the textures are not being read correctly and so when d_surf tries to create a cache it complains about a 0 size texture with a 0 size cache.
Tried to debug but current gdb is a crock. I think I need to build a newer version of that as stepping just DOESN'T seem to step all the assembler instructions when I'm debugging in source mode and seems to hop backwards and forwards in the session - hard to follow and not very useful. There are some patches out now which show the source lines as well when you use disassemble so I think my next step is to try that.
Actually regarding the libraries.. the FP intensive bits in quake aren't calling math.h stuff it's actually doing simple FP stuff... just a lot of it. Any application that makes a lot of use of math.h isn't going to benefit since the Z libraries are prebuilt with FPA rather then soft-float. I would NOT suggest recompiling these libraries since there may possibly be precision loss/change and that would introduce some compatibility issues. - but hey if you are a fan of Intel processors then I guess that's nothing new to you
- Andy
-
I can now confirm that 2.95.2 and 2.95.3 as cross-compilers produce the same duff quake executable when cross compiling from the desktop and 2.95.1 in dev-img-1.6 results in the same problem when compiling natively on the Z.
...goes off to build gdb-6.3.
-
Well I am happy to report that I managed to compile a soft float enabled quake binary that runs under sharp rom. It is definitely much faster and very playable almost faster than prboom. Only, it runs outside of qtopia since I compiled my sdl without qtopia support (dont know yet how to recompile those qtopia libs). However it runs 320x240 so that up button makes it turn left, down button turns right, left is back and right is forward. Does anybody know how to influence screen rotation in fb mode with sdl?
The way to get this done:
1. create a soft float enabled toolchain.
2. recompile zlib and sdl without qtopia support to create static libs
3. compile quake with soft float linking with the static libs
4. transfer the binary to zaurus
5. open a terminal su to root
6. disable the sdl mouse
5 run quake
I can email the binary to anyone wanting to test.
-
I'd be honnestly more interested in the toolchain :-) May I ask you a copy or the instructions, so I can see what's wrong with qtopia?
I'll send you a copy of a libsdl source where some little changes let you manually fix the keys and/or the screen rotation
-
I'm still going down the 2.95 route to see if we can use most of the shared libc in the Sharp ROM.
I have now traced the problems I was experiencing with Quake compiled with libfloat and -msoft-float to the floor() and ceil() functions in use within Quake and some rather dubious casting of floats into doubles. When compiled with softfloat these functions invariably return 0 which is why all textures etc. come out with a zero byte size and why D_SCAlloc complains that it is trying to cache 0 bytes of texture.
I'm now going to see if I can build a static linkable module from a toolchain that carries all the maths functions - this version to be built using -msoft-float and linked against libfloat.
As to my best guess as to why there is such a problem, well I'm now wondering if the format of the float type changes when compiling using soft-float.....hmm.
- Andy
-
I uploaded the instructions on building the toolchain in my web site referenced below. Its on the very bottom of the zaurus section.
-
Maybe someone can help recompile the Qtopia libs so they will be soft float enabled. I will endeavor to do that as well.
This opens up new possibilities for the Z. I dont know how much of the programs currently compiled for the Z use hard FPU. It might be worth recompiling them for soft FPU to improve performance. Mplayer comes to mind.
-
Well, I just found out that Qtopia will not compile with gcc 3.4.x because it has a problem with packed structs. So I am building another toolchain with gcc 3.3.3.
-
Exellent work you guys are doing! One of the reasons I've tried pdaxrom was to see Quake runnign at playable speed Now if you manage to get similar result on Sharp-based ROM that will be great! Looking forward to seeing you suceed.
-
OK, what I have found so far with -msoft-float and libfloat.
1. You don't actually need to copy libfloat up onto your development box if you are using the Embeddix toolchain. try this....
find /opt/Embeddix -name soft-float
it will report a couple of subdirectories containing soft-float enabled versions of library stubs. You may link with gcc using -msoft-float and it will find these stubs without you having to specify -lfloat.
2. Unfortunately the libm.so doesn't seem to handle soft-float compiled binaries properly, at least not all the time. I can compile simple apps with soft-float and the math.h stuff works well. Quake just doesn't, the floor() and ceil() commands that quake uses quite a lot always seem to return 0. - It isn't a format problem with the floating point storage, simple things like printf("%f",myfnum) would fail if that were the case. Not sure (yet) why these functions fail in quake and to be honest even the new version of gdb that I built isn't helping
So, cmisip, what sort of frame rate are you getting out of your version of quake with the GCC 3 toolchain ?...
You can time this from the console using timedemo demo1.dem
Oh and BTW: did you try Duke3D again yet ?
- Andy
-
Unfortunately I do not have the tilde key on the zaurus keyboard so I cant access the console. Maybe you can modify the quake source so I can access it another way. (You are more qualified to tinker with the quake source than me). I think I am getting at least 25 fps though. It is faster than prboom which probably needs to be recompiled with soft float as well. The quake binary is in the website referenced below on my signature. It should work on your system since libraries are statically linked.
We seem to be taking different routes to the same problem. I am trying to get the libraries and compilers to work with the quake source. You are trying to get the quake source to work with existing compilers and libraries.
My biggest stumbling block right now is that I cant seem to build libqpe. Following the readme.html that came with the free version of qt embedded, it only built libqte. I am still trying to figure this out. I think I pretty much know how to compile libsdl and quake once I get that library built. If you have tips regarding the building of libpqe let me know.
As far as duke nukem 3d, I was able to at least get rid of the problem with all the sound being played back sequentially when you start the game. Its a hack though, If I remember correctly, I just disabled the loading of sound data greater than a certain size. I think its a memory issue. I have not looked at the source for a while. Maybe you can take that on as well. I do not have any programming background. I just slept at a holiday inn.
-
You can get the console up through the options menu... if you are working on the same source..
.. Oh, you can change the console binding by editing id1/config.cfg, just look for the line that says bind "`" "toggleconsole".
BTW: If I try your precompiled version I get...
$ runquake.sh
Cvar_RegisterVariable: crosshair is a command
Added packfile /mnt/card/quake/id1/pak0.pak (339 files)
Added packfile /mnt/card/quake/id1/pak1.pak (85 files)
PackFile: /mnt/card/quake/id1/pak1.pak : gfx/pop.lmp
Playing registered version.
PackFile: /mnt/card/quake/id1/pak0.pak : gfx.wad
Console initialized.
UDP Initialized
Exe: 23:14:14 Nov 26 2004
8.0 megabyte heap
PackFile: /mnt/card/quake/id1/pak0.pak : gfx/palette.lmp
PackFile: /mnt/card/quake/id1/pak0.pak : gfx/colormap.lmp
Error: VID: Couldn't load SDL: Unable to open a console terminal
$
Andy
-
you must run it as root.
-
Can you clear up something for me? I know libqte is built using qt-embedded. Is libqpe built using qtopia-free-1.X? Is qpe-1.X just an earlier version of qtopia-free-1.x.
I have decided to try qt-embedded-2.3.3 with qpe-1.4.
What is the version running on the sharp rom?
Thanks.
-
I managed to run timedemo demo1.dem and it showed 18.8 fps at 320 x 200
It felt like it was faster than that though.
-
Sorry don't know about the libqpe stuff.
BTW: Got the binary running, actually had to boot out of Qtopia to a plain old shell before I could see anything - I guess this figures, you build SDL without Qtopia right ?
It runs upside down on an 860... hey that's easily fixable and runs about 12.5fps with no overclocking but I can't believe that. It seems SO much faster than the PDAXROM version.... I really don't know what's going on here.
Anyway, it's given me some motivation to see what results I can get out of a 2.95.2 version.... although I'm getting to the point of wondering if it would actually be better to build a softfloat enabled uclibc and statically link against that.
I may try the GCC 3 route again soon, I'm wondering if the ELF headers of the .o files can be simply tweaked to allow linkage against non soft-float stuff.
Have you played with readelf ? does it show you anything different on your objects ?
- Andy
-
The statically linked SDL was compiled without qtopia.
That is why I am trying to build libqte and libqpe with soft-float.
I think I got libqte built right but libqpe is problematic.
How do you fix the fact that it is upside down?
You are getting only 12.5 fps. Are you running at a higher resolution?
I dont know anything about readelf or uclibc.
In the future, I might build a toolchain based on xscale. It will be with gcc 3.4.X. Maybe we canget higher frame rates with xscale optimization.
But right now, libqpe first.
-
The statically linked SDL was compiled without qtopia.
That is why I am trying to build libqte and libqpe with soft-float.
I think I got libqte built right but libqpe is problematic.
How do you fix the fact that it is upside down?
You are getting only 12.5 fps. Are you running at a higher resolution?
I dont know anything about readelf or uclibc.
In the future, I might build a toolchain based on xscale. It will be with gcc 3.4.X. Maybe we canget higher frame rates with xscale optimization.
But right now, libqpe first.
If you check out the zport SDL cvs you can find code that gets the rotation right for various different models.
My command line is set to 320x240, however, because I'm running from the console the frame buffer is probably set to 640x480 causing quake to run quad pixel blocks so that may account for the drop in frame rate. When running under Qtopia I can tell Qtopia to scale to 320x240, may make up the frame rate by doing that.
I found the cause of the math.h/libm proble .. take this sample...
mathtest.h....
#include <stdio.h>
#include <math.h>
float module1();
float module2();
module1.c...
float module1()
{
float f1,f2;
f1=3.14159;
f1/=1.23456;
f2=floot(f1);
return f2;
}
module2.c.....
#include "mathtest.h"
float module2()
{
float f1,f2;
f1=3.14159;
f1/=1.23456;
f2=floor(f1);
return f2;
}
test.c....
#include "mathtest.h"
main()
{
printf("%f\n",module1());
printf("%f\n",module2());
}
...now first compile with...
arm-linux-gcc -o module1.o -c module1.c
arm-linux-gcc -o module2.o -c module2.c -msoft-float
arm-linux-gcc -o test.o -c test.c -msoft-float
arm-linux-gcc -o test test.o module1.o module2.o libfloat.a -lm
(I made a static link version of libfloat).
Results when you run test on the Z...
0
0
Now recompile as follows...
arm-linux-gcc -o module1.o -c module1.c
arm-linux-gcc -o module2.o -c module2.c -msoft-float
arm-linux-gcc -o test.o -c test.c
arm-linux-gcc -o test test.o module1.o module2.o libfloat.a -lm
And results are...
2
2
Excellent it works, now why ????
I'm pretty sure now that if you link the main() module in your executable as soft-float it removes the exception handler that normally sits on SIGFPE which is what is normally used to handle the unimplemented FP opcodes. Since the libm library is linked with hard floating point this is why the library is failing.
Now, unfortunately, libSDL throws a spanner in the works. You start up with SDL_main rather than main() and I have tried SDL build with both FPE and soft-float... both barf.
So I now need to find out why SDL is linking with FPE unhooked from the SIGFPE handler.
Anyway, I'm a much happier bunny now I now the cause of the problem !
-
OK, now I know that the Netwinder FPE is not kicking in when using modules with the main() function compiled for -msoft-float I thought that I would look at what may be happening with SIGFPE.
Firstly I patched the SDL_Parachute install routines which normally install handlers where SIG_DEF are installed so that it definitely wouldn't touch SIGFPE... no luck. Well I didn't expect this to be the root cause of the problem so I thought that it may be possible to re-vector the signal handler for SIGFPE within a Soft float binary such that the Netwinder FPE (in the kernel) kicked in.
So, (please take a look at my previous example in the last post), I created another test.
#include <signal.h>
#include <stdio.h>
main()
{
void *t;
t=signal(SIGFPE,SIG_DFL);
signal(SIGFPE,t);
printf("%08X\n",t);
}
This should very simply print out the hex ID of any handler installed on SIGFPE, this was compiled with FPE and with soft-float.
BOTH returned 00000000 !
It is now my guess that the vectoring of the FPE is somehow handled by the ELF loader dependent upon flags in the ELF headers of the executable (probably on _main) and that the vectoring is done silently such that SIG_DFL is returned.
Anyone know much about ELF headers.
objdump and readelf don't seem to reveal much.
- Andy
-
Well, I am still in a gcc mess with qtopia.
It seems that gcc-3.4.1 can compile without libfloat but earlier versions needed an external libfloat library. Found the libfloat source and was able to create the static library that makes qtopia happy. However, it complains of libgcc being compiled with hard FP support.
Now I am trying to figure out how to compile libgcc so that it is software FP.
Any ideas?
-
It runs upside down on an 860... hey that's easily fixable and runs about 12.5fps with no overclocking but I can't believe that. It seems SO much faster than the PDAXROM version.... I really don't know what's going on here.
hello,
pdaXrom quake give about 15 fps without overclock and about 20 with overclock..
-
The 18.8 fps I reported was using Zynergy ROM and an unoverclocked kernel. It must be the fast libsdl.
-
OK, softfloat (with 2.95 +libfloat) was not a goer, there were too many calls to libm.so and although I could have proxied the floating point ABI through a stub it wouldn't achieve anything... libm.so would just throttle the speed.
Switched to a softfloat GCC 3.4.2 toolchain, statically linked with libSDL and qpe as cmisip tried. I can reliably get 14 FPS on an SL-C860 running standard SA1100 code, however, quake is about 4Mb in size and there are some differences in qte/qpe as built and as available in the shared libraries.. that is the rotation stuff that the zports team put into SDL doesn't work correctly and initialises the screen as 240x320 on a 320x240 screen.
So... spending some time getting to know libSDL now.
-
Were you able to compile qpe with gcc 3.4.2?
-
Well the conclusion was reached by cmisip, it works well.
The zports libsdl (which I was trying) doesn't work for this but he used a patched 1.2.5 libSDL which is statically linked in so you don't need to install that specifically.
Note that the link at the time I tried to pull it down was actually linked to the non Qtopia version. Hopefully he will fix that soon but in the meantime if you pull the quake IPK from the site by using the url http://home.comcast.net/~cmisip/quakeqt-z5600-1.ipk (http://home.comcast.net/~cmisip/quakeqt-z5600-1.ipk) then that works.
For the curious I'm using an SL-C860 and it works well, it takes some time to initialise (and I have to hit cancel a couple of times) but when it's going it runs at 16.5fps without overclocking which is much better than the 3.5fps that you get using the standard FPE based math and gcc 2.95.
In fact it is marginally faster than the pdaXrom version but this is an optimised libSDL.
Well done cmisip
-
I fixed the link. It was working at it late last night. It has been a fun project.
-
It runs upside down on an 860... hey that's easily fixable and runs about 12.5fps with no overclocking but I can't believe that. It seems SO much faster than the PDAXROM version.... I really don't know what's going on here.
hello,
pdaXrom quake give about 15 fps without overclock and about 20 with overclock..
with cmisip's binary in his website i get 15 fps without overclock and 17.8 fps with overclock (timedemo demo1). Its running at 320x240 on my c860 with piro's sdl
I can only run in 320x200 (quakeqt -win 320 200) mode if I rotate the screen b4 running it. This has the ill effect of the arrow keys rotated too. I do get 16.6 fps without overclock and 19.8 fps overclocked though. Any idea why the rotation is needed to run it in 320x200 mode.
tovarish