Won't all of these relocation issues be fixed if we use an elf/bFLT/QEMU loader?

binutils: 2.21
gcc:      4.6.2
newlib:   1.19.0
gdb:      7.3.1

BTW, atiatini, meanwhile you could use the fast inverse square root function (used in Quake for example):

float inv_sqrt(float x) {
   union {
      float x;
      int i;
   } u = {x};
   u.i = 0x5f3759df - (u.i >> 1);
   return u.x * (1.5f - (0.5f * x * u.x * u.x));
}

It's quite "hackish", but just do 1/inv_sqrt() and you have an accurate and a very fast approximation of the square root.

I'd prefer that both of you contribute to find out the root cause of the issue.
atiatinini, if you are trying to port SDL programs, you'll probably encounter other conflicts more difficult to identify and work around.

I'd prefer that both of you contribute to find out the root cause of the issue.
atiatinini, if you are trying to port SDL programs, you'll probably encounter other conflicts more difficult to identify and work around.

Yes, there are a few things that doesn't seem to work with Ndless, like srand(int) and rand();

The source code of Newlib's sqrt is this one:

http://sourceware.org/cgi-bin/cvsweb.cgi/src/newlib/libm/math/w_sqrt.c?annotate=1.1.1.1&cvsroot=src

_LIB_VERSION refers to the global variable __fdlib_version, I'm not sure why but it seems to require relocation, which cannot be provided by Ndless.
It actually doesn't work well without nSDL, it's just that the random access to memory falls to a valid address (but still not __fdlib_version).
I'm afraid we cannot trust any Newlib function without a full-featured relocator.

Can't Newlib "just" be recompiled with some nl_relocdata hacking meanwhile?

I'll try and port (wait, no, I will port) fdlibm (actually I think that's what newlib partly uses); it would be a nice add-on with the next nSDL release.

EDIT:

I compiled the fdlibm sqrt routine codes with _IEEE_LIBM and __LITTLE_ENDIAN defined, and it works nicely:



The "inside *" messages are there to prove that it is indeed using the new functions and those of the math lib magically included by GCC.
Maybe the same trick could be blindly used on newlib's libm code (which should be pretty much the same).

PS: It seems that GCC includes libm even without -lm, how do I force it not to use any libraries? Using -nostdlib with ld-nspire just makes it vomit all kinds of __aeabi_* errors.

EDIT2: I did a few changes and compiled fdlibm; it should implement all functions in <math.h> and it also contains the macros (were added from newlib's <math.h> manually). If it works well it could be a more or less lightweight replacement to newlib's libm.a. Library's attached.

I've looked closer if anything could be done for the relocation issue. Global variables containing data which need to be relocated are stored in the 'data.rel' section of the ELF file, but this doesn't mean we can blindly relocate anything in this section, since there may also be fields not to be relocated. The relocation info cannot be emitted to the binary file and the current Ndless relocator cannot do much about it.

I'd like to see if tangrs's relocator ( http://ourl.ca/15714 ) would fix all these issues.

Looks good, as usual

8 BPP support for CX (thanks to atiatini for the idea; makes it possible to port 8 BPP programs for the CX),

FWIW, while their screen sucks beyond usability, the Clickpad & Touchpad models do support 8 bpp, as shown by nDOOM

many font-related changes (if you're the observing type you can notice one thing on the screenshot below)

Transparency ?