nSDL 1.1.1 Anniversary Edition—The Ultimate TI-Nspire Graphics Library!

[atiatinini]

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

[ExtendeD]

Maybe.

 atiatinini, hoffa, which version of YAGARTO/Newlib are you respectively using?

[hoffa]

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.

[atiatinini]

Thanks, I'll use those "alternative methods" then.

[ExtendeD]

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.

[hoffa]

I'd prefer that both of you contribute to find out the root cause of the issue.

I'll have a more thorough look at it tomorrow (or whenever I have the time). I checked newlib's sqrt() implementation (I'm pretty sure that's the one used), and there doesn't seem to be any global variable stuff that could cause issues.

[atiatinini]

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();

[ExtendeD]

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.

[hoffa]

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?

[ExtendeD]

I suppose this would require some effort. And for example I don't understand why _LIB_VERSION would require nl_relocdata, so identifying what needs to be patched isn't clear to me.

[hoffa]

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.

[hoffa]

I managed to get the mouse to work, at least to some degree. Some very weird bug shuts down the program at seemingly random moments, as you can see:

<a href="http://www.youtube.com/watch?v=CgPxly7vODM" target="_blank">http://www.youtube.com/watch?v=CgPxly7vODM</a>

EDIT: After numerous tests it seems that it crashes (or whatever happens) if the mouse goes to the y-coordinate 9. I see no logical explanation for this bug.

[ExtendeD]

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://www.omnimaga.org/index.php?topic=13117.0 ) would fix all these issues.

[hoffa]

Just to give you a quick heads up, the next version--0.2.0--and rather major step, will have numerous changes. Among those will be mouse support, 8 BPP support for CX (thanks to atiatini for the idea; makes it possible to port 8 BPP programs for the CX), many font-related changes (if you're the observing type you can notice one thing on the screenshot below) and a lot of under-the-hood modifications (performance, stability, etc.). Also a few surprises. Quick screenshot to show 16 BPP and palettized 8 BPP on CX (actually it's just an excuse to give the thread some color):

[Lionel Debroux]

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 ?