[vbcc/win] Doing some maths..

[guy lateur]

Just a newbie exploring C, and trying to write some maths code -- eg to generate a sine table. So nothing to see, here..

I'm using the latest version of vbcc on win64. I've attached the code, the makefile and the exe. This is really about the C translation of the assembler question I asked in this thread: http://eab.abime.net/showthread.php?t=87875 (just read to about post 7 or so; it got really off topic after that )

#include <math.h>
#include <stdio.h>
 
int main (void)
{
 int nrSamples = 256;
 
 float deltaAngle = 2.0 * M_PI / ((float) nrSamples);
 float currAngle, currSine;
 int iSample;
 
 for (iSample = 0; iSample < nrSamples; iSample++)
 {
  currAngle = deltaAngle * ((float) iSample);
  currSine = sin(currAngle);
 
  printf("%3d : %f : %f\n", iSample, currAngle, currSine);
 }
 
 return (0);
}

The code is pretty much exactly what thomas wrote in post 4. However, I'm experiencing some weirdness on executing the exe, depending on the platform. I have an accelerated A1200, EC030/50MHz, 2/8 MB.

My ultimate goal is to have this working on this actual hardware, of course. And it doesn't, really; it outputs some unexpected-yet-recognisable results:

I'm not sure what's happening there, but it seems like it kind of gets the main part (the mantissa?) right, but then loses it (at the exponent?).

