Super mario 68k - Page 2

C'est sensé dès que tu as à écrire du code qui doit être validé, testé unitairement, certifié, maintenu et réutilisé aussi

oui enfin si tu as des dépendances circulaires ça n'apporte pas grand-chose ^^

Si tu as des dépendances circulaires, tu changes de conception pour ne plus en avoir.

tu m'expliques comment faire (par exemple) un générateur de code sans dépendance circulaire ? si tu veux éviter de faire une énorme fonction de plusieurs milliers de lignes il faut bien avoir des fonctions mutuellement récursives...

La récursivité est interdite aussi

(solution : ne pas embarquer de générateur de code dans des avions )

non sérieux, la récursivité est interdite ?

Dans l'aérospatial, souvent oui.

1. Imagine l'avion:
* fonction f, que doit faire le moteur?
* fonction f, que doit faire le moteur?
* fonction f, que doit faire le moteur?
* fonction f, que doit faire le moteur?
* fonction f, que doit faire le moteur?
* fonction f, que doit faire le moteur?
boum! (Trop tard!) Le temps est critique, et il est plus difficile de prévoir le temps de réponse pour une fonction récursive que pour une fonction itérative (avec des conditions sur les types de boucles aussi, mais ces conditions font aussi partie des conventions à respecter!). Il est impossible dans le cas général de prouver qu'un code termine, donc si on ne peut pas le prouver pour ton code, à toi de le changer.

2. Imagine aussi cet avion:
* fonction f, que doit faire le moteur?
* Stack overflow!
Oups... boum! La consommation de pile est aussi difficile à prévoir en récursif. (C'est pour ça que tu vas probablement te faire gueuler dessus par la LKML aussi si tu essaies de faire du récursif dans le noyau Linux avec ses piles de 4 KO. )

Ximoon pourra sans doûte t'en dire plus sur les contraintes de l'aérospatial, ayant vécu ça en première personne.

Ximoon (./35) :
La récursivité est interdite aussi

(solution : ne pas embarquer de générateur de code dans des avions )

oui dans ce contexte-là (), mais c'est pas le seul contexte dans lequel on peut être amené à "écrire du code qui doit être validé, testé unitairement, certifié, maintenu et réutilisé aussi "

Seule chose que je regrette dans ce projet, enfin, pour tout dire je n'ai essaye que les premieres demos, mais la maniabilité ne me plaisait pas du tout
Il faudrait que j'essaye la version actuelle.
Pour le reste c'est clair qu'il y a un sacre boulot !

Tiens, salut FlashZ

Rah faut bien que je regarde de temps en temps ce qui se fait

Heu la recurcivité peut etre maitrisée...
Mais bon de toute maniere dans l'aeronotique meme les malloc sont interdits lol

Pkoi lol ?

Parce que l'allocation peut échouer ou prendre plus de temps que prévu. Tu es censé savoir à l'avance combien de mémoire il te faut dans un logiciel "mission-critical".

Comment on fait pour stocker des données en mémoire sans malloc ?

Tableaux globaux de taille fixe. Et moins de données on stocke, mieux c'est, parce qu'on trouve des RAMs très petites, parfois moins d'un KO, dans ces domaines.

(un autre problème du malloc, outre le fait qu'il puisse échouer, est que (sauf algorithme spéciaux) dans la majorité des cas, son temps d'exécution n'est pas connu)
Mais comme dit, dans un système fermé et maîtrisé, le malloc est inutile.

Ximoon (./49) :
(un autre problème du malloc, outre le fait qu'il puisse échouer, est que (sauf algorithme spéciaux) dans la majorité des cas, son temps d'exécution n'est pas connu)

Je l'ai dit.

Kevin Kofler (./45) :
Parce que l'allocation peut échouer ou prendre plus de temps que prévu.

Oui mais justement, on ne peut pas prévoir Donc ça n'a aucun sens de dire que quelque chose prend plus de temps que prévu, lorsque l'évênement est imprévisible M'enfin on est d'accord sur le fond

J'aurais dû mettre "plus de temps que prévu par le programmeur incompétent qui se contente d'estimations sans garantie alors qu'il est censé coder du hard real time". "Prévu" n'implique pas forcément une garantie, mais évidemment dans le domaine de l'avionique, une prévision sans garantie ne sert à rien, tu as entièrement raison de le rappeler.

Sans compter la fragmentation etc...
Bon pour le moment je fais mon codeur crade car j'utilise un faux malloc:

// Runtime pour la gestion de la mémoire
static void *heap_malloc(unsigned int size){
	void *pReturn= (void*)&heap_datas[heap_size];
	REQUIRE(size+heap_size<heap_maxSize);
	heap_size += size + (~(size-1)&0x3); 
	return pReturn; 	
}
void heap_free(void *ptr){
	ASSERT(1);
}

* Tu ne libères jamais rien? Dans un programme qui tourne longtemps, ça épuisera vite ton heap (sauf si tu alloues une taille immense, ce qui n'est pas possible sur tous les systèmes, et là où c'est possible, c'est parce que l'OS n'alloue réellement la mémoire que quand tu y écris la première fois, donc ton programme consomme de plus en plus de mémoire plus il tourne ).
* Si tu fais ça sur TI (68k), tu as au maximum un heap de 65520 octets, ce qui n'est qu'un tiers de la RAM disponible au total.

Bref, utilisez toujours les fonctions malloc et free du système, elles existent pour une raison!

Heu en embarqué niveau A, tu n'as pas le droit au free

Ah OK, c'est toujours dans ce contexte, ça explique les choses, mais ton heap_malloc n'est pas une bonne idée non plus (et ça me surprend qu'on te le laisse passer): REQUIRE(size+heap_size<heap_maxSize); et si ce test échoue? L'avion explose? (Ou le réacteur nucléaire? )

Kevin Kofler (./52) :
J'aurais dû mettre "plus de temps que prévu par le programmeur incompétent qui se contente d'estimations sans garantie alors qu'il est censé coder du hard real time". "Prévu" n'implique pas forcément une garantie, mais évidemment dans le domaine de l'avionique, une prévision sans garantie ne sert à rien, tu as entièrement raison de le rappeler.

Surtout que tous les documents (et les sources) sont relus par des tierces personnes, tu ne peux pas te contenter d'une estimation à la louche (enfin si tu peux, mais t'as intérêt à faire large alors )

Sinon, pour l'embarqué "niveau A" (de quoi ? la DO 178 B ?), je ne sais pas si elle interdit explicitement le free, mais souvent les normes de codages informatiques internes à une boîte sont plus contraignantes.

Kevin, il faudrait que tu lises des livres sur la programmation par contrat.

Je viens d'envoyer le dossier sur ma ti mais lorsque je veux faire fonctionner le programme dans home, j'ai un message d'erreur indiquant erreur d'argument. Mon problème doit vous paraître futile mais si vous pouviez m'expliquer.. Merci.

S'il y a des arguments à passer au programme, ça doit être écrit dans sa documentation ce qu'il faut passer. T'as regardé ?