problème de compilation c OSDK 1.14

[goyo]

depuis que j'ai installé la dernière version ( 1.14 ) d'OSDK, mes programmes avec des tableaux de type char de plus de 127 éléments provoques une erreur de syntaxe à la compilation : 08bb.

Du coup comment gérer des tableaux de plus de 127 char avec cette dernière version ?

Aussi je ne sais pas où trouver la doc de référence des erreurs du compilateur.

Code:


void main()
{
 // 127 max ?
 char tab[]="01234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567";
 
 printf(tab);
  
}


Code:

Building the program HWSIMPLE at adress $800 [OSDK 1.14]
Compiling MAIN.C
 - preprocess
 - compile
 - convert C to assembly code
 - cleanup output
Assembling print.S
Linking
D:\osdk\sample\c\test2
Assembling
.asc "01234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567"
D:\osdk\sample\c\test2\MAIN.s(3):  08bb:Syntax error
Break after 1 errors
ERROR : Build failed.
Appuyez sur une touche pour continuer...

[Dbug]

Tu confirmes que y'a pas de problème avec la version 1.13 ?
(Tu peux avoir les deux versions installées en meme temps, et juste changer la variable d'environnement pour pointer sur la bonne version)

[retroric]

Salut DBug,

De mon côté, je confirme aussi l'existence de problèmes avec la dernière version de l'OSDK, mais au niveau de l'EXECUTION, et non pas de la COMPILATION:

Je l'ai testé sur ma dernière version d'ElectrOric, et si le build se déroule correctement, en revanche j'ai des erreurs à l'exécution au niveau d'un tableau de sprites (les sprites sont du coup mal affichés). Aucun problème avec la v1.13 ni les versions précédentes de l'OSDK.

Je vais tester le mode -O2 avec la v1.14, pour voir si le souci est lié à l'activation par défaut de -O3.

EDIT: en fait j'ai un "SET OSDKCOMP=-O2" dans mes scripts de build, donc je confirme que j'ai aussi de toutes façons des soucis (de tableaux aussi donc vraisemblablement) avec la v1.14 en mode -O2.

[retroric]

PS - je viens de tester la compilation en mode -O3... Alors là, c'est le désastre complet, au lancement de mon jeu je n'ai plus aucun graphisme qui s'affiche....

Par contre, niveau gain d'espace c'est pas mal, je passe de 36440 octets à 31861 octets de binaire généré !

[retroric]

Pour info, voici le tableau qui pose problème (certains éléments graphiques se retrouvent "inversés" avec OSDK 1.14):

Code:


extern unsigned char g_gate_sprites[][16][5] =
{   
   // 0: NOT
   { { 0x40, 0x40, 0x5E, 0x40, 0x40 },
   { 0x41, 0x44, 0x5E, 0x48, 0x60 },
   { 0x4F, 0x7F, 0x7F, 0x7F, 0x78 },
   { 0x50, 0x40, 0x40, 0x40, 0x44 },
   { 0x50, 0x7C, 0x5E, 0x7E, 0x44 },
   { 0x70, 0x62, 0x62, 0x48, 0x46 },
   { 0x50, 0x62, 0x62, 0x48, 0x44 },
   { 0x50, 0x62, 0x62, 0x48, 0x44 },
   { 0x50, 0x72, 0x72, 0x4C, 0x44 },
   { 0x50, 0x72, 0x72, 0x4C, 0x44 },
   { 0x70, 0x72, 0x72, 0x4C, 0x46 },
   { 0x50, 0x72, 0x7C, 0x4C, 0x44 },
   { 0x50, 0x40, 0x40, 0x40, 0x44 },
   { 0x4F, 0x7F, 0x7F, 0x7F, 0x78 },
   { 0x41, 0x44, 0x5E, 0x48, 0x60 },
   { 0x40, 0x40, 0x5E, 0x40, 0x40 } },
   
   // 1: AND
   
   { { 0x40, 0x40, 0x5E, 0x40, 0x40 },
   { 0x42, 0x52, 0x5E, 0x52, 0x50 },
   { 0x4F, 0x7F, 0x7F, 0x7F, 0x78 },
   { 0x50, 0x40, 0x40, 0x40, 0x44 },
   { 0x50, 0x5C, 0x78, 0x7C, 0x44 },
   { 0x70, 0x62, 0x66, 0x62, 0x46 },
   { 0x50, 0x62, 0x62, 0x62, 0x44 },
   { 0x50, 0x62, 0x62, 0x62, 0x44 },
   { 0x50, 0x7E, 0x72, 0x72, 0x44 },
   { 0x50, 0x72, 0x72, 0x72, 0x44 },
   { 0x50, 0x72, 0x72, 0x72, 0x46 },
   { 0x70, 0x72, 0x72, 0x7C, 0x44 },
   { 0x50, 0x40, 0x40, 0x40, 0x44 },
   { 0x4F, 0x7F, 0x7F, 0x7F, 0x78 },
   { 0x42, 0x5E, 0x52, 0x5E, 0x50 },
   { 0x40, 0x5E, 0x40, 0x5E, 0x40 } },

   // 2: OR
   { { 0x40, 0x40, 0x5E, 0x40, 0x40 },
   { 0x42, 0x52, 0x5E, 0x52, 0x50 },
   { 0x5F, 0x7F, 0x7F, 0x7F, 0x7C },
   { 0x70, 0x40, 0x40, 0x40, 0x46 },
   { 0x50, 0x43, 0x77, 0x40, 0x44 },
   { 0x50, 0x44, 0x54, 0x60, 0x44 },
   { 0x70, 0x44, 0x54, 0x60, 0x46 },
   { 0x50, 0x44, 0x54, 0x60, 0x44 },
   { 0x50, 0x46, 0x57, 0x60, 0x44 },
   { 0x70, 0x46, 0x56, 0x70, 0x46 },
   { 0x50, 0x46, 0x56, 0x70, 0x44 },
   { 0x50, 0x43, 0x66, 0x70, 0x44 },
   { 0x70, 0x40, 0x40, 0x40, 0x46 },
   { 0x5F, 0x7F, 0x7F, 0x7F, 0x7C },
   { 0x42, 0x5E, 0x52, 0x5E, 0x50 },
   { 0x40, 0x5E, 0x40, 0x5E, 0x40 } },

   // 3: XOR
    { { 0x40, 0x40, 0x5E, 0x40, 0x40 },
    { 0x46, 0x4C, 0x5E, 0x4C, 0x70 },
    { 0x5F, 0x7F, 0x7F, 0x7F, 0x7C },
    { 0x50, 0x40, 0x40, 0x40, 0x44 },
    { 0x70, 0x62, 0x5E, 0x78, 0x46 },
    { 0x70, 0x62, 0x62, 0x64, 0x46 },
    { 0x50, 0x62, 0x62, 0x64, 0x44 },
    { 0x50, 0x5C, 0x62, 0x64, 0x44 },
    { 0x50, 0x56, 0x72, 0x7C, 0x44 },
    { 0x50, 0x72, 0x72, 0x76, 0x44 },
    { 0x70, 0x72, 0x72, 0x76, 0x46 },
    { 0x70, 0x72, 0x5C, 0x76, 0x46 },
    { 0x50, 0x40, 0x40, 0x40, 0x44 },
    { 0x5F, 0x7F, 0x7F, 0x7F, 0x7C },
    { 0x46, 0x5E, 0x4C, 0x5E, 0x70 },
    { 0x40, 0x5E, 0x40, 0x5E, 0x40 } },

   // 4: NAND
   { { 0x40, 0x40, 0x5E, 0x40, 0x40 },
   { 0x46, 0x4C, 0x5E, 0x4C, 0x70 },
   { 0x5F, 0x7F, 0x7F, 0x7F, 0x7C },
   { 0x50, 0x40, 0x40, 0x40, 0x44 },
   { 0x77, 0x63, 0x47, 0x47, 0x66 },
   { 0x74, 0x76, 0x64, 0x74, 0x56 },
   { 0x54, 0x56, 0x54, 0x54, 0x54 },
   { 0x54, 0x56, 0x54, 0x54, 0x54 },
   { 0x56, 0x57, 0x76, 0x56, 0x54 },
   { 0x56, 0x56, 0x56, 0x56, 0x54 },
   { 0x76, 0x56, 0x56, 0x56, 0x56 },
   { 0x76, 0x56, 0x56, 0x57, 0x66 },
   { 0x50, 0x40, 0x40, 0x40, 0x44 },
   { 0x5F, 0x7F, 0x7F, 0x7F, 0x7C },
   { 0x46, 0x5E, 0x4C, 0x5E, 0x70 },
   { 0x40, 0x5E, 0x40, 0x5E, 0x40 } },

   // 5: NOR
   { { 0x40, 0x40, 0x5E, 0x40, 0x40 },
   { 0x46, 0x4C, 0x5E, 0x4C, 0x70 },
   { 0x5F, 0x7F, 0x7F, 0x7F, 0x7C },
   { 0x50, 0x40, 0x40, 0x40, 0x44 },
   { 0x70, 0x7C, 0x5E, 0x78, 0x46 },
   { 0x70, 0x62, 0x62, 0x64, 0x46 },
   { 0x50, 0x62, 0x62, 0x64, 0x44 },
   { 0x50, 0x62, 0x62, 0x64, 0x44 },
   { 0x50, 0x72, 0x72, 0x7C, 0x44 },
   { 0x50, 0x72, 0x72, 0x76, 0x44 },
   { 0x70, 0x72, 0x72, 0x76, 0x46 },
   { 0x70, 0x72, 0x5C, 0x76, 0x46 },
   { 0x50, 0x40, 0x40, 0x40, 0x44 },
   { 0x5F, 0x7F, 0x7F, 0x7F, 0x7C },
   { 0x46, 0x5E, 0x4C, 0x5E, 0x70 },
   { 0x40, 0x5E, 0x40, 0x5E, 0x40 } },

   // 6: XNOR
   { { 0x40, 0x40, 0x5E, 0x40, 0x40 },
   { 0x46, 0x4C, 0x5E, 0x4C, 0x70 },
   { 0x5F, 0x7F, 0x7F, 0x7F, 0x7C },
   { 0x50, 0x40, 0x40, 0x40, 0x44 },
   { 0x74, 0x57, 0x63, 0x77, 0x46 },
   { 0x74, 0x54, 0x54, 0x54, 0x66 },
   { 0x54, 0x54, 0x54, 0x54, 0x64 },
   { 0x53, 0x64, 0x54, 0x54, 0x64 },
   { 0x53, 0x66, 0x56, 0x57, 0x64 },
   { 0x56, 0x56, 0x56, 0x56, 0x74 },
   { 0x76, 0x56, 0x56, 0x56, 0x76 },
   { 0x76, 0x56, 0x51, 0x66, 0x76 },
   { 0x50, 0x40, 0x40, 0x40, 0x44 },
   { 0x5F, 0x7F, 0x7F, 0x7F, 0x7C },
   { 0x46, 0x5E, 0x4C, 0x5E, 0x70 },
   { 0x40, 0x5E, 0x40, 0x5E, 0x40 } }
};


Pour l'instant ceci dit, c'est le seul bug que je rencontre avec la v1.14 en mode -O2.

[goyo]

Tu confirmes que y'a pas de problème avec la version 1.13 ?
(Tu peux avoir les deux versions installées en meme temps, et juste changer la variable d'environnement pour pointer sur la bonne version)

Dbug, je confirme, pas de problème avec l'OSDK 1.13

Aussi, j'ai remarqué que lors du build de la 1.13 on ne voit pas le numéro de la version de l'OSDK, contrairement à la 1.14, info bien utile.

[Dbug]

Un truc qui me chiffonne, c'est que les gens viennent reporter leurs problèmes OSDK sur ce forum là au lieu du forum defence force.

Je ne passe ici qu'une fois de temps en temps, donc fatalement les trucs reportés ici je ne les vois pas forcément... et au final la version 1.14 avec les trois RC est bien resté en test pour plus d'un mois, et quand plus personne ne m'a rapporté des problèmes j'ai sortit la version.

Est-ce que vous confirmez que les seuls problèmes trouvés sont avec la gestion des tableaux, ou bien il y a d'autres trucs?

[retroric]

De mon côté j'ai pas mal disparu de la circulation pendant 1 mois suite à un souci perso, et après je suis parti en vacances je viens juste de revenir,  j'avais meme pas vu que la v1.14 était sortie, c'est en voyant le post de Goyo que je l'ai su...

Je pourrai faire d'autres tests la semaine prochaine pour le mode -O2, mais en ce qui concerne le mode -O3 là je crois qu'il y a vraiment du boulot et de nombreux tests à faire pour voir "l'étendue des dégâts", si tu me passes l'expression, car par ailleurs évidemment je te remercie ainsi que Fabrice pour tous les efforts investis dans cette version, et j'espère que les soucis pourront être résolus rapidement malgré tout...

[Dbug]

J'ai trouvé le problème avec les tableaux: L'ancien code de Fabrice générait des lignes de 16 valeurs hexa, et ensuite ca retournait a la ligne.
Le nouveau code génère des longues lignes si les tableaux sont larges, et ca dépasse la taille de ce que gère XA (256 charactères).

Sauf que le code de XA est aussi buggé, et ne se rend compte du problème que plus tard, d'ou le "Syntax Error".

Après, je ne sais pas: J'était en train de voir comment fixer le problème quand j'ai eu un appel du boulot pour une urgence, donc bon...

[goyo]

Merci Dbug de ton intervention.
Pardon pour le post, je posterai mes messages sur le sujet sur le forum de defense-force à l'avenir.

[Dbug]

Merci Dbug de ton intervention.
Pardon pour le post, je posterai mes messages sur le sujet sur le forum de defense-force à l'avenir.

C'est plus pour un problème global d'efficacité.

C'est comme le thread sur "comment utiliser le player mym".

Je comprend la facilité d'utiliser un forum en francais, mais d'un autre coté, ca limite les réponses aux gens qui parlent francais, et quand ca ne revient pas aux auteurs des programmes c'est contre productifs.

J'ai vu d'autres forums se plaindre de problèmes sur Oricutron, Euphoric, ceci et cela, mais si les auteurs ne sont pas au courant ca ne risque pas d'être résolu.

Surtout, maintenant les outils de traduction sont suffisamment utilisables pour que le langage ne soit plus une barrière: Sur mon forum (et celui de ma boite) il y a plein de gens ne parlant pas anglais qui copient de la traduction automatique, dans 80% des cas c'est compréhensible

[retroric]

Ceci étant DBug, tu ne peux pas non plus interdire aux gens d'utiliser ces forums sous prétexte que  ceux de Defence-Force seraient la "référence" pour tout ce qui concerne l'Oric... (d'autant plus que le CEO est tout de même une référence historique indéniable pour l'Oric...)

Et l'argument linguistique vaut dans les 2 sens, il est facile également aux anglophones d'utiliser un traducteur comme DeepL.com pour traduire du français vers l'anglais...

Il y a d'ailleurs quelques "étrangers" qui fréquentent ce forum, iss intervient régulièrement ici, et parfois Chema et Fabrizio entre autres...

Et pour finir, la réalité de la situation est qu'il y a de facto une "segmentation" assez complexe de la population de ces forums:
1) un groupe qui fréquente uniquement oric.org
2) un groupe qui fréquente uniquement defence-force.org
3) un dernier groupe enfin (heureusement le plus nombreux je crois) qui fréquente les 2 sites (mais avec des "proportions" de fréquentation différente, selon les périodes et les sujets abordés, software, hardware, ou autre...)

