Forum TI-Planet.org

Bonjour à tous !

Je pense qu'il serait bien qu'il soit effectué un lecteur de PDF pour TI-Nspire, adapté de ozbookr. Ce programme fait maximum 1.2 Mégas et tourne parfaitement à 222MHz sur PSP.
Mais voici les problèmes rencontrés :
1) C'est en C++ et il parait que des trucs en C++ ne marchent pas pour TI-Nspire (ce que je trouve vraiment très bizarre vu que théoriquement, on devrait tout pouvoir faire.
2) Pour compiler la librairie freetype nécessaire, bizarrement, la commande "make" ne marche pas avec ndlesseditor.

Pour le développement de ce projet, je propose aux plus expérimentés d'entre vous de s'y atteler (moi, je n'aurai pas le temps). Par exemple, extended, Levak, tangrs.

Imaginez un lecteur de PDF pour TI-Nspire :

C'est en C++ et il parait que tout ce qu'il y a en C++ ne marche pas pour TI-Nspire

Que ça ne fonctionne pas out of the box avec le SDK Ndless reste, à l'heure où est écrit ce post, un fait - mais il existe des programmes C++ pour Nspire (et TI-Planet s'en est fait l'écho)

(ce que je trouve vraiment très bizarre vu que théoriquement, on devrait tout pouvoir faire.

La différence entre la théorie et la pratique...

Pour compiler la librairie freetype nécessaire, bizarrement, la commande "make" ne marche pas avec ndlesseditor.

Tu m'étonnes... freetype doit avoir pas mal de dépendances non fournies par l'OS de TI ^^

Lionel Debroux wrote:Tu m'étonnes... freetype doit avoir pas mal de dépendances non fournies par l'OS de TI ^^

Faux :

Apart from a standard ANSI C library, FreeType doesn't have any external dependencies and can be compiled and installed on its own on any kind of system.

http://www.freetype.org/freetype2/index.html

mdr1 wrote:

Apart from a standard ANSI C library

Ahem.

Sinon, voir http://blog.tangrs.id.au/?p=712

mdr1 wrote:1) C'est en C++ et il parait que tout ce qu'il y a en C++ ne marche pas pour TI-Nspire (ce que je trouve vraiment très bizarre vu que théoriquement, on devrait tout pouvoir faire.

Beaucoup de concepts en C++ n'existent pas en C (même si pour la plupart ils sont reproductibles). Un exemple simple : les exceptions. Or, quand on sait qu'une grande partie des routines standard du C++ sont basées sur les exceptions pour retourner les cas d'erreur, ça limite beaucoup dans la "beauté" de coder en C++, surtout si on essaie d'adapter un programme qui se laisse libre d'utiliser tous les recoins du C++ impossible à transcrire en C.

2) Pour compiler la librairie freetype nécessaire, bizarrement, la commande "make" ne marche pas avec ndlesseditor.

Sans donner plus de précisions, on ne pourra pas te faire comprendre qu'il n'y a pas toutes les dépendances. Par dépendance on exprime la présence de telle ou telle fonction, classe, template ou bibliothèque qui ne trouve pas de correspondance dans les Syscalls connus

Pour le développement de ce projet, je propose aux plus expérimentés d'entre vous de s'y atteler (moi, je n'aurai pas le temps). Par exemple, extended, Levak, tangrs.

Être expérimenté ne veut pas dire avoir plus de temps. C'est même souvent inversement proportionnel.

Levak wrote:Un exemple simple : les exceptions. Or, quand on sait qu'une grande partie des routines standard du C++ sont basées sur les exceptions pour retourner les cas d'erreur, ça limite beaucoup dans la "beauté" de coder en C++, surtout si on essaie d'adapter un programme qui se laisse libre d'utiliser tous les recoins du C++ impossible à transcrire en C.

http://code.google.com/p/exceptions4c/

Levak wrote:Être expérimenté ne veut pas dire avoir plus de temps. C'est même souvent inversement proportionnel.

Lol, je n'ai jamais dit ça. ^^

mdr1 wrote:

Levak wrote:Un exemple simple : les exceptions. Or, quand on sait qu'une grande partie des routines standard du C++ sont basées sur les exceptions pour retourner les cas d'erreur, ça limite beaucoup dans la "beauté" de coder en C++, surtout si on essaie d'adapter un programme qui se laisse libre d'utiliser tous les recoins du C++ impossible à transcrire en C.

http://code.google.com/p/exceptions4c/

Que ce passe-t-il si dynamic_cast<T>() renvoie une exception ?
On ne parle pas d'utiliser des exceptions en C, mais de catcher en C les exceptions de la STL du C++.

C'est si compliqué que ça de porter g++ ?
Sachant qu'on a réussi à porter gcc, g++ ne devrait pas être tellement plus dur. (et puis, je suis sûr qu'il est déjà porté pour ARM).

J'imagine qu'il faudra faire des wrappers pour linker les syscalls aux librairies standards du C++.

D'ailleurs, pourquoi personne n'a créé de repository de reverse engineering avec le désassemblage ? Comme ça, n'importe qui pourrait aider à trouver les syscalls et leur correspondant dans les librairies standards.

Même moi je pourrais essayer de trouver du temps pour reverse engineer des fonctions dès que j'ai du temps libre.

Pas besoin de reverse engineer en C, il suffit de comprendre à quelle fonction standard elle correspond ou comprendre son utilité si elle ne fait pas partie de la librairie standard.

J'imagine que l'on pourrait récupérer une liste des syscalls et leur offset + désassemblage avec IDA et ensuite poster ça sur un repo genre github ou code.google.com

Vous en pensez quoi ? Cela ne devrait pas trop prendre de temps et permettrait de mettre à jour les syscalls simplement.

mdr1: je suis au courant que freetype ne dépend pas de XLib / XCB, par exemple - mais comme l'a indiqué Adriweb, même la librairie C est un problème sur Nspire.
Je crois que tu n'as pas encore assez pris conscience du point auquel, par la faute de la politique contre-productive de TI, la plate-forme Nspire n'est pas sympa à programmer en C/ASM et n'attire pas les programmeurs

C'est si compliqué que ça de porter g++ ?

Porter GCC vers un nouvel hôte, pas trop. Porter GCC vers une nouvelle target, pas très simple. Mais ici, il n'y aurait pas à porter vers une nouvelle target.

Sachant qu'on a réussi à porter gcc, g++ ne devrait pas être tellement plus dur. (et puis, je suis sûr qu'il est déjà porté pour ARM).

