problem with osdk ?

Questions, bug reports, features requests, ... about the Oric Software Development Kit. Please indicate clearly in the title the related element (OSDK for generic questions, PictConv, FilePack, XA, Euphoric, etc...) to make it easy to locate messages.

mmu_man
Flight Lieutenant
Posts: 322
Joined: Thu Sep 21, 2006 7:45 pm
Location: 26000 Valence, FRANCE
Contact:

Post by mmu_man »

It's the "by default" that scares me. Maybe I forced it to something else somewhere, not intentionally.
I'll make a simple project to test that.
User avatar
Dbug
Site Admin
Posts: 4444
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Post by Dbug »

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.
mmu_man
Flight Lieutenant
Posts: 322
Joined: Thu Sep 21, 2006 7:45 pm
Location: 26000 Valence, FRANCE
Contact:

Post by mmu_man »

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:

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;
}
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. !?? :!: :?: :roll:
mmu_man
Flight Lieutenant
Posts: 322
Joined: Thu Sep 21, 2006 7:45 pm
Location: 26000 Valence, FRANCE
Contact:

Post by mmu_man »

Now I just need to fix the mul and div I hope (they used int32).
mmu_man
Flight Lieutenant
Posts: 322
Joined: Thu Sep 21, 2006 7:45 pm
Location: 26000 Valence, FRANCE
Contact:

Post by mmu_man »

Hmm, now a nice one:

Code: Select all

	int i = 5;
	printf("%f\n", 5.0);
	printf("%f\n", (float)i);
	printf("%d\n", (int)(float)i);
gives:
5
0
0
:)
User avatar
Dbug
Site Admin
Posts: 4444
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Post by Dbug »

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 !
mmu_man
Flight Lieutenant
Posts: 322
Joined: Thu Sep 21, 2006 7:45 pm
Location: 26000 Valence, FRANCE
Contact:

Post by mmu_man »

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 ?
Will see.
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 !
When I told you to do crossplatform code... :P
JamesD
Flight Lieutenant
Posts: 358
Joined: Tue Nov 07, 2006 7:38 am

Post by JamesD »

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
User avatar
Dbug
Site Admin
Posts: 4444
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Post by Dbug »

Give me a decent debugger.
I tried kdevelop and anjuta, it's just plain unusable crap, and Eclipse is dog slow on my laptop.

I refuse to do command line based GCC+makefile+insert your favorite editor here.
User avatar
Dbug
Site Admin
Posts: 4444
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Post by Dbug »

Hum, I started to do a unit test program, and it appears that "shorts" are one byte long... so obviously I was wrong on that.

Both floats and double are 5 bytes long, so this work.
mmu_man
Flight Lieutenant
Posts: 322
Joined: Thu Sep 21, 2006 7:45 pm
Location: 26000 Valence, FRANCE
Contact:

Post by mmu_man »

Dbug wrote:Give me a decent debugger.
Bdb is very nice... under BeOS ;)
There are several frontends to gdb... but I didn't try them.
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.
XEmacs \o/
Seriously, it's the most productive setup once you know how to use it.
User avatar
Dbug
Site Admin
Posts: 4444
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Post by Dbug »

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
mmu_man
Flight Lieutenant
Posts: 322
Joined: Thu Sep 21, 2006 7:45 pm
Location: 26000 Valence, FRANCE
Contact:

Post by mmu_man »

Ah, now I get 5 for all 3.
But the newest linker still busy loops.
User avatar
waskol
Flight Lieutenant
Posts: 414
Joined: Wed Jun 13, 2007 8:20 pm
Location: FRANCE, Paris

Post by waskol »

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
What was supposed to be $DF24 then ?
User avatar
Dbug
Site Admin
Posts: 4444
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Post by Dbug »

waskol wrote:What was supposed to be $DF24 then ?
Good question, I have no idea.
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.
Post Reply