xboxdev / nxdk-pdclib Goto Github PK

Page 273: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3088.pdf

The hypot functions compute the square root of the sum of the squares of x and y , without undue
overflow or underflow. A range error occurs for some finite arguments.

For details see #57

Both tan() and tanf() seem to return 0 or garbage on any inputs I've tested them with.

Sample code:

#define DEG2RAD(x) ((x) * M_PI / 180.0)
#define DEG2RADF(x) ((x) * (float)M_PI / 180.f)
#define FAKETAN(x) (sin((x)) / cos((x)))

const double testd1 = tan(DEG2RAD(45.0));
const double testd2 = tan(DEG2RAD(90.0));
const double testd3 = tan(DEG2RAD(0.0));
const double testd4 = tan(DEG2RAD(22.5));

const float testf1 = tanf(DEG2RADF(45.0f));
const float testf2 = tanf(DEG2RADF(90.0f));
const float testf3 = tanf(DEG2RADF(0.0f));
const float testf4 = tanf(DEG2RADF(22.5f));

const double testc1 = FAKETAN(DEG2RAD(45.0));
const double testc2 = FAKETAN(DEG2RAD(90.0));
const double testc3 = FAKETAN(DEG2RAD(0.0));
const double testc4 = FAKETAN(DEG2RAD(22.5));

gdb output when running in xqemu, code compiled with DEBUG=y and inserted into the hello sample:

(gdb) p testd1
$2 = 0
(gdb) p testd2
$3 = 0
(gdb) p testd3
$4 = 0
(gdb) p testd4
$5 = 0
(gdb) p testf1
$6 = 0
(gdb) p testf2
$7 = 0
(gdb) p testf3
$8 = 0
(gdb) p testf4
$9 = 1.55740774
(gdb) p testc1
$10 = 0.99999999999999989
(gdb) p testc2
$11 = 16331778728383844
(gdb) p testc3
$12 = 0
(gdb) p testc4
$13 = 0.41421356237309509

Output from real hardware, built with my nxdk fork and added debugPrints (not sure if my float formatter is very correct):

testd1 = nan
testd2 = nan
testd3 = nan
testd4 = nan
testf1 = nan
testf2 = nan
testf3 = nan
testf4 = nan
testc1 = 1.000000
testc2 = 1.633178e+16
testc3 = 0.000000
testc4 = 0.414214

The various floor functions are not currently present in math.h

We should rebase to the latest upstream.

The upstream has added some interesting changes since then; click here to see the diff / list of commits. Most interesting:

• scanf fix (closes #16)
• memory leak in fclose
• asctime implementation
• at least 1 fix that we manually pulled (fwrite crash fix)

In the rebase process, we can also fix #17, and remove our hacks / when we pulled in changes manually (like b770ec6 and potentially 31473f1).

Attempting to minimize executable size, PDClib' print function uses a fair amount of space and is frankly unneeded, also as far as I can tell these aren't actually printed anywhere to the user(?), either the screen or via serial port. So it should be replaced with a call to DbgPrint.

int main(void)
{
    for(;;) {
        DbgPrint("Hello\n");
    }
    return 0;
}

LTO = y
CFLAGS += -Oz -DNDEBUG
CXXFLAGS += -Oz -DNDEBUG
NXDK_CFLAGS += -Oz -DNDEBUG
NXDK_CXXFLAGS += -Oz -DNDEBUG

As is, this results in a 32KB binary. Nuking the while loops in vfprintf and vsnprintf we end up with 28KB.

18e3b16 introduced a bug which breaks CMake (which was added later in 4246158); this prevents running tests on non-Xbox platforms.

$ mkdir build
$ cd build
$ cmake ..
++ CMAKE_BUILD_TYPE not set. Defaulting to 'Debug'.
-- Configuring done
CMake Error at CMakeLists.txt:309 (add_library):
  Cannot find source file:

    functions/_PDCLIB/assert.c

  Tried extensions .c .C .c++ .cc .cpp .cxx .cu .m .M .mm .h .hh .h++ .hm
  .hpp .hxx .in .txx

[...]

I'm not sure how to resolve this most gracefully.

Generally it feels like 18e3b16 shouldn't require changes to existing pdclib code. We have extension hooks now and there has always been the optimization overlay (which works as long as we don't use wildcards in our Makefiles).

See XboxDev/nxdk-sdl#20 (comment)

Additionally, I noticed that the math functions don't have any copyright header or note where they stem from / wether they were tested; this makes it hard to analyze / report such issues.

It is worth noting that the code for different precisions is exactly the same (except for type suffix on float constants). I'm not sure if this is enough / correct.

I also believe we never set up or check the control words for precision (I expected this in crt0). So it might be possible to get different results on different runs, depending on how the XBE was started?

This code (taken from Neverball) leads to faulty behaviour:

#ifdef NXDK
#include <hal/video.h>
#include <hal/debug.h>
#else
#define debugPrint(...) printf(__VA_ARGS__)
#endif
#include <stdio.h>

int main() {

#ifdef NXDK
  XVideoSetMode(640, 480, 32, REFRESH_DEFAULT);
#endif

  const char* line = "fullscreen                0";

  int ks, ke, vs;

  ks = -1;
  ke = -1;
  vs = -1;

  debugPrint("Starting scan\n");

  int ret = sscanf(line, " %n%*s%n %n", &ks, &ke, &vs);

  debugPrint("Result %d = %d %d %d\n", ret, ks, ke, vs);

#ifdef NXDK
  while(1);
#else
  return 0;
#endif
}

On my desktop with clang I get:

Starting scan
Result 0 = 0 10 26

On nxdk (in XQEMU) I only get:

Starting scan

(it seems to hang before the second debugPrint is reached)

On nxdk (in XQEMU) I got this with an older revision of the code which didn't retrieve / print int ret:

Starting scan
Result 1701995379 1819047270 10

Probably a bug in pdclib? CC @DevSolar

I was surprised to find that trunc is done using x87 by modifying the control word.

Xbox should have SSE, so we can use faster methods like these http://wurstcaptures.untergrund.net/assembler_tricks.html

This isn't necessarily much faster, but hopefully shorter code which is easier to read (and step through).

We should also review other math.h funtions like round. Also possibly affects #7 (future floor implementation).

I think we can safely ignore any precision issues beyond 32 / 64 bit IEEE float.