OSDK - verbosité du code généré par LCC (RCC16)...

Hello,

Je suis en train de poursuivre le dev d'un petit jeu dont j'ai envoyé la version "démo" comme contribution pour le concours CEO NY 2019.

Bien que j'ai ajouté pas mal de code, ça reste tout de même assez concis me semble-t-il au niveau du code C, et pourtant j'en viens à dépasser la barre fatidique des 37.000 octets (un peu plus de 36 Ko) au-delà desquels mes variables commencent à venir empiéter sur la mémoire écran HIRES, ce qui est pour le moins gênant, et handicape évidemment sérieusement ma capacité à finaliser mon jeu..  

L'exercice m'avait pourtant permis de tester et de démontrer la capacité d'OSDK à gérer un projet modulaire constitué de multiples fichiers (compilation de 13 fichiers .h + 12 fichiers .c actuellement, sans aucun souci, hyper rapide) et me semblait du coup pouvoir constituer un bon exemple qui aurait peut-être pu être intégré par la suite à l'OSDK...

... Mais là, c'est un peu le drame quoi... Je peux évidemment refactoriser quelques bouts de code et grapiller quelques Ko, mais je trouve quand même bizarre d'arriver à remplir la mémoire avec si peu de code, et si peu de variables (qui plus est, avec des structures de données déjà un peu optimisées...).

Bref, moi qui me voyais déjà réaliser des jeux plus ambitieux avec l'OSDK, j'ai l'impression que la verbosité du code généré limite fortement les capacités de développement en C pur...

Je vais sans doute essayer CC65 pour voir si le code généré est plus compact, mais je suis assez pessimiste, la déception est grande...

Bon, en même temps, développer en C sous Oric, c'est très agréable, mais je ne peux pas m'empêcher d'avoir l'impression de "tricher", c'est trop facile, on est quand même très loin des contraintes du BASIC ou de l'assembleur... et paradoxalement, on subit donc des contraintes de mémoire qu'on ne devrait pas avoir si le compilateur était plus performant...

PS - j'avoue que je n'ai pas encore regardé le code produit par LCC/RCC16 pour voir la qualité et la compacité du code généré.

PS - qq précisions/compléments:

• j'ai essayé de positionner l'option de compilation "agressive" -O3  dans OSDCOMP, mais la taille du fichier .TAP généré reste identique  -- actuellement: 36933 bytes long (14 bytes header and 36919 bytes of data).
  
• je pense que le souci est sans doute lié à l'utilisation des librairies suivantes de l'OSDK que j'inclus:
  

  Code:

  
#include <lib.h>
#include <sys/graphics.h>


  Je n'utilise ceci dit pas énormément de fonctions de ces librairies, et j'espère que le linker inclut bien uniquement les fonctions réellement appelées dans le code final ??
  

Facile, regarde le fichier linked.s dans ton OSDK/temp, c'est le résultat final avant assemblage (donc après la passage de linkage).

Pour savoir ou la place part, tu peux lancer OSDK_ShowMap qui va générer un rapport montrant la taille de toutes tes fonctions avec tous les labels.

Pour savoir ce que le linker inclu, il suffit de regarder le fichier .ndx dans le repertoire libs, il indique la liste de toutes les fonctions des libs, si une reference est trouvée le fichier .s complet est inclu, mais en général c'est pas bien gros.

Si tu me mets ton projet quelque part, je peux jeter un coup d'oeil,

ouaip. il est indispensable de regarder le code asm généré dans le temp.
C'est là que tu comprends deux choses :
- l'assembleur, c'et pas sorcier
- le compilateur génère plein d'instructions redondantes inutiles...

.j'aimerais bien d'ailleurs regarder à l'occasion le source du compilateur (façon Lex/Yacc ou FLex/Bison) (pas vu ça depuis l'école.... donc ca risque de pas être de la tarte)
pour voir ce qui pourrait être optimisé

Merci pour ces infos, je n'avais pas remarqué la génération dans OSDK/TMP, je me demandais effectivement où tout était généré car je ne voyais que les fichiers final.out, symbols et xaerr.txt dans BUILD...

J'ai du boulot pour examiner tout ça...

J'ai pensé à une chose qui pouvait éventuellement générer du code verbeux, c'est mon utilisation de "bit fields" dans des "struct" en C... Je l'ai fait pour gagner de la place dans mes structures de données, mais au final peut-être que je perds plus de place à cause de la complexité du code nécessaire pour l'exploiter... Je vais voir ça, si je vois des successions d'opérations de décalage/rotation/masquage de bits dans le code généré, ça va me mettre la puce à l'oreille...

@DBug: je ne trouve pas de binaire ou de fichier .bat "OSDK_ShowMap", il se trouve où ???
(NB: J'utilise bien OSDK 1.13, et j'ai le sous-répertoire "bin" dans mon PATH, mais il ne contient rien qui s'appelle OSDK_ShowMap, je vois juste un exe appelé MemMap.exe, c'est çà ?)

PS - @DrPsy, l'assembleur, c'est pas que c'est sorcier, c'est que coder une petite routine de 20-30 lignes, ça va, mais après ça devient un peu pénible quoi, surtout et spécialement avec le 6502... Ce serait du 68000 encore, je dis pas, ou même du Z80, mais là, du 6502... Faut vraiment que j'aime sacrément l'Oric (et aussi une certaine tendance inconsciente à l'autoflagellation sans doute) pour en faire, parce que sinon je crois que ça fait longtemps que j'aurais arrêté de perdre mon temps avec un CPU aussi "rustique", pour rester poli !

drpsy a écrit:.j'aimerais bien d'ailleurs regarder à l'occasion le source du compilateur (façon Lex/Yacc ou FLex/Bison) (pas vu ça depuis l'école.... donc ca risque de pas être de la tarte) pour voir ce qui pourrait être optimisé

Tout le code source du OSDK est public: http://miniserve.defence-force.org/svn/public/pc/tools/osdk/main/compiler/

laurentd75 a écrit:@DBug: je ne trouve pas de binaire ou de fichier .bat "OSDK_ShowMap", il se trouve où ???

Il y en a quelqu'un dans le repértoire "sample" comme sample\assembly\game_4kkong

Code:

@ECHO OFF

::
:: Initial check.
:: Verify if the SDK is correctly configurated
::
IF "%OSDK%"=="" GOTO ErCfg

::
:: Set the build paremeters
::
CALL osdk_config.bat

::
:: Generate the HTML file
::
%OSDK%\bin\MemMap.exe build\symbols build\map.htm %OSDKNAME% %OSDK%\documentation\documentation.css

::
:: Display the HTML file
::
explorer build\map.htm
GOTO End

::
:: Outputs an error message
::
:ErCfg
ECHO == ERROR ==
ECHO The Oric SDK was not configured properly
ECHO You should have a OSDK environment variable setted to the location of the SDK
pause
GOTO End

:End


J'ai répondu au mail

laurentd75 a écrit:Faut vraiment que j'aime sacrément l'Oric (et aussi une certaine tendance inconsciente à l'autoflagellation sans doute) pour en faire, parce que sinon je crois que ça fait longtemps que j'aurais arrêté de perdre mon temps avec un CPU aussi "rustique", pour rester poli !

C est ca qui me passionne, un proceseur "petit" qui m' oblige a surchauffer les boyaux d'la tête.
Un prof de l'époque n'aimait pas le z80 pour l'apprentissage, il le trouvait "trop confortable"

Grand, pardon, ENOOOOOOORME MERCI à DBug, qui s'est montré comme à son habitude à la hauteur de son pseudo et m'a donné une foule de conseils et d'observations sur le dev en C avec OSDK dans le cadre de mon projet.

Pour essayer de synthétiser:

• par défaut, dans le script osdk_config.bat des "samples", la variable OSDKADDR est initialisée à $800. Il est possible de modifier cette valeur par défaut et d'utiliser la valeur $500, voire la valeur $400 (mais dans ce cas le programme sera incompatible avec l'utilisation des lecteurs de disquettes), ce qui fait gagner un (tout petit) peu d'espace : 768 à 1024 octets... [EDIT: et non pas 3 ou 4 Ko comme je l'avais écrit bêtement en premier, faisant la confusion entre Ko et page de 256 octets !!]
  
  
•  l'utilitaire MemMap.exe fourni avec l'OSDK (dans \bin) est très utile et permet de lister notamment les fonctions du programme avec leurs tailles respectives.
  Il existe un exemple de script .bat  "wrapper" pour appeler ce programme dans certains samples livrés avec l'OSDK (ex: OSDK_ShowMap.bat dans \ sample\assembly\game_4kkong)
  
• il faut éviter l'utilisation de structures en C ("struct"), et préférer l’utilisation de tableaux, si possible uniquement à une dimension
  
• si on doit malgré tout utiliser des "struct" en C, il faut éviter à tout prix l’utilisation de "bit fields", car le type sous-jacent est "int", donc sur 16 bits, et le code généré est d'une verbosité incroyable, donc autant gérer ses "bit fields" soi-même sur des octets (unsigned char) avec les opérateurs de manipulation de bits classiques du C (&, ~, |, ^, <<, >>).
  
• privilégier la déclaration de tables de valeur dans des modules assembleur, le préprocesseur de XA étant très riche en fonctionnalités pour les masquages, décalages, forçages d'alignement, etc
  
•  faire attention aux instructions switch() /case , car il semble que le compilateur traite centaines valeurs littérales 8 bits sur 16 bits (peut-être faut-il faire 1 cast explicite de (char), je vais faire le test)
  
• éviter autant que possible les fonctions avec arguments et privilégier l'utilisation de variables globales (le passage de paramètres utilise une pile logicielle dédié au compilateur C en haut de la mémoire, de taille limitée comme la pile système et sa gestion n'est pas des plus efficaces, même pour les fonctions sans paramètres il y a un "LDY" inutile qui est fait...)
  
• corollaire du point précédent: éviter à tout prix les fonctions récursives style factorielle:
  int fact(int x) { if(x==0) return 1; else return x*fact(x-1); }
  
• limiter aussi l'usage de variables locales dans les fonctions au strict minimum
  
• NE PAS faire d'allocation dynamique via malloc() -- certes, la fonction est présente, mais c'est vraiment déconseillé de l'utiliser [et d'après des tests que je dois confirmer, elle semble buggée].
  
• enfin, l'OSDK transcrit chaque source .C en source .S dans le dossier /TMP, donc ne pas hésiter à aller jeter un œil pour voir la complexité (et du coup le manque de lisibilité) du code généré, et il y a aussi un fichier "linked.s" qui est l'assemblage final de tous les sources.
  
• corollaire du point précédent: ne comptez même pas pouvoir debugger un jour du code C compilé via l'OSDK avec Oricutron, la complexité du code généré rend l'exercice virtuellement impossible...
  

Et pour compléter le propos, j'ai vu hier que notre ami Fabrizio (auteur du petit jeu multi-plateformes "Cross Chase" qui a fait l'objet de publications dans le mag du CEO), avait commencé à rédiger il y a quelques jours un article de fond sur le sujet, voici la version anglaise dans son dépôt GitHub associé:
https://github.com/Fabrizio-Caruso/8bitC/blob/master/8bitC_ENG.md

Très intéressant, même si je ne suis pas d'accord avec tout (notamment, sur le fait d'avoir une fonction  "accesseur" générique pour chaque "struct").

En tous cas, il y a un passage qui m'a beaucoup interpellé, car il exprime tout à fait ce sentiment bizarre mêlé d'une forme de culpabilité que je ressens lorsque je code en C pour l'Oric:

“Sentimental drawbacks”
One not fully rational reason for not using C in this context is the fact [that] coding in C provides a less vintage experience compared to BASIC and Assembly because it was less common on the home computers from the 80s (but it was common on 8-bit business computers such as on computers that used the CP/M operating system).

Et pour répondre à Kenneth    

kenneth a écrit:C'est ca qui me passionne, un proceseur "petit" qui m' oblige a surchauffer les boyaux d'la tête.
Un prof de l'époque n'aimait pas le z80 pour l'apprentissage, il le trouvait "trop confortable"

Je râle sur le 6502, mais en vérité c'est pour ça aussi que ça me passionne au final, qu'on puisse arriver à faire de grandes choses avec un CPU aussi modeste...

... Ceci dit, déjà que j'étais jaloux de mes copains qui avaient un AMstrad CPC à l'époque, si en plus j'avais su en détail les différences entre le Z80 et le 6502 à l'époque, j'aurais vraiemnt été dégoûté, car ça n'a vraiment rien à voir effectivement, c'est clair, c'est presque trop facile !!

Je compte d'ailleurs faire quelques infidélités à l'Oric et tâter un peu du Z80 sur CPC, mais je ne pousserai pas l'offense jusqu'à aller toucher un ZX Spectrum, vade retro !!!  

Salut!

@laurentd75
Merci pour avoir lu mon document en anglais (qui est encore un "work in progress").

Je ne conseile pas du tout de mettre une fonction "accesseur" dans chaque struct.
Je montre tout simplement qu'on peut créer des classes "light" si l'on met maximum une seule "methode" par "class" par ce que cela nous permet d'éviter l'implementation d'un virtual table.
Par exemple dans le code de mon jeu Cross Chase je définis des classes "light" et cela est très efficace. Si l'on rajoutait deux ou plus méthodes sur la m^eme classe, il faudrait plutot implementer un virtual table pour réduire l'utilisation de la mémoire.

Je chercherai de clarifier ce point si c'est pas 100% clair.

Fabrizio

laurentd75 a écrit:Et pour compléter le propos, j'ai vu hier que notre ami Fabrizio (auteur du petit jeu multi-plateformes "Cross Chase" qui a fait l'objets de publications dans le mag CEO), avait commencé à rédiger il y a quelques jours un article de fond sur le sujet, voici la version anglaise dans son dépôt GitHub associé:
https://github.com/Fabrizio-Caruso/8bitC/blob/master/8bitC_ENG.md

Très intéressant, même si je ne suis pas d'accord avec tout (notamment, sur le fait d'avoir une fonction  "accesseur" générique pour chaque "struct").

En tous cas, il y a un passage qui m'a beaucoup interpellé, car il exprime tout à fait ce sentiment bizarre mêlé d'une forme de culpabilité que je ressens lorsque je code en C pour l'Oric:

“Sentimental drawbacks”
One not fully rational reason for not using C in this context is the fact [that] coding in C provides a less vintage experience compared to BASIC and Assembly because it was less common on the home computers from the 80s (but it was common on 8-bit business computers such as on computers that used the CP/M operating system).

@Fabrizio,

Tu as entièrement raison j'ai déformé ton propos, désolé, et en relisant ton article, c'est 100% clair, rassure-toi !!

En revanche, un point que j'aimerais pouvoir éclaircir:

We must avoid post-increment/decrement operators (i++, i--) when they are not needed, i.e., when we do not need the original value and replace them with (++i, --i).
The reason is that the post-increment operator requires at least an extra operation to save the original value.

Il me semble que ce conseil est également donné dans la documentation de cc65, et ce n'est pas très clair pour moi:

• déjà, je ne comprends pas bien pourquoi il serait nécessaire de sauvegarder la valeur originale du  pointeur dans une instruction du type "*ptr++ = value;"
  
• et d'autre part, j'aimerais savoir si "++i" et "i++" sont équivalents (et sinon, pourquoi l'un serait préférable à l'autre) dans une boucle for de ce type par exemple:
  
  
  
  • for(i = 0; i < 10; i++)
    
  • vs: for(i = 0; i < 10; ++i)
    
  
  

PS - Au fait, bravo pour la publication de ton article dans RetroMagazine #12 !! David La Monaca nous poste régulièrement le magazine sur la page Facebook "Oric Fans" (https://www.facebook.com/groups/oricenthusiasts/), et ça nous fait vraiment très plaisir à chaque fois,c e magazine est vraiment bien ! (dommage qu'il n'y ait pas de version anglaise, ou française, mais bon, avec Google Translate, ou mieux, avec DeepL.com, on s'en sort très bien, et même sans traducteur, on arrive à comprendre pas mal de choses déjà !!)