I'm cross developing on a PC and I also have Amiga Forever 7, so obviously I'd like to test it there first before I transfer it to the actual amiga (that workflow still needs some work). If I select the default A1200 config, the exe gurues (error #8000 000B). That's unfortunate. If I change the ROM version from 3.1 to 3.X, it works perfectly, and generates exactly the output thomas quoted. So what is going on here? I happen to have 3.X ROMs in my A1200, where it also doesn't really work neither, but at least it doesn't guru.

I'm linking to mieee.lib. It says in the vbcc docs (page 83) that this 'will always open MathIeeeSingBas.library, MathIeeeDoubBas.library and MathIeeeDoub-Trans.library'. I don't have MathIeeeSingBas.library in the libs: folder on any of my systems, so maybe that comes with ROM 3.X?

Also, tbh, I'm not really sure which printf version I'm calling. Is it the 1 in amiga.lib (http://amigadev.elowar.com/read/ADCD.../node0162.html)? Because according to the docs, this does not support the %f type. Or is it in vc.lib (as the docs slightly seem to suggest)? Including <stdio.h> probably loads the one in targets\m68k-amigaos\include, right?

So that's another fine mess I've gotten myself into!

[guy lateur]

Btw, if I link to msoft.lib, it works ok on all 3 platforms. Just a whole lot slower, unfortunately..

[ajk]

I didn't examine your code very closely but you could rule out the printf() by printing an integer instead, e.g.:

float angle = 35.3f;

printf("%d\n", (int)(angle * 1000.0f))

And see if that gives the expected results (times 1000, of course).

[matthey]

Frank Wille (phx) could probably give more suggestions and specifics in regards to the ieee libraries but I will start.

Originally Posted by guy lateur

I'm cross developing on a PC and I also have Amiga Forever 7, so obviously I'd like to test it there first before I transfer it to the actual amiga (that workflow still needs some work). If I select the default A1200 config, the exe gurus (error #8000 000B). That's unfortunate. If I change the ROM version from 3.1 to 3.X, it works perfectly, and generates exactly the output thomas quoted. So what is going on here? I happen to have 3.X ROMs in my A1200, where it also doesn't really work neither, but at least it doesn't guru.

The guru is an F-line trap usually from lack of FPU. There are different versions of the ieee libraries and ROMs which may or may not require an FPU. Make sure you installed the correct ones for your hardware configuration selected in UAE. Also, be sure SetPatch is run in your S:Startup-Sequence as there are important floating point patches applied in some cases.

Originally Posted by guy lateur

I'm linking to mieee.lib. It says in the vbcc docs (page 83) that this 'will always open MathIeeeSingBas.library, MathIeeeDoubBas.library and MathIeeeDoub-Trans.library'. I don't have MathIeeeSingBas.library in the libs: folder on any of my systems, so maybe that comes with ROM 3.X?

Yes. There are a couple of math libraries in kickstart/ROM.

Originally Posted by guy lateur

Also, tbh, I'm not really sure which printf version I'm calling. Is it the 1 in amiga.lib (http://amigadev.elowar.com/read/ADCD.../node0162.html)? Because according to the docs, this does not support the %f type. Or is it in vc.lib (as the docs slightly seem to suggest)? Including <stdio.h> probably loads the one in targets\m68k-amigaos\include, right?

I believe the default printf() is in vc.lib but using a math library selects a different version of printf() from that .lib (mieee.lib in your case).

[alkis]

I think %f stands for double.

Yeap, just checked https://en.wikipedia.org/wiki/Printf_format_string

Try casting float to double in printf's parameters.

[guy lateur]

Originally Posted by ajk

I didn't examine your code very closely but you could rule out the printf() by printing an integer instead, e.g.:

float angle = 35.3f;

printf("%d\n", (int)(angle * 1000.0f))

And see if that gives the expected results (times 1000, of course).

This does indeed give the expected results on 3.X, but still gurues on the default A1200 (3.1). Linking to mieee.lib, btw. So.. what would you say is the problem: the %f printf function (whatever one gets called), or mieee.lib?

[matthey]

Originally Posted by alkis

I think %f stands for double.

Yeap, just checked https://en.wikipedia.org/wiki/Printf_format_string

Try casting float to double in printf's parameters.

Or use double for everything. C has historically more commonly used double and only recently with c99 supported single precision float well. The single precision sin() should actually be sinf() but I'm not even sure if the ieee.lib supports it (the vbcc FPU specific math libraries do).

https://en.wikipedia.org/wiki/C_mathematical_functions
http://en.cppreference.com/w/c/numeric/math/sin

Compiling with vbcc using any c99 features (and probably single precision floats) should use the -c99 command line option!

[guy lateur]

Originally Posted by alkis

I think %f stands for double.

Yeap, just checked https://en.wikipedia.org/wiki/Printf_format_string

Try casting float to double in printf's parameters.

Thanks alkis, but this gives the exact same results:

printf("%3d : %f : %f\n", iSample, (double) currAngle, (double) currSine);

[alkis]

Originally Posted by guy lateur

Thanks alkis, but this gives the exact same results:

printf("%3d : %f : %f\n", iSample, (double) currAngle, (double) currSine);

Well, at least now it's the compiler's fault and not your own

Btw, gcc crashes amiga too.

[alkis]

hmm, the plot thickens.

float arguments in variadic functions are auto-promoted to double
(https://stackoverflow.com/questions/...at-to-a-double )

[guy lateur]

Originally Posted by matthey

Or use double for everything. C has historically more commonly used double and only recently with c99 supported single precision float well. The single precision sin() should actually be sinf() but I'm not even sure if the ieee.lib supports it (the vbcc FPU specific math libraries do).

Well you're definitely onto something with the 'all double' path. The code below works on all 3 platforms:

#include <math.h>
#include <stdio.h>

int main (void)
{
	int nrSamples = 256;
 
	double deltaAngle = 2.0 * M_PI / ((double) nrSamples);
	double currAngle, currSine;

	int iSample;
 
	for (iSample = 0; iSample < nrSamples; iSample++)
	{
		currAngle = deltaAngle * ((double) iSample);
		currSine = sin(currAngle);
		
		printf("%3d : %f : %f\n", iSample, currAngle, currSine);
	}

	return (0);
}

Originally Posted by matthey

Compiling with vbcc using any c99 features (and probably single precision floats) should use the -c99 command line option!

Not sure what you mean by that, but I definitely would like to have this working with singles rather than doubles (which are probably total overkill in most scenarios). So how exactly do I proceed from here, again?

[guy lateur]

Originally Posted by alkis

hmm, the plot thickens.

float arguments in variadic functions are auto-promoted to double
(https://stackoverflow.com/questions/...at-to-a-double )

But the sin function isn't variadic (if I'm right about what this means), so this auto-promotion doesn't happen, right? Unless there's something else I'm missing..

[alkis]

sin is not variadic, but the prototype of it should promote the argument to double.

printf is variadic.

[guy lateur]

Originally Posted by alkis

sin is not variadic, but the prototype of it should promote the argument to double.

printf is variadic.

From the tests I've run, neither sin nor printf seems to automatically promote floats to doubles. Which is probably for the best, really. I only get this working when going 'all doubles', as matthey suggested.

[matthey]

Originally Posted by alkis

hmm, the plot thickens.

float arguments in variadic functions are auto-promoted to double
(https://stackoverflow.com/questions/...at-to-a-double )

I thought it should work without problems even though it is less efficient than working with floats in some cases.

Originally Posted by guy lateur

Not sure what you mean by that, but I definitely would like to have this working with singles rather than doubles (which are probably total overkill in most scenarios). So how exactly do I proceed from here, again?

The -c99 option is recommended unless needing old C89/ANSI C compatibility.

vc -c99 ...

This will eliminate problems (sometimes without errors) when trying to use c99 functions and features.

I'm not even sure the mieee.lib supports single precision c99 like features. It should be partially possible (and provide better performance) as the C= ieee libraries have some single precision functions needed by c99. There was no c99 support in the FPU specific libraries for functions like sinf() until I added them because I wanted better c99 support. I didn't touch the mieee.lib which is behind in features and can not really be brought up to the same level of c99 features because of limitations in the C= ieee libraries. Frank could probably tell us exactly what is supported in the mieee.lib but I recommend using only double until we hear from him.

[guy lateur]

Originally Posted by matthey

The -c99 option is recommended unless needing old C89/ANSI C compatibility.

vc -c99 ...

This will eliminate problems (sometimes without errors) when trying to use c99 functions and features.

I had this option on already; it doesn't seem to solve the problem, unfortunately.

[alkis]

Ok, further testing.

Works fine in SAS/C and in gcc-6.2.1.
Doesn't work in gcc-3.4.0

[guy lateur]

Originally Posted by alkis

Ok, further testing.

Works fine in SAS/C and in gcc-6.2.1.
Doesn't work in gcc-3.4.0

Alright, nice investigation, alkis!
So what on earth is going on?

[ajk]

Originally Posted by guy lateur

This does indeed give the expected results on 3.X, but still gurues on the default A1200 (3.1). Linking to mieee.lib, btw. So.. what would you say is the problem: the %f printf function (whatever one gets called), or mieee.lib?

Well as far as outputting garbage goes, I'd say there is something odd going on with the printf function (whichever implementation it is). I don't see any logical reason why a printf would put out non-numeric values like that, even if it did misinterpret the parameters somehow. Maybe that also leads to crashing in some circumstances.

[guy lateur]

Originally Posted by ajk

Well as far as outputting garbage goes, I'd say there is something odd going on with the printf function (whichever implementation it is). I don't see any logical reason why a printf would put out non-numeric values like that, even if it did misinterpret the parameters somehow.

Well if it's the amiga.lib implementation, it would be surprising that it outputs anything at all in this case, as it doesn't seem to support %f -- at least not according to the docs?