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

[DJ Omnimaga]

This is good to hear Hoffa

[ruler501]

Great job hoffa I can't wait to see what comes of this. I'll also have to move my one simple SDL program over to the nspire. How much code change is needed to go from a program written in C++ for a computer to working with the calc?

[Jim Bauwens]

Well, Ndless is focusing on C, but you can get a C++ compiler to work: http://blog.tangrs.id.au/?p=712 .
If the program only uses SDL libraries and hoffa finished this one, it should compile fine without any changes. (I think)

[ruler501]

thanks jimbauwens I forgot that ndless was mainly for C
And I actually will still need to know if this will work on a regular nspire. I dont have a CX

[Jim Bauwens]

It should work on any Nspire, if hoffa does it correctly (and I don't doubt that)

[hoffa]

I think I've finally--after many smashed walls, headaches and a bucket of aspirin--narrowed down one major issue.

Have this piece of code for instance:

Code: Select All | Copy To Clipboard

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

#include <os.h> typedef struct type1_t {     const char *s; } type1_t; typedef struct type2_t {     const char *s1;     const char *s2; } type2_t; int main(void) {     type1_t test1 = {"foobar"};     type2_t test2 = {"foo", "bar"};     printf("test1.s: %s\n", test1.s); /* Prints "foobar" */     printf("test2.s1: %s\n", test2.s1); /* Should print "foo"; doesn't */     printf("test2.s2: %s\n", test2.s2); /* Should print "bar"; doesn't */     return 0; }

As you can read, the output is:
test1.s: foobar
test2.s1:
test2.s2:
Which is completely wrong. Here's what the output obviously should be: http://codepad.org/DQcGIFy3

I think this might be one of those ARM struct alignment issues, or possibly some other bug. Either way, it has kept me from advancing with the port.
Any input on this one, ExtendeD? (or others, if you know what might be causing the problem)

[ExtendeD]

Well on my side it outputs:

Code: Select All | Copy To Clipboard

1 2 3

test1.s: foobar test2.s1: foo test2.s2: bar

Which version of GCC are you using? On which OS?
Can you also post the content of the .s file generated with nspire-gcc -S <your.c>?

[hoffa]

This is very weird, not the first time only I have the issues.

Here's the assembly code: http://pastebin.com/2Giv2ScW

I also attached a TNS that doesn't print the values.

EDIT:
Windows 7 x64 and Yagarto that uses the following versions:
binutils: 2.21
gcc:      4.6.2
newlib:   1.19.0
gdb:      7.3.1

[ExtendeD]

My .s is identical. Strangely using nspire-as on the .s file reproduces the error on my side.
I see:

.LC2:
   .word   .LC0
   .word   .LC1

Which is not good, GCC doesn't make it relocatable by Ndless.

I'm afraid you will have to use something like this:

Code: Select All | Copy To Clipboard

1 2 3 4 5 6 7 8 9 10

int main(void) {     type1_t test1 = {"foobar"};     type2_t test2 = {"foo", "bar"};     nl_relocdata((unsigned*)&test2.s1, 1);     nl_relocdata((unsigned*)&test2.s2, 1);     printf("test1.s: %s\n", test1.s); /* Prints "foobar" */     printf("test2.s1: %s\n", test2.s1); /* Should print "foo"; doesn't */     printf("test2.s2: %s\n", test2.s2); /* Should print "bar"; doesn't */     return 0; }

See http://hackspire.unsads.com/wiki/index.php/Ndless_features_and_limitations#Global_variables_and_initialization .

How much is this a problem in your case?
If it is too annoying I will then  have to integrate tangrs's ELF loader with its drawbacks.

[hoffa]

I see. But how come then that you were able to see the strings?

It does work now, but I'm afraid it will make the porting process a rather "hacky" and dirty one, with #if directives everywhere (breaking the clean code and flexibility) as SDL does rely quite a lot on structs. The code is not that simple in SDL as in the example, so the result might be spaghetti code. For now I'll try to see how it goes with nl_relocdata, if the code becomes an ugly mess I'll tell you. Thanks anyway for pointing out that fix, it'll be useful.

What are the drawbacks of using the ELF loader?

[ExtendeD]

According to tangrs the program size seems rather random, sometimes very big.
And this would require maintaining a much more complex program loader than the current one.

[alberthrocks]

BLFT is also another possible option, if that may help with making SDL port work.

[Lionel Debroux]

ELF is a very complicated format, so an ELF loader is a complicated piece of software

bFLT ( http://www.uclinux.org/bFLT/ , http://retired.beyondlogic.org/uClinux/bflt.htm ) is much simpler a format, which was suggested a number of times since the introduction of Ndless 1.0 nearly two years ago.
I once opened the source code of Linux kernel's bFLT loader ( https://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=fs/binfmt_flat.c;hb=HEAD ). It needs some porting to work outside the Linux kernel environment

EDIT: heh, I see alberthro beat me by mere seconds to mentioning bFLT
EDIT2: added a note.
EDIT3: added link to Linux's bFLT loader.

[hoffa]

I will rely on nl_relocdata as long as possible then; the advantages of keeping the ELF loader away outweigh the advantages of integrating it. But we'll see how it turns out after a few lines of code.

[lkj]

EDIT:
Windows 7 x64 and Yagarto that uses the following versions:
binutils: 2.21
gcc:      4.6.2
newlib:   1.19.0
gdb:      7.3.1

For me the program works, also windows7 x64, but yagarto with gcc 4.6.0 and gdb 7.2.