Post your Nspire routines here!

[apcalc]

Looks nice bwang!

Thanks for all of your hard work!

[bwang]

Thanks! Have you tested it? If it works with your projects, I think I'll replace the skeleton in the OP with it.

[apcalc]

Yes, I have tested this and it seems to work fine!

The only complaint I have is that the compiled program, on the emulator, was 33K (this was the main.c with no actual code in it included in the library, not one of my programs).  I assume this could be caused by my GCC/Makefile I am using (it is probably including functions not actually used by the program, say atoi(, for example).  I am not good at all with coding Makefiles (I used the one that came with Ndless--not the one included with the library, which gave me an error message), so I really don't know if this is fixable.  I do like how all of the functions are in one place, though!  If nothing, I could just pick and choose the headers I want and just not build the .a file. Thanks again for your hard work on this !

[bwang]

Hmm...perhaps I should break the libraries into separate files, so the user does not need to link everything into his program.
Then again, 33K is not very large considering the fact that the Nspire has 32 MB of flash. Even accounting for the OS, it's still over 20 MB.

[apcalc]

33K is not very large in itself, but that is just what you are starting with.  I know that currently Trapped is 20K.  If I added these files in, that might double the size.  An extra, say 15-20K on every Ndless program you have on your calc can add up quickly.  There has to be some way to have it not include the unused functions.  I am almost sure TIGCC/GCC4TI dose it.  You can include one file:

Code: Select All | Copy To Clipboard

1 2	#include <tigcclib.h>

This includes all headers for use, but it does not start the program at the size of all of the headers plus your code, only your code and the functions used by it.  I am not sure how it is done, but one of the maintainers of GCC4TI might know.

[ExtendeD]

I haven't a clue what syscalls.c is. It came with Ndless.

syscalls.c contains OS stubs requires by "newlib" (the implementation of stdlib integrated with YAGARTO).
The stdlib is not really required in our case, because most of the functions can be found in the TI-Nspire OS, you just need to define them in Ndless headers.
And it appears that newlib is built without -fpic in YAGARTO (pc-relative instructions), so the stdlib functions may crash.
The stdlib should only be enabled if the program uses floating-point arithmetic, similarly to the Ndless's particles demo.

Most programs should be built with the -nostdlib option for nspire-ld.

There has to be some way to have it not include the unused functions.  I am almost sure TIGCC/GCC4TI dose it.

Headers do not influence program size, the libraries does. The .a file should contain separate .o files (as it does). The granularity for inclusion is a .o file. So your problem is quite strange.

Could you try to build with the flag -nostdlib for nspire-ld? Could you check that the .tns doesn't contain series of zeros?
Could you try to run a "arm-none-eabi-objdump.exe -D <your_program.elf>" which disassemble the program, and see which symbols appear?

[apcalc]

This is really strange, but I went back to compile the same exact file, and it compiled to 3K!

Even better, when I added the flag -nostdlib to the Makefile, the size went down to 1K (although this would only work for the blank file included with the skeleton; when I tried it on Trapped, it complained of undefined references to memset and memcpy)!!

I can't explain why it went down from 33K, as I made no edits at all, but at least it is working now!!

[DJ Omnimaga]

Did you change some files used for compiling? That seems a bit strange. I hope this doesn't mean data loss...

[ExtendeD]

when I tried it on Trapped, it complained of undefined references to memset and memcpy)!!

This is odd: this means you are using stdlib's memset/memcpy instead of the TI-Nspire OS's.
Does the .c which memsets/memcopies includes <os.h>?

[apcalc]

Yes, the .c file includeds <os.h>

Even stranger, I went to test this by renaming all instances of memset and memcpy to _memset and _memcpy, respectively, and went into <os.h> and renamed memset and memcpy (the ti-os ones) to _memset and _memcpy, respectively, and it still complained memset and memcpy were undefined, despite the fact that they are not even used by the program at all.

What is confusing me even more is that it is complaining that these two functions are not defiend in a function that does not even use these functions at all.  Here is the error I am getting:

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 20 21 22 23 24

Danny@DANNYCOMPUTER /c/users/danny/documents/ti-nspire/development/trapped $ make clean;make nspire-gcc -Os -Wall -W -fpic -fno-merge-constants -D NON_CAS -c main.c nspire-gcc -Os -Wall -W -fpic -fno-merge-constants -D NON_CAS -c utils.c nspire-ld main.o utils.o -nostdlib -o Trapped.elf utils.o: In function `setlevel': utils.c:(.text+0x28): undefined reference to `memset' utils.c:(.text+0x1f8): undefined reference to `memset' utils.o: In function `setladder': utils.c:(.text+0x504): undefined reference to `memset' utils.c:(.text+0x540): undefined reference to `memset' utils.o: In function `drawlevel': utils.c:(.text+0x8f0): undefined reference to `memcpy' utils.c:(.text+0x904): undefined reference to `memcpy' utils.c:(.text+0x918): undefined reference to `memcpy' utils.c:(.text+0x92c): undefined reference to `memcpy' utils.c:(.text+0x944): undefined reference to `memcpy' utils.o:utils.c:(.text+0x95c): more undefined references to `memcpy' follow collect2: ld returned 1 exit status make: *** [Trapped.tns] Error 1 Danny@DANNYCOMPUTER /c/users/danny/documents/ti-nspire/development/trapped $

The function "setlevel" does not call these functions at all; drawlevel only calls them in the form of the sprite function and to clear a buffer.

[Goplat]

gcc will sometimes emit calls to memset or memcpy functions if you initialize or assign large structures. Having them as macros won't help. I think we need to have real memset and memcpy functions in the library (even if all they do is call the OS functions).

[bwang]

Yes, the .c file includeds <os.h>

Even stranger, I went to test this by renaming all instances of memset and memcpy to _memset and _memcpy, respectively, and went into <os.h> and renamed memset and memcpy (the ti-os ones) to _memset and _memcpy, respectively, and it still complained memset and memcpy were undefined, despite the fact that they are not even used by the program at all.

What is confusing me even more is that it is complaining that these two functions are not defiend in a function that does not even use these functions at all.  Here is the error I am getting:

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 20 21 22 23 24

Danny@DANNYCOMPUTER /c/users/danny/documents/ti-nspire/development/trapped $ make clean;make nspire-gcc -Os -Wall -W -fpic -fno-merge-constants -D NON_CAS -c main.c nspire-gcc -Os -Wall -W -fpic -fno-merge-constants -D NON_CAS -c utils.c nspire-ld main.o utils.o -nostdlib -o Trapped.elf utils.o: In function `setlevel': utils.c:(.text+0x28): undefined reference to `memset' utils.c:(.text+0x1f8): undefined reference to `memset' utils.o: In function `setladder': utils.c:(.text+0x504): undefined reference to `memset' utils.c:(.text+0x540): undefined reference to `memset' utils.o: In function `drawlevel': utils.c:(.text+0x8f0): undefined reference to `memcpy' utils.c:(.text+0x904): undefined reference to `memcpy' utils.c:(.text+0x918): undefined reference to `memcpy' utils.c:(.text+0x92c): undefined reference to `memcpy' utils.c:(.text+0x944): undefined reference to `memcpy' utils.o:utils.c:(.text+0x95c): more undefined references to `memcpy' follow collect2: ld returned 1 exit status make: *** [Trapped.tns] Error 1 Danny@DANNYCOMPUTER /c/users/danny/documents/ti-nspire/development/trapped $

The function "setlevel" does not call these functions at all; drawlevel only calls them in the form of the sprite function and to clear a buffer.

Is this only a problem when you use the statically-linked library?

[apcalc]

This is only a problem when the flag -nostdlib is added to the ld part of the makefile (I discovered it when ExtendeD suggested it as a fix to the "random" large file size).

When I remove the flag, everything is fine.

EDIT:  Also, the program that gives that error (Trapped) does not even use the static library (I have been too lazy to change it over).

[ExtendeD]

gcc will sometimes emit calls to memset or memcpy functions if you initialize or assign large structures. Having them as macros won't help. I think we need to have real memset and memcpy functions in the library (even if all they do is call the OS functions).

In the next release of Ndless, OS calls will be defined as static inline functions. I'm not sure how GCC will react in this case.

[qazz42]

hmm, good to hear that ndless is being worked on still