Langage de programmation des jeux sur Thomson

[Zebulon]

Oui c'est lourdingue. Je pense que c'était aussi dépendant des implémentations. Borland avait du implémenter les constantes à partir d'une certaine version.

[Daniel]

Y a un truc que j'aimerais bien voir en Pascal : comment affiche-t-on les sprites du chat ? Combien de temps faut-il pour effacer et redessiner un sprite ?
Plus généralement, comment accède-t-on à la RAM en lecture et en écriture ? Et plus précisément à la RAM vidéo en bitmap4 ?

[__sam__]

@Zebulon: Si ca dépend et varie d'un compilateur à l'autre, c'est que ca ne fait pas parti du langage mais d'une extension propriétaire de ce dernier. Dans tous les cas PascalBase sur thomson ne permet pas cela

@Daniel: PascalBase n'ayant pas de type pointeur il faut se faire 2 primitives PEEK et POKE en langage machine pour taper directement de le matériel (le code est donné dans le manuel). Comme il n'a pas non plus d'opérateur bit-à-bit, il faut prévoir aussi plusieurs routines en langage machine (BITAND, BITOR,BITXOR,BITNOT mais leur implémentation est absente du manuel) pour faire un POKE(#E7C3, BITXOR(PEEK(#E7C3),1).

[Zebulon]

Oui Sam je suis d'accord avec toi. C'est clair que Pascal avait ce défaut. Sur PC (et quelques machines qui tournaient sur CP/M comme le CPC sur la version TP 3) on peut dire que Borland était un standard de fait. Mais il n'y avait pas de standard.

Daniel je pense que pour des routines bas-niveau il faut coder du langage machine "inline" avec au passage la lourdeur de la sauvegarde du contexte à chaque appel et sa restauration au retour...

Non ce ne sera pas performant.

EDIT Pascal Base ou UCSD sur Thomson ne le permet pas je pense mais TP3 pouvait déjà "ancrer" une variable comme un tableau à une adresse mémoire définie. Ça marchait super bien sur PC pour accéder à la zone de mémoire vidéo facilement. Après s'il faut faire des changements de banque mémoire ou autre c'est mort.

[Daniel]

Finalement le Pascal, c'est comme le BASIC : on peut à la rigueur l'utiliser pour la logique de l'application quand il n'y a pas de contrainte de temps, mais dès qu'il faut aller vite (animation, musique, etc.) l'assembleur est nécessaire. Et donc on perd l'intérêt d'un langage de haut niveau. Il est plus simple de tout écrire en assembleur.

Au cours de ma (lointaine) carrière professionnelle j'ai connu des services d'informatique de gestion équipés d'IBM/360 qui programmaient avec des langages évolués générateurs de COBOL, d'autre qui programmaient en COBOL et d'autres qui programmaient en assembleur. Aussi étonnant que ça puisse paraître, la productivité des derniers était identique à celle des premiers, et leurs applications étaient plus rapides. Il faut dire qu'il avaient développé des "Programmes Généraux", petits utilitaires bien optimisés pour réaliser des fonctions simples : lecture/écriture de fichier, tris, recherche dans une table, impression d'un formulaire, etc.

Et autre constatation (un peu hors sujet) : La productivité et la qualité dépendent énormément du programmeur, pas beaucoup du langage utilisé. C'est une échelle de 1 à 10 en fonction du bonhomme (je n'ose pas dire de zéro à l'infini, mais je ne suis pas loin de le penser).

[Zebulon]

Oui ces langages sont utilisables pour ce qu'on pourrait appeler l'informatique de "gestion" où le temps humain est prépondérant (saisie au clavier, interprétation des données à l'écran, etc).

[__sam__]

Oui et aussi à l'enseignement aux algorithmes et à la programmation.

Pascal est suffisamment rigoureux pour cela et évite les joyeusetés plantogènes de la programmation "système" sans garde-fous avec allocation mémoire, accès aux pointeurs nuls et autres débordement de tableaux, sans oublier l'interaction avec les couches bases (interruptions, temps réel, peek-poke partout).

De nos jour c'est Python qui rempli cette fonction d'enseignement et il a un certain succès, mais là encore (en dépit des idéologues), il se saurait être utilisé pour de la programmation sérieuse.

sam (perso j'aurais préféré que ce soit Lua, mais il est moins populaire.)

[Fool-DupleX]

Il ne faut pas confondre le langage et l'implémentation de son compilateur. Turbo-Pascal était effectivement un standard de facto, Microsoft Quick Pascal ne lui arrivait pas à la cheville, et c'étaient les plus utilisés dans le monde PC à l'époque [pour le Pascal]. Et la raison est assez simple. Outre le fait que le compilateur était écrit 100% en assembleur jusqu'à la version 4.0 incluse, il produisait du code quand même pas mal optimisé. Pas d'initialisations stupides comme celle citée plus haut pour les tableaux et les variables. Elimination du code non utilisé. Overlays et allocations FAR. Borland a d'ailleurs été le premier à proposer des évaluations paresseuses pour les conditions complexes ou du code optimisé pour 286 et pour la FPU.

Par contre, éviter les joyeusetés plantogènes, je ne suis pas d'accord du tout. J'ai utilisé Turbo-Pascal à haute dose pour développer des applications MS-DOS puis Windows, et j'ai souvent planté les apps, surtout sous DOS. Dès qu'on utilise des allocations dynamiques et des pointeurs, ca part très vite en sucette. Et les fameuses runtime errors peuvent être désactivées pour gagner énormément en performance, avec le risque qui va avec (par exemple, plus de verification de dépassement, même de tableau statique).

Pour les curieux, j'invite à visiter le site http://www.turbopascal.org. C'est un hobbyiste qui a reversé le compilateur turbo-pascal et qui l'a ensuite réimplémenté en turbo-pascal. Son compilateur est plus gros et plus lent (puisque le vrai était écrit 100% en assembleur), mais il est 100% fidèle à la variante Borland du langage et surtout, il produit un binaire identique au compilateur d'origine. C'est très intéressant à étudier.

Edit: parlant d'implémentation du compilateur, celui de Pascal Base est en BASIC ... Les seules parties en assembleur sont les convertisseurs de chaînes hexadecimale et l'éditeur de source ! D'où sa lenteur indescriptible à la compilation. Et en plus, c'est du code spaghetti de la meilleure espèce.

[Dominique]

après jamais entendu des jeux programmé en Forth ni en pascal ...

Pour alimenter la conversation, en 1980 la revue BYTE (Volume 5 N° 8 - August 1980) écrivait :

Byte.gif (342.26 Kio) Consulté 2997 fois

Il semblerait que cela ne soit pas allé plus loin que le Is rumored .

La même revue publie aussi P 150 le listing d'un "Casse Brique" appelé "BreakForth" facilement adaptable sur nos machines.

https://archive.org/details/byte-magazine-1980-08

[Neotenien]

Tout simplement car il n'y a rien en Pascal Base pour gérer des tableaux aussi gros que l'image de présentation. Je ne sais pas pour Pascal UCSD, par contre.

C'est même pire que cela, car comme l'indiquait Kerningham en 1981 dans le lien plus haut il n'y a aucun support pour des données "statiques" dans le "Framework Pascal" dans le paragraphe "2.2. There are no static variables and no initialization". Résultat toutes les constantes sont initialisées par du code, ce qui prends carrément beaucoup plus de place: un static int tab[] = {1,2} qui prends 4 octets en C ou ASM, se traduit en pascal par une allocation du tableau dans la pile + l'affectation des valeurs 1 puis 2 dans un registre 16 bit et enfin l'écriture aux offsets 0 et 1 du tableau alloué ce qui doit prendre facilement

Code : Tout sélectionner

	LEAU ,S		; 2 octets (début stack-frame)
	LEAS -4,S	; 2 octets
	LDD #1		; 3 octets
	STD -4,U	; 2 octets
	LDD #2		; 3 octets
	STD -2,U	; 2 octets

3 ou 4 fois plus de place, sans compter les cycles CPU gaspillés à initialiser tout cela.

Comme je l'ai dit, ce qu'a écrit kernigan à l'époque à propos du Pascal est complètement obsolète! Et d'ailleurs le Pascal a été le premier langage de type impératif existant au monde (historiquement). Le C a suivi ce paradigme aussi.

Pascal a évolué dans bien des points, à la fin des années 80 Pascal intégrait les pointeurs de fonction, pointeurs de variables, les type Pchar (C'est l'équivalent du *Char du C) et des types qu'on ne trouve pas en C (comme les "ensemble" ou les "liste". Pascal est bcp plus adapté à l'écriture de programme de calcul scientifique que le C. Il inclut aussi l'OO (pour ceux qui sont fan de ça).

Pascal Base est malheureusement un produit inabouti, il n'inclut pas les autres types que "Integer" et tableau d'entier, mais dans d'autres systèmes, Amstrad par exemple, ou Macintosh LISA, ils utilisaient des Pascal + évolués.

Pascal UCSD fait du P-Code (et pas du compilé) ce qui le rend + lent, et en plus, dans la version TO8, utilise un DOS spécifique au Pascal (et différent de celui du Thomson) mais il inclut toutes les fonctionnalité du Pascal (contrairement à Pascal Base). Bref, dommage qu'on n'ait pas les 2 langages en 1 seul (Pour la compilation et pour le DOS) sur Thomson, ça aurait été un super langage. Quand on voit les capacités de Pure Pascal sur Atari ST/Falcon etc...

Pour info, nombre de plate forme 8 bits avaient leur langage Pascal à l'époque (Apple II, Commodore, Amstrad etc).

De toutes façons, Pascal est reconnu actuellement comme l'équivalent du C, il n'y a rien que le C fasse que le PAscal ne fasse pas, par contre l'inverse n'est pas forcément vrai... Je pense qu'à l'usage, un logiciel écrit en C mettra moins de temps à se faire en Pascal, avec en plus, une compilation stricte qui exclut nombre d'erreurs qu'on fait en C (un peu comme le garbage collector du Java). Actuellement je fais un site web sur le Pascal en parlant de Pure Pascal qui est un des tous meilleurs langage Pascal existant (et c'est sur Atari ST/TT/Falcon) il inclut les pointeurs, l'OO et toute la bibliotèqque du GEM (qui est énorme) en plus des bibliothèques propre au Pascal (Unité CRT, Graphe etc).

[Zebulon]

Ce sera un débat sans fin. Mais concernant la question de Daniel, est-il possible d'utiliser le langage Pascal sur TO pour coder l'intro d'Alley Cat et pouvoir comparer l'exécution des deux ? Les integer doivent suffirent pour animer le chat. Je ne connais pas assez le TO pour me lancer. A la rigueur sur CPC mais on ne pourrait rien comparer. L'animation du chat dans sa version est fluide et fidèle à celle sous DOS autant que j'ai pu voir hier soir.

[Fool-DupleX]

Pascal est reconnu actuellement comme l'équivalent du C

C'est sans doute pour cette raison que C est resté en tête des langages de programmation depuis 40 ans, seulement récemment détroné par Python, alors que Pascal n'est que 20ème dans la liste TIOBE. Pour cette raison aussi que C a son standard ISO, régulièrement amélioré (2018 la dernière fois), alors que Pascal, ben, euh, ah ben non (dernière modif en 1991). (Et attention: j'ai adoré Pascal, mais à une autre époque, au 20ème siècle, en gros)

comparer l'exécution des deux ?

Ne perche chat, c'est imp... mpffmmmhh

[__sam__]

Par contre, éviter les joyeusetés plantogènes, je ne suis pas d'accord du tout. J'ai utilisé Turbo-Pascal à haute dose pour développer des applications MS-DOS puis Windows, et j'ai souvent planté les apps, surtout sous DOS. Dès qu'on utilise des allocations dynamiques et des pointeurs, ca part très vite en sucette.

Humm dans mon esprit le Pascal initial n'avait pas de new()/dispose(), et c'est pour ca que je disais qu'il évitait les zones de programmation hyper-plantogènes. Mais je viens de checker, et je me suis trompé.

En effet, dès le debut Wirth a bien prévu le new() [par contre j'ai pas trouvé le dispose/delete... je ne dois pas être bien éveillé] combiné à un mécanisme d'indirection (la flèche vers le haut).

Par contre on ne peut pointer que sur des objets "pleins", par exemple un entier, un record, ou un tableau dans son ensemble (avec toutes ses cases). Le new n'est pas paramétrable. On ne peut créer qu'une seule instance de type, et pas n (variable), ce qui aurait nécessité le support de tableaux de taille variables.

En outre comme il n'y a pas d'opérateur retournant une "adresse", on ne peut pas pointer à l'intérieur d'une instance allouée et avoir des choses tordues et plantogènes comme deux tableaux se chevauchants partiellement. C'est sans doute de là que vient ma confusion.

[__sam__]

Comme je l'ai dit, ce qu'a écrit kernigan à l'époque à propos du Pascal est complètement obsolète!

Pas au moment où il l'a écrit, et pas non plus pour le PascalBase sur Thomson.

Et d'ailleurs le Pascal a été le premier langage de type impératif existant au monde (historiquement).

Algol est un langage impératif avec de la récursion, des tableaux dynamiques et tout. Il date de 1958, au moins 12 ans avant le Pascal.

Pascal a évolué dans bien des points, à la fin des années 80 Pascal intégrait les pointeurs de fonction, pointeurs de variables, les type Pchar (C'est l'équivalent du *Char du C) et des types qu'on ne trouve pas en C (comme les "ensemble" ou les "liste". Pascal est bcp plus adapté à l'écriture de programme de calcul scientifique que le C. Il inclut aussi l'OO (pour ceux qui sont fan de ça).

Non ca n'est pas le Pascal qui a évolué, mais certains compilateurs avec des extensions propriétaires qu'ils ont refusés de normaliser.

Le Pascal est décrit par la norme ISO 7185 (1983) puis révisée ultimement par ISO 10206 (1990). Aucun de ces standards officiels ne connait de Pchar, de listes génériques, ni de pointeurs sur fonctions, ni même les simples opérations bit à bits.

Nota: l'extension de 1990 définit enfin ceci principalement motivés par le standard ANSI-C de 1989:

• les unités de compilations et les exports de symboles pour de la programmation modulaire.
• Les strings y sont enfin +/- définies et manipulables (concaténation, comparaison avec padding par des blancs). Bref ce ne sont plus juste des constantes pour le writeln() de la version de 1983.
• Les fichiers à accès direct avec Seek() sont enfin supportés.
• On peut enfin ouvrir un fichier séquentiel en mode ajout ("append").
• L'exponentiation "**" (pour calculer x puissance y).
• Et surtout le "Short Circuit Boolean Evaluation" : Enfin "while (i<max) and (tab[ i ]!=n) do i = succ(i);" ne fait pas une erreur de débordement de tableau quand i=max.

Et cela 20ans après le C.

De toutes façons, Pascal est reconnu actuellement comme l'équivalent du C, il n'y a rien que le C fasse que le PAscal ne fasse pas, par contre l'inverse n'est pas forcément vrai...

les bitfields, les shortcut dans les expressions booléenes avant 1990, les opérateurs de post/pre incrementation/décrémentation, l'opérateur ternaire ?

Je pense qu'à l'usage, un logiciel écrit en C mettra moins de temps à se faire en Pascal, avec en plus, une compilation stricte qui exclut nombre d'erreurs qu'on fait en C (un peu comme le garbage collector du Java). Actuellement je fais un site web sur le Pascal en parlant de Pure Pascal qui est un des tous meilleurs langage Pascal existant (et c'est sur Atari ST/TT/Falcon) il inclut les pointeurs, l'OO et toute la bibliotèqque du GEM (qui est énorme) en plus des bibliothèques propre au Pascal (Unité CRT, Graphe etc).

As-tu déjà été voir du coté de Free Pascal, il est présent sur pas mal de machines et est assez puissant. Il supporte les opérations bit-à-bit, les Pchar, les pointeurs sur fonctions, et les champs statiques et le typage générique. De fait il dépasse la norme 1990 et se rapproche de ce dont tu parles avec le Pure Pascal sur Atari. Dommage que la norme n'ait pas évoluée avec ces extensions.

[Fool-DupleX]

PascalABC.net est tres sympa aussi, dommage qu'il genere du code .NET. Mais le couple Free Pascal/Lazarus est probablement le meilleur actuellement.