Derniers sujets
» Comment configurer un joystick ?
OSDK - verbosité du code généré par LCC (RCC16)... EmptyAujourd'hui à 10:18 par Jede

» Base de données listings ?
OSDK - verbosité du code généré par LCC (RCC16)... EmptyAujourd'hui à 7:17 par Symoon

» Lancement de jeux - Messages d'erreur
OSDK - verbosité du code généré par LCC (RCC16)... EmptyHier à 19:18 par Symoon

» Pub télé pour l'Oric Atmos
OSDK - verbosité du code généré par LCC (RCC16)... EmptyLun 15 Juil 2019 - 23:29 par Ladywasky

» Invitation à l'Alchimie 13
OSDK - verbosité du code généré par LCC (RCC16)... EmptyDim 14 Juil 2019 - 19:36 par didierv

» Devoirs de vacances
OSDK - verbosité du code généré par LCC (RCC16)... EmptyDim 14 Juil 2019 - 13:09 par Voyageur

» Petit jeu: robot
OSDK - verbosité du code généré par LCC (RCC16)... EmptySam 13 Juil 2019 - 12:11 par Symoon

» The voyage of the Golden Hind
OSDK - verbosité du code généré par LCC (RCC16)... EmptyVen 12 Juil 2019 - 12:47 par retroric

» récupération d'anciens listings via l'OCR Google Docs
OSDK - verbosité du code généré par LCC (RCC16)... EmptyVen 12 Juil 2019 - 12:43 par retroric

» Boitier Oric HD
OSDK - verbosité du code généré par LCC (RCC16)... EmptyVen 12 Juil 2019 - 0:54 par Symoon

» Effet sonore : Torpille spatiale (Deuxlignes !)
OSDK - verbosité du code généré par LCC (RCC16)... EmptyMer 10 Juil 2019 - 18:19 par Ladywasky

» Un "oncle/cousin" de l'Oric ?
OSDK - verbosité du code généré par LCC (RCC16)... EmptyMer 10 Juil 2019 - 12:36 par kenneth

» Zorgons Revenge cassette demo
OSDK - verbosité du code généré par LCC (RCC16)... EmptyDim 7 Juil 2019 - 9:25 par Symoon

» Aux couleurs de l'Atmos
OSDK - verbosité du code généré par LCC (RCC16)... EmptyDim 7 Juil 2019 - 3:10 par Ladywasky

» problème de compilation c OSDK 1.14
OSDK - verbosité du code généré par LCC (RCC16)... EmptyVen 5 Juil 2019 - 11:42 par retroric

Qui est en ligne ?
Il y a en tout 1 utilisateur en ligne :: 0 Enregistré, 0 Invisible et 1 Invité

Aucun

Le record du nombre d'utilisateurs en ligne est de 29 le Mer 25 Fév 2015 - 14:01
Connexion

Récupérer mon mot de passe

Statistiques
Nous avons 188 membres enregistrés
L'utilisateur enregistré le plus récent est Sebiohazard

Nos membres ont posté un total de 7436 messages dans 644 sujets
Portail ORIC




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

Poster un nouveau sujet   Répondre au sujet

Aller en bas

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

Message par retroric le Sam 19 Jan 2019 - 20:02

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..  Evil or Very Mad

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é.
retroric
retroric

Messages : 503
Date d'inscription : 09/08/2014
Age : 48
Localisation : Paris

https://github.com/retroric

Revenir en haut Aller en bas

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

Message par retroric le Sam 19 Jan 2019 - 20:16

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 ??


retroric
retroric

Messages : 503
Date d'inscription : 09/08/2014
Age : 48
Localisation : Paris

https://github.com/retroric

Revenir en haut Aller en bas

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

Message par Dbug le Sam 19 Jan 2019 - 22:03

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,

_________________

Dbug
Dbug

Messages : 171
Date d'inscription : 06/01/2013

Revenir en haut Aller en bas

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

Message par drpsy le Dim 20 Jan 2019 - 2:16

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é

_________________
>++++++++++[<++++++++>-]<.>++++++[<++++>-]<+.----.+++++++++++++..-------------.[-]
drpsy
drpsy

Messages : 200
Date d'inscription : 20/07/2014
Age : 47
Localisation : Lagny sur Marne

Revenir en haut Aller en bas

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

Message par retroric le Dim 20 Jan 2019 - 3:36

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 ! Smile
retroric
retroric

Messages : 503
Date d'inscription : 09/08/2014
Age : 48
Localisation : Paris

https://github.com/retroric

Revenir en haut Aller en bas

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

Message par Dbug le Dim 20 Jan 2019 - 10:01

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

_________________

Dbug
Dbug

Messages : 171
Date d'inscription : 06/01/2013

Revenir en haut Aller en bas

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

Message par Dbug le Dim 20 Jan 2019 - 11:13

J'ai répondu au mail Smile

_________________

Dbug
Dbug

Messages : 171
Date d'inscription : 06/01/2013

Revenir en haut Aller en bas

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

Message par kenneth le Dim 20 Jan 2019 - 13:32

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 ! Smile
C est ca qui me passionne, un proceseur "petit" qui m' oblige a surchauffer les boyaux d'la tête. clown
Un prof de l'époque n'aimait pas le z80 pour l'apprentissage, il le trouvait "trop confortable" Laughing
kenneth
kenneth
Modérateur

Messages : 664
Date d'inscription : 13/01/2013
Age : 52
Localisation : 972

Revenir en haut Aller en bas

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

Message par retroric le Lun 21 Jan 2019 - 17:25

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...


Dernière édition par laurentd75 le Sam 26 Jan 2019 - 16:35, édité 2 fois
retroric
retroric

Messages : 503
Date d'inscription : 09/08/2014
Age : 48
Localisation : Paris

https://github.com/retroric

Revenir en haut Aller en bas

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

Message par retroric le Lun 21 Jan 2019 - 17:41

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).


Dernière édition par laurentd75 le Sam 26 Jan 2019 - 16:33, édité 1 fois
retroric
retroric

Messages : 503
Date d'inscription : 09/08/2014
Age : 48
Localisation : Paris

https://github.com/retroric

Revenir en haut Aller en bas

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

Message par retroric le Lun 21 Jan 2019 - 17:46

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

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 !! Very Happy

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 !!!  Evil or Very Mad
retroric
retroric

Messages : 503
Date d'inscription : 09/08/2014
Age : 48
Localisation : Paris

https://github.com/retroric

Revenir en haut Aller en bas

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

Message par Fabrizio Caruso le Sam 26 Jan 2019 - 16:26

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 Caruso
Fabrizio Caruso

Messages : 1
Date d'inscription : 26/01/2019

Revenir en haut Aller en bas

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

Message par retroric le Jeu 31 Jan 2019 - 5:04

@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à !!)
retroric
retroric

Messages : 503
Date d'inscription : 09/08/2014
Age : 48
Localisation : Paris

https://github.com/retroric

Revenir en haut Aller en bas

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

Message par Contenu sponsorisé


Contenu sponsorisé


Revenir en haut Aller en bas

Revenir en haut

- Sujets similaires

 
Permission de ce forum:
Vous pouvez répondre aux sujets dans ce forum