gcc n'a été porté pour Nspire que grâce à Linux ouvert et documenté, et g++ a les mêmes dépendances. Pour Nucleus+Phoenix fermé et non documenté, nous essayons de signifier que c'est plus difficile - surtout que le support bFLT n'est pas encore intégré à Ndless de façon utilisable, il y a un problème technique. Voir le topic que mdr1 a créé sur Omnimaga.
De toute façon, avec aussi peu de RAM, gcc, et encore plus g++, serait incapable de compiler des programmes un tant soit peu complexes en un temps acceptable (et l'utilisation de swap externe sur MSD USB n'améliorerait pas les choses, tant le débit est limité). Les plus puissantes boards ARM de 2011-2013, au moins 50 fois plus puissantes que la Nspire (Cortex A9 quad @ 1.7 GHz, 2 GB RAM - en attendant, avant la fin du premier semestre, des Cortex A15 quad @ probablement au moins 2 GHz et 4+ GB RAM), sont capables de compiler presque tout programme C/C++ avec gcc/g++/clang/clang++; mais la Nspire, fût-elle la plus puissante calculatrice du marché, est, en absolu, très peu puissante (et très chère).

D'ailleurs, pourquoi personne n'a créé de repository de reverse engineering avec le désassemblage ?

Hmm... un tel repository existe, et comme Ndless, il est publiquement accessible, je viens de vérifier

Comme ça, n'importe qui pourrait aider à trouver les syscalls et leur correspondant dans les librairies standards.

"n'importe qui", en pratique, est "presque personne"...

Pas besoin de reverse engineer en C, il suffit de comprendre à quelle fonction standard elle correspond ou comprendre son utilité si elle ne fait pas partie de la librairie standard.

Il suffit de, tout à fait. Cependant, le fait est que le reverse-engineering complet n'est fait ni pour TI-Z80, ni pour TI-68k; et l'OS des Nspire est beaucoup plus récent, beaucoup plus gros et plus complexe, donc beaucoup plus difficile et coûteux en temps à reverse engineer

J'imagine que l'on pourrait récupérer une liste des syscalls et leur offset + désassemblage avec IDA et ensuite poster ça sur un repo genre github ou code.google.com

Liste des routines, c'est ce qui existe déjà dans un repo SVN public

Vous en pensez quoi ? Cela ne devrait pas trop prendre de temps et permettrait de mettre à jour les syscalls simplement.

J'en pense que c'est une bonne idée, et qu'elle est du reste implémentée depuis assez longtemps
Mais en pratique, sache que la possibilité de mettre à jour les syscalls simplement est très théorique. Ce n'est pas aussi simple qu'on peut l'imaginer, pas parce que l'info n'est pas accessible publiquement, mais parce que ce n'est réellement pas si simple que ça, et parce que presque personne n'a à la fois l'intérêt et le temps.
Pour avoir une meilleure idée des raisons qui font que ce n'est pas trivial, tu peux essayer par toi-même d'utiliser l'OS 3.1.0.392 comme base pour les syscalls de l'OS 3.2.0.1212, 3.2.0.1219 ou 3.2.3.1233

Leur NIDS sont randomizés entre chaque OS ?
Si oui, on peut faire comme on l'a fait sur la psp: comparaison automatique des routines pour trouver lequelles se rapprochent et donc sont les mêmes syscall entre les OS mais avec un identifiant différent.

Ca serait une bonne idée de poster le lien du repo ?

D'ailleurs, pourrais-tu faire un tutoriel justement sur comment contribuer, comment fonctionnent les syscall et l'histoire des NIDS qui changent entre chaque OS, comment repérer si une fonction fait partie des libs ANSI ou pas etc...

Bonne chance

EDIT: d'ailleurs, je ne voulais pas dire de compiler g++ avec la nspire comme host mais comme target (c'est à dire crosscompiling depuis le pc pour la nspire, comme le ndless sdk actuel)