Du coup, c'est de  la "responsabilité" du 3e groupe à mon sens de faire le "lien" entre les 2 premiers groupes.

Dans le cas présent, c'était de notre "responsabilité" à Goyo et à moi de poster les messages sur OSDK sur les 2 forums. De ton côté, tu as fait ce qu'il fallait en venant ici régulièrement comme tu le fais...

Bref, cette discussion est intéressante pour sensibiliser les gens au fait qu'au final il vaut mieux poster ses questions techniques dans les 2 forums simultanément, ou mieux, poster dans l'un et faire un poste dans l'autre forum avec un lien vers le premier post...

Enfin, pour Oricutron, c'est encore un cas différent je pense, cle mieux est de poster des "issues" sur la page GitHub du projet...

Quoi qu'il en soit, pour en revenir aux problèmes sur la v1.14 d'OSDK, GRAND MERCI à toi d'avoir déjà trouvé une première piste, de mon côté je ferai plus de tests dès que possible, et essaierai de fournir un cas de test simple, quoique il serait bon je pense pour tester l'OSDK d'avoir justement sous le coude 2 ou 3 programmes conséquents en terme de taille de code (et idéalement faciles à tester niveau exécution) pour éprouver les nouvelles versions.

[Dbug]

Ceci étant DBug, tu ne peux pas non plus interdire aux gens d'utiliser ces forums sous prétexte que  ceux de Defence-Force seraient la "référence" pour tout ce qui concerne l'Oric... (d'autant plus que le CEO est tout de même une référence historique indéniable pour l'Oric...)

Ne me fait pas dire ce que je n'ai pas dit: Je dit juste que pour tout ce qui est OSDK c'est logique de me le signaler a moi.
Je ne vais pas m'amuser a faire le tour de facebook, twitter, oric.org, irc et usenet pour découvrir qu'il y a des problèmes dans le compilo.

Après que ce soit sur Defence-Force. ou bien sur la page Facebook du OSDK, le compte Twitter Defence-Force, c'est pas vraiment important, mais poster quelque part sans s'assurer que les auteurs sont au courant, c'est contre productif.

Pour ca que je contacted Fabrice pour tous les problèmes de compilateur.

Au final l'important c'est de signaler a la bonne personne et au bon endroit. Pas juste poster et espérer que les gens présent pourrons aider.

Bref, cette discussion est intéressante pour sensibiliser les gens au fait qu'au final il vaut mieux poster ses questions techniques dans les 2 forums simultanément, ou mieux, poster dans l'un et faire un poste dans l'autre forum avec un lien vers le premier post...

Poster dans les deux forums, c'est contre productif, la seconde solution est meilleure, et quand le problème est réglé un message final expliquant la solution.

[Ladywasky]

Bin moi je fréquente les deux forums :
J'apprends sur defence-force et j'essaie d'expliquer ce que j'ai compris et mis en pratique, sur oric.org.
Les deux forums sont supers, et les deux sites sont complémentaires.

[Ladywasky]

Pour l'OSDK, je n'ai pas testé les dernières moutures depuis janvier mais dès que je vois un bug je n'hésite pas à t'en faire part sur defence-force cher DBug.
Bises

[Dbug]

@goyo, retroric, est-ce que vous pouvez télécharger cette version du compilateur et la mettre dans votre répertoire "bin" du osdk 1.14 pour voir si ca règle les problèmes?
http://osdk.org/files/compiler.exe

[goyo]

@goyo, retroric, est-ce que vous pouvez télécharger cette version du compilateur et la mettre dans votre répertoire "bin" du osdk 1.14 pour voir si ca règle les problèmes?
http://osdk.org/files/compiler.exe

Pour moi, ça marche maintenant sans problème avec cette nouvelle version du compilateur !  

merci beaucoup DBUG !!  

[Dbug]

@goyo, cool.
Manque plus que @retroric pour savoir si ca règle ses problèmes.

Je ne sortirais une nouvelle version que si ca fixe les deux problèmes.

[retroric]

@DBug: Nope... Merci pour cette nouvelle version du compilateur, mais problème identique de mon côté... :-(

Au passage, si je peux me permettre, dans la nouvelle version d'OSDK il serait bon de corriger les erreurs de syntaxe dans les #defines pour les notes de musique dans sys/sound.h comme je te l'avais signalé, c'est pas grand-chose à corriger:

Issue #32: Syntax error in include/sys/sound.h
Details: The "#define NOTE_C-SHARP 2" uses an invalid "-" symbol that does not compile, should have been an underscore instead.

Au passage le libellé de l'issue est faux, et ça vaut pour d'autres #defiens (pour toutes les notes dièse en fait) ==> il faudrait mettre:

Details: The "#define NOTE_C- 2" uses an invalid "-" symbol that does not compile, should have been an underscore instead (or better, a _SHARP suffix).
This also applies to all #defines for sharp notes B To G, and DO to SI.

Ce "bug" cause des warnings, et cause surtout la redéfinition des notes "pures" DO à SI définies auparavant... Voici un extrait des warnings générés:

Code:


In file included from sound_fx.c:1:
V:\EMULATION\ORIC\OSDK\OSDK_1_14_patched\include\sys/sound.h:74: warning: missing white space after `#define NOTE_C'
V:\EMULATION\ORIC\OSDK\OSDK_1_14_patched\include\sys/sound.h:74: warning: `NOTE_C' redefined
V:\EMULATION\ORIC\OSDK\OSDK_1_14_patched\include\sys/sound.h:73: warning: this is the location of the previous definition
V:\EMULATION\ORIC\OSDK\OSDK_1_14_patched\include\sys/sound.h:76: warning: missing white space after `#define NOTE_D'
V:\EMULATION\ORIC\OSDK\OSDK_1_14_patched\include\sys/sound.h:76: warning: `NOTE_D' redefined
V:\EMULATION\ORIC\OSDK\OSDK_1_14_patched\include\sys/sound.h:75: warning: this is the location of the previous definition
V:\EMULATION\ORIC\OSDK\OSDK_1_14_patched\include\sys/sound.h:79: warning: missing white space after `#define NOTE_F'
.../...


Il me semble que je tavais envoyé le fichier sound.h corrigé à l'époque...

A ta dispo pour plus de tests, je peux t'envoyer la dernière version du source de mon jeu en ZIP si tu le souhaites...

[Dbug]

Au passage, si je peux me permettre, dans la nouvelle version d'OSDK il serait bon de corriger les erreurs de syntaxe dans les #defines pour les notes de musique dans sys/sound.h comme je te l'avais signalé, c'est pas grand-chose à corriger:

Comme tu l'a toi meme écrit, c'est dans la liste des trucs a corriger.

Le concept de "c'est pas grand-chose" ne prend pas en compte que:
- je traite les trucs importants en premier (ce qui touche le plus de monde et n'a pas de solution simple comme dans ton cas vu que tu avais déja fixé le problème)
- quand je fixe un truc, je met aussi a jour la documentation, des examples pour reproduire le problème avant et après, je fait tourner toute ma liste de tests pour être sur que je ne casse pas un autre truc
de facon générale, en informatique, il n'y a pas de petit problème, pour ca qu'en général on évalue le temps en multipliant par deux le temps que l'on pense que ca va prendre, et on passe a l'unité de valeur suivante... donc le petit truc qui prend 1 seconde a régler, ca coute 2 minutes, et le truc qui ne devrait pas prendre plus d'une heure fini par te prendre deux jours

A ta dispo pour plus de tests, je peux t'envoyer la dernière version du source de mon jeu en ZIP si tu le souhaites...

De facon générale, ce genre de bug (génération de code incorrect) devrait systématiquement être accompagné d'un example facile a recompiler.
Goyo m'avait envoyé son programme, donc facile de valider 1.13/1.14 et voir que ca ne marche pas.

Voir: https://fr.wikipedia.org/wiki/Exemple_minimal_fonctionnel (ou http://sscce.org et https://stackoverflow.com/help/minimal-reproducible-example)

[retroric]

Salut DBug,

Je comprends et respecte ta manière de travailler, c'est juste que je pensais que pour ces erreurs de #defines dans sound.h, la correction était simple et n'appelait pas à des tests de non-régression trop compliqués, mais je comprends que tu veuilles faire les choses une par une et résoudre d'abord les pbs importants.

Pour ce qui est du bug sur OSDK1.14 (et version patchée) sur les tableaux:

Je t'avais déjà posté plus haut le source du tableau multi-dimensionnel qui posait souci, mais effectivement j'aurais du plutôt te poster un cas de test complet.

Je te joins donc un ZIP avec un prog simple permettant de reproduire le bug sur un tableau à 3 dimensions: on constate qu'à partir d'un certain point dans le tableau, avec OSDK1.14 et la version patchée certains éléments se "répètent" ce qui change l'ordre des valeurs dans le tableau.

Pour visualiser le problème, le mieux est de compiler le programme avec OSDK1.13 et la dernière version OSDK1.14 patchée, et de comparer un à un les éléments du tableau qui s'affichent lors de l'exécution des tests, on voit qu'à partir d'un certain moment (au niveau de l'élément 2 = sprite #1), les données diffèrent. On peut contrôler les données sources dans le fichier sprites.c .

J'ai rajouté un cas de test automatisé (le premier test) qui vérifie la valeur de certains éléments du tableau. J'ai juste choisi 3 éléments particuliers du tableau dont les valeurs sont incorrectes avec OSDK1.14 patché.

Pour faciliter la construction des versions du programme pour différentes versions d'OSDK, j'ai ajouté des définitions de variables d'environnement dans "osdk_config.bat", tu comprendras facilement la logique je pense. Au passage, le script osdk_config.bat génère aussi un fichier header "osdkver.h" à la volée, qui est utilisé dans le programme pour afficher la version d'OSDK utilisée pour le compiler.

Voilà, en espérant que ce cas de test te convienne, et que tu puisse trouver l'origine du problème...

Merci par avance pour tes investigations, pour ma part debugger le compilateur est malheureusement bien au-delà de mes capacités...

Laurent

PS:
- le cas de test est prévu pour être ouvert dans Visual Studio Code, il y a des mappings pour les fichiers .bat, mais on peut bien sûr aussi tout simplement construire l'exécutable en ligne de commande...

- je n'ai pas testé les tableaux à 1 ou 2 dimensions, je ne sais pas si le nombre de dimensions influe, ou si le bug se produit simplement à partir d'un certain nombre d'éléments dans le tableau, mais  ce cas de test peut être facilement adapté à différents tableaux.

Fichiers joints

OSDK_MultiDimensionalArrayTestCase.zip (12 Ko) Téléchargé 20 fois

[retroric]

Hello,

Voici les informations que j'ai pu recueillir à l'aide de ce cas de test, en contrôlant les valeurs affichées avec la déclaration du tableau dans le fichier source "sprites.c":

- le problème qui se pose est que certaines valeurs du tableau semblent être dupliquées à l'initialisation, ce qui décale les valeurs suivantes dans le tableau, et fausse donc ensuite l'accès aux éléments du tableau.

- la première occurrence de ce bug apparaît au boute de la 103e valeur du tableau, qui est incorrecte, il s'agit d'une "répétition" de la 102e valeur du tableau, du coup la bonne valeur pour le 103e élément se retrouve affectée au 104e élément, et ainsi de suite...

Au niveau de l'exécution des tests, on retrouve 4 occurrences de ces "répétitions" de valeurs qui décalent le reste des valeurs du tableau:


- g_gate_sprites[1][4][2] répété (même valeur que g_gate_sprites[1][4][1]), ce qui décale toutes les valeurs suivantes.

- un nouveau décalage se produit pour la valeur de à la valeur
g_gate_sprites[3][7][3] répété (même valeur que g_gate_sprites[3][7][2])

- Puis encore pour g_gate_sprites[3][12][0] répété (même valeur que g_gate_sprites[3][11][4])

- Et enfin pour g_gate_sprites[5][13][1] (même valeur que g_gate_sprites[5][13][0])

Il y a donc un souci dans le compilateur au niveau du code d'initialisation d'un tableau, qui insère des valeurs en double à certains endroits, ce qui décale le reste des valeurs.

[Dbug]

Au passage, le script osdk_config.bat génère aussi un fichier header "osdkver.h" à la volée, qui est utilisé dans le programme pour afficher la version d'OSDK utilisée pour le compiler.

Pour ca, le plus simple est de modifier le make.bat pour passer la version au compilateur, style:

-DOSDKVERSION=\"%OSDKVERSION%\"

Code:

:: the -DATMOS is for Contiki
%OSDKB%\cpp.exe -lang-c++ -I %OSDK%\include -D__16BIT__ -D__NOFLOAT__ -DATMOS -DOSDKNAME_%OSDKNAME% -DOSDKVERSION=\"%OSDKVERSION%\" -nostdinc %1.c %OSDKT%\%1.c


Pour le reste, je suis en train de regarder plus en détails.

[Dbug]

Bon, le problème est identifié.

Ce ne sont que les valeurs "5C" qui sont dupliquées, et "5C" c'est le code ASCII du \.
En fait le nouveau compilateur de Fabrice génère des lignes "humainement lisibles" pour les codes affichables, et quand ca tombe sur un \ il le double parce que normalement c'est un caractère d'échappement, sauf que XA il échappe pas, donc on reste avec le double \.

J'en causes avec Fabrice.

[retroric]

Super, merci et bravo pour avoir cerné le bug si rapidement !!!!    

J'avoue que je n'avais pas songé à regarder les valeurs dupliquées, je pensais plutôt qu'il s'agissait d'un pb de taille de tableau ou de dimensions...

C'est ballot quand même le coup du caractère d'échappement, j'avoue que je n'aurais pas soupçonné qu'il y avait une "transformation" en caractères ASCII de valeurs numériques au cours du processus de compilation...

Du coup, si c'est la même chose avec les chaînes de caractères, ne risque-t-on pas d'avoir le même bug avec des programmes voulant afficher le caractère antislah dans une chaine, dans laquelle ce caractère serait donc doublé ?

PS - à ce que je comprends, cette "transformation" de valeurs en ASCII pour avoir des valeurs "humainement lisibles" dans les sources "compilés" en assembleur est donc une nouveauté de la v1.14 ?

[Contenu sponsorisé]