problem with osdk ?
If you can put together a list of "quirks" and "oddities", I will add that to the FAQ and things to watch out when using the osdk.
I guess you are the first one trying to use some multi-platform code directly. I always did very simple C code from scratch, so yeah, different usage patterns shows specific problems.
I guess you are the first one trying to use some multi-platform code directly. I always did very simple C code from scratch, so yeah, different usage patterns shows specific problems.
-
- Flight Lieutenant
- Posts: 322
- Joined: Thu Sep 21, 2006 7:45 pm
- Location: 26000 Valence, FRANCE
- Contact:
I'm currently trying to isolate what makes int 8bit...
it seems #including fpfloat triggers the assert, when NOFPMATH isn't defined.
Ok found the bugger:
If I #if 0 from before this in fpfloat_8_8.h to the end main doesn't assert, if I move the #if 0 under this one it asserts.
I fail to see how this could change int from 8bit to 16 bit though.
Oddly if I switch back to the macro version it fixes the bug. !??
it seems #including fpfloat triggers the assert, when NOFPMATH isn't defined.
Ok found the bugger:
Code: Select all
FPINLINE fpfloat float_to_fp(float f)
{
fpfloat v;
v = (_fp_full_t)(f * (float)((_fp_full_t)1 << _FPSH));
return v;
}
I fail to see how this could change int from 8bit to 16 bit though.
Oddly if I switch back to the macro version it fixes the bug. !??
-
- Flight Lieutenant
- Posts: 322
- Joined: Thu Sep 21, 2006 7:45 pm
- Location: 26000 Valence, FRANCE
- Contact:
Hmm, now a nice one:
gives:
5
0
0
Code: Select all
int i = 5;
printf("%f\n", 5.0);
printf("%f\n", (float)i);
printf("%d\n", (int)(float)i);
5
0
0
Ok, interesting.
Do you think you could manage to put all that in a small program that can be used as a regression/bug test for the compiler ?
It's something I should have done a long time ago when I started working on the new versions of the OSDK, would have avoided introducing some ridiculous bugs... *sigh*
I still can't do any major new change, my main pc is not working, so I'm on my linux laptop, with the osdk working partially using wine, but that's not an ideal setup to develop !
Do you think you could manage to put all that in a small program that can be used as a regression/bug test for the compiler ?
It's something I should have done a long time ago when I started working on the new versions of the OSDK, would have avoided introducing some ridiculous bugs... *sigh*
I still can't do any major new change, my main pc is not working, so I'm on my linux laptop, with the osdk working partially using wine, but that's not an ideal setup to develop !
-
- Flight Lieutenant
- Posts: 322
- Joined: Thu Sep 21, 2006 7:45 pm
- Location: 26000 Valence, FRANCE
- Contact:
Will see.Dbug wrote:Do you think you could manage to put all that in a small program that can be used as a regression/bug test for the compiler ?
When I told you to do crossplatform code...I still can't do any major new change, my main pc is not working, so I'm on my linux laptop, with the osdk working partially using wine, but that's not an ideal setup to develop !
If you really want to give the compiler a workout to see if everything works you could use the GCC test suites.
Some of them are just library tests but others will bring out compiler issues.
I'm sure the tests assume ANSI compatibility so anywhere you chose not to support ANSI will cause some tests to show up as a FAIL.
http://gcc.gnu.org/install/test.html
Some of them are just library tests but others will bring out compiler issues.
I'm sure the tests assume ANSI compatibility so anywhere you chose not to support ANSI will cause some tests to show up as a FAIL.
http://gcc.gnu.org/install/test.html
-
- Flight Lieutenant
- Posts: 322
- Joined: Thu Sep 21, 2006 7:45 pm
- Location: 26000 Valence, FRANCE
- Contact:
Bdb is very nice... under BeOSDbug wrote:Give me a decent debugger.
There are several frontends to gdb... but I didn't try them.
XEmacs\o/I tried kdevelop and anjuta, it's just plain unusable crap, and Eclipse is dog slow on my laptop.
XEmacs \o/I refuse to do command line based GCC+makefile+insert your favorite editor here.
Seriously, it's the most productive setup once you know how to use it.
What was supposed to be $DF24 then ?Dbug wrote:Ok, I guess I found out the problem for the float conversion.
It seems that the adress in rom for the Integer to Float conversion is pointing on the wrong place.
Try to change the file osdk/lib/header.s, by replacing the line
#define cif $DF24
by
#define cif $D499
Good question, I have no idea.waskol wrote:What was supposed to be $DF24 then ?
Obviously it's a routine which at least does not crash when called incorrectly.
If found out the real adress when I checked the generated code, and compared the LOADACC1/STOREACC1, etc... calls to what I had in Au coeur de l'Oric Atmos. And obviously it was not the same adress used for converting an integer to a float.
I'm wondering if it would not be a good idea to extract the floating point conversion code from the ROM, and get it as a separate library, would make it possible to do fp code while using the overlay memory, and perhaps optimise a bit the code as well.