ugBASIC est arrivé sur Olivetti Prodest PC128!

Cette catégorie traite de développements récents pour nos vieilles machines, applications, jeux ou démos... Amis programmeurs, c'est ici que vous pourrez enfin devenir célèbres!

Modérateurs : Papy.G, fneck, Carl

Neotenien
Messages : 354
Inscription : 23 oct. 2020 19:15
Localisation : Le Mans
Contact :

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par Neotenien »

spotlessmind1975 a écrit : 18 juil. 2022 09:11
Neotenien a écrit : 18 juil. 2022 04:04 Essayez de faire un programme en itératif pour trouver la sortie d'un labyrinthe hors récussif, c'est IMPOSSIBLE!!
Traduire un algorithme de récursif en itératif est toujours possible, sinon "IMPOSSIBLE". Il suffit de remplacer l'appel récursif en insérant et en récupérant des éléments d'une pile implémentée dans n'importe laquelle des structures de données fournies par le langage.
Encore une fois NON.

Lisez cet article qui vous contredit en ce qu concerne les performances. Et vous n'avez pas pris le soin de me lire sur les algorithme de tris quick sort, de résolution de labyrinthe, ou même la fonction "remplissage couleur" des logiciels de retouche photo, les algorithme ne peuvent qu'utilser que le récursif. Et pour ce qui est des performance, c'est plus rapide d'utiliser des piles (pour le récursif) que des variables tableaux (ça prend moins de cycle d'horloge).. enfin tout dépend si le processeur prend en charge les instruction de pile (comme c'est le cas du 6809 et sans doutes des proicesseurs 16 ou 32 bits).

Comme je l'ai écrit dans le message précédent, j'avais écrit en Basic avec justement des itération et surtout des tableaux de puiles (on ne peut PAS faire autrement) pour l'algorithme de tri Quick Sort en Basic des Thomson et ça a été très long à développer comparé à la programmation récursive.

Evidemment ces cas sont extrême et dans d'autres cas on préfèrera la méthode itérative (comme par exemple, calculer le résultat d'une suite numérique au rang N, ici on connait les étapes intermédiaires donc on peut utiliser l'itératif (sans les piles donc).
spotlessmind1975 a écrit : 18 juil. 2022 09:11
Neotenien a écrit : 18 juil. 2022 04:04Parce qu'il faut sauvegarder les états intermédiaires et c'est le job du récursif (autrement dit, vous devez créer dynamiquement un tableau de N/2xxN/2)
J'affirme que les langages génériques (tels que C) fournissent des primitives pour utiliser la mémoire de tas ("heap") au lieu de la pile ("stack"), c'est exactement ce type d'abstraction qui réduit les performances sur les ordinateurs 8 bits, mais pas sur les ordinateurs modernes, qui ont été conçus pour donner des primitives pour la pile ("stack").
La réponse n'est pas en rapport avec ce que j'ai écrit mais passons...
spotlessmind1975 a écrit : 18 juil. 2022 09:11
Neotenien a écrit : 18 juil. 2022 04:04Visiblement vous n'avez pas fait des études dans une grande école d'informatique comme le CNAM...
Oui c'est vrai, je n'ai pas étudié dans cette école. Je suis allé dans une université plus modeste mais où on m'a appris à utiliser deux outils (itération et récursivité) au lieu d'un, expliquant également les différences. Donc, au final, je pense que ça a marché pour moi.
Evidemment que j'ai étudié l'itératif et le récursif mais visiblement vous n'avez pas compris l'intérêt de cette programmation et avez décidé de l'occulter... J'ai expliqué ses intérêts plus haut (performance et faciliter de résoudre des problèmes complexe (qui ne peuvent pas être écrit en itératif... Encore une fois le tri "Quick sort" est impossible à résoudre en itératif seul (et sans pile donc).
Je le dis, pour moi quand on utilise des "piles" en itérant c'est identique à du récursif au niveau algorithmique, puisque les fonctions récursives sont basées sur des piles. Mais c'est beaucoup plus difficile à écrire des algorithmes avec piles en itératif qu'en fonction récursive (cf exemple de l'aogorithme de Quick Sort)..
spotlessmind1975 a écrit : 18 juil. 2022 09:11
Neotenien a écrit : 18 juil. 2022 04:04Mon algorithme assembleur utilisant les piles du 6809 pour la découverte des cases de démineur est hyper rapide et c'est du récursif
Si vous l'écrivez sous une forme itérative, c'est encore plus rapide.
Eh bien je vous met au défi d'écrire ce code en Itératif (et sans Pile donc!). Il est impossible d'écrire un tel algorithme sans piles (sans sauver les états intermédiaires) hors les piles sont justement sur quoi sont basées les fonction récursives. Si dans votre code, vous utilisez des "piles" ça utilise le même principe de codage que les fonctions récursive mais en bcp plus difficile à écrire!.
spotlessmind1975 a écrit : 18 juil. 2022 09:11
Neotenien a écrit : 18 juil. 2022 04:04A mon avis il n'y a pas de dépendance!! Si vous avez des compilateurs pour chaque machine est que, selon moi, vous avez dû écrire les spécificités fonctionnelles pour chaque machine, ça me parait complètement logique.
Le langage Pascal (mais aussi C !) Partez de quelques axiomes pris pour acquis. Dans les ordinateurs 8 bits, les développeurs ont littéralement sauté des étapes pour implémenter les contraintes que ces langages imposent, et parfois ils ont compromis sur les performances ou les ressources utilisées, voir la pile ("stack"). Parfois, ils ont décidé de déléguer certaines fonctionnalités à des bibliothèques externes, et parfois ces bibliothèques ("libraries") sont implémentées différemment ou ne sont même pas implémentées. Ils sont partis de vos considérations.
Eh oui, dans"Pascal Base" (sur les thomson), il y a 2 limitations:
- Pas de variable de type réel
- Zone RAM limité de l'éditeur (quelques dizaines de lignes seulement) du fait de l'implémntation dans la zone Utilisateur du code Pascal pour les Thomson (sans doute pour garder la compatibilité avec les MO5 et TO7/70) alors qu'en Bsic on peut écrire des centaines de lignes de code sur MO6/TO8...
Mais au moins ces compilo Pascal existaient en 8 bits (6 différents pour le C64) et c'est quand même mieux pour produire rapidement des binaires pour chaque machine que l'assembleur.
spotlessmind1975 a écrit : 18 juil. 2022 09:11
Neotenien a écrit : 18 juil. 2022 04:04Personnellement, j'aurais utilisé une librairie propre à chaque processeur et à une couche plus basse, une librairie propre à chaque machine pour exactement les mêmes commandes Basic...
Comme vous pouvez l'imaginer, il n'est pas possible d'adopter cette approche à moins de vouloir reproduire les erreurs (en termes de performances et d'utilisation des ressources) de Pascal et C. C'est une approche qui introduit des abstractions, et rend sceptique quant à la possibilité d'un port valide entre différents ordinateurs.
[/qote]
Là ça rejoint les questionnements de Daniel... C'est comme si vous essayez de travailler sur 10 chantier en même temps en appliquant les mêmes normes partout.. Hors c'est pas toujoursn possible parce que chaque terrain est différent. Mais je persiste dans mon raisonnement! Quand vous avez créé et validé une fonction Basic pour une machine, chacun des comuilateur devrait l'adopter pour chaque machine... D'ailleurs vous l'avez partiellement fait entre les MO5 (pas de gate array) et les MO5 (avec Gate Array, donc si vous avez pu le faire pour les architectures matérielles différentes, vous pouvez le faire pour les ROM non ?
spotlessmind1975 a écrit : 18 juil. 2022 09:11
Je ne comprends pas votre fixation sur les ROM d'origine. Il n'y a pas de norme dans leur fabrication, vous ne pouvez donc pas espérer en trouver beaucoup de réutilisables. Ou qu'il est logique de réutiliser, si vous voulez faire quelque chose de professionnel.
Pour la nème fois, je le répère, c'est simplement pour économiser de la RAM! Quand vous réécrivez (à l'identique) des fonctions existant en ROM dans la RAM en assembleur c'est de la place en moins pour le logiciel lui même. Et quand j'ai soumis le petit algorithme pour les animations de Ken et Blanka et quen ça a été confronté à ce probème de RAM (et qu'il fallait déjà utiliser d'autre bank)... Vous dites que les 8 bits sont limités en RAM mais si vous la gaspiller à réécrire des procédure existante dans la ROM. L'écriture complète des caractères et des fonction en mode bm16 est parfaitement justufiée, mais dans les autres modes ? Oui c'est complexe à écrire mais on n'a jamais dit que l'informatque était simple.

Et pour ce qui est de l'abstraction, on a smeble-t-il pas la même définition de ce c'est, du moins en POO, le noiveau d'abstration fat référence à des niveaux hiérarchique dans des classes. Mais je suppose qu'ici, vous voulez parler du fait qu'une grammaire de langage doit rester la même quelle que soit la machine à compiler... Et justement vous avez dit que certaines des fonction Basic n'exciste pas sur certaines machines donc ça signifie quand même que vous travaillez au cas par cas non ?
Neotenien a écrit : 18 juil. 2022 04:04e ne sais pas si vous comprenez ce que j'essaie de dire...
Vous essayez de faire valoir que les abstractions ont un sens sur un ordinateur 8 bits, mais hélas, les preuves sont contre.
Eh non vous avez tort! Si l'abstraction est ce qui est donné dans cette définition, je vous donne au moins un exemple, c'est le Basic Microsoft qui a été adopté sur Thomson (6809), MSX (Z80), BBC (6502), Oic (6502) et PC (8088). Mais évidemment chaque machine avait ses propres développeurs mais pour UG Basic êtes vous seul à le développer ?
spotlessmind1975 a écrit : 18 juil. 2022 09:11
Neotenien a écrit : 18 juil. 2022 04:04Si ça l'est, la différence est énorme entre le Pascal et le C, où en Pascal on peut se concentrer uniquement sur l'application en elle même et pas perdre 90% du temps à voir si tel espace mémoire va être débordé etc...
Je ne sais pas combien d'expérience vous avez en C (ça ne semble pas beaucoup) mais le problème de la gestion de la mémoire dynamique est aussi en Pascal, du moins si vous l'utilisez. Si vous utilisez de la mémoire statique, C et Pascal sont équivalents. Comparé au temps qu'il faut pour écrire un logiciel, ce n'est pas une mesure très significative pour les ordinateurs 8 bits. Les outils qui existent aujourd'hui sont des dizaines de fois plus productifs que ceux de l'époque, et Pascal n'est pas une "solution miracle" en ce sens.
J'ai suffisamment d'expérience en C pour en connaitre les problématique et limites (j'ai commencé dans les années 90 et j'utilise des langages de types PHP qui ont la mêmes syntaxe que le C mais sans les inconvénients de RAM)... Vous pouvez considérer que j'ai au moins 5 ans d'expérience en C (dans l'étude). Et le C est très limité quant aux possibilité des librairies comparé au Pascal (il n'y a PAS d'équivalent, de bases, aux Unités Graph et CRT par exemple). Eh non il n'y a PAS de base les problèmes de gestion de RAM en Pascal. Les poinyeur en Pascal ont été intriduit tardivement et l'Objet également, mais peut de développeur Delphi utilisent les Objet et de nos jours, les ingénieurs commence enfin à comprendre que le concept objet est un énorme problème à plein de pont de vue! Et que finalement ça a couté des milliard d'euros à des enytreprises d'avoir opté pour cette tecno pour des résultats bien en dessous des attentes comparé à l'ippératif (alors que quand j'ai appris l'objet au début des années 2000 je n'y voyais pas di'ntérêt comparé justement aux pointeurs des langages C et Pascal (pointeurs de variables et de fonctions), c'était exactement la même chose. Les poinyteurs sont un énorme problème dans ces langage s'il n'y a pas de système de gestion de RAM... Le Pascal a un système de ramasse miette (que ça soit pour les pointeurs que pour les objets) qui n'existe pas en C.

Alors certes certaines études montrent que la compilation C donne les binaires les plus rapides existant, mais cela dépend en grande partie de la qualité du compilateur... Un exemple, pour le PHP5 et PHP7, j'avais créé un algorithmede création de permutation (10 éléments) et la version 7 de PHO s'avère être 5 fois plus rapide (eyh oui!!) que la version 5. Peut-être que Free Pascal pêche un peu à ce niveau actuellemement (donnant des binaires 2.5 fois plus lent apparemment) mais Pascal est le langage usant le moins d'espace RAM pour un même algorithme et surtout demandant beaucoup moins de temps de développement parce que c'est justement un langage orthogonal (c'est à dire avec une synthaxe atomique pour une même fonction ce que ne fait pas le C).

En Pascal on peut croire que les tableaux soient limité à 256 éléments mais en fait NON!! puisqu'on peut avoir plusieurs dimensions à un tableau, on peut déclarer, par exemple, un Tableau (voiture[4][255]) pour déclarer un tableau de 4090 éléments et j'ai créé des algorithme capable de gérer ça avec un index de type entier. (on peut avoir un élément en indiquant l'élément :
voiture)
spotlessmind1975 a écrit : 18 juil. 2022 09:11
Neotenien a écrit : 18 juil. 2022 04:04Vous ne prenez pas le problème par le bon bout.

À mon avis, c'est vous qui n'avez pas bien compris de quoi nous parlons. Si vous me dites que vous voulez faire un produit éducatif pour expliquer ce qu'est la 3D, ce que vous écrivez me convient. Si on parle d'un jeu vidéo où il y a des attentes à respecter en termes de qualité et de jouabilité, cela n'a plus beaucoup de sens: Minotaure 3D ne semble jamais dépasser les 10 nœuds, soit l'équivalent de deux tétraèdres, ce qui me semble un peu éloigné de ce dont je parle.

En plus des noeuds des ennemis. Je pense qu'ici (minotaure 3D), ils calcule vraient les position des "sommets" (ou noeud) en trigonométrie (ou en perspective ?). Samuel m'a expliqué le principe de la virgule fixe, en vérité c'est peu différent de l'IEEE754 mais il est vrai que la gestion de la position de la virgule en IEEE754 doit être complexe. C'est une quetsion intéressante à étudier. Voir s'il est possible de directement tracer les sommets d'un labyrinthe 2D vers la 3D, d'ailleurs, ce sont juste des translation de points (verticaux et horizontaux) après tout! Ca reprend le principe de la 3D isomorphique mais en 3D réel...

Comme je l'ai écrit précédemment, il y a certains jeux 3D sur Atari ST qui sont très lent (idem sur Atari Falcon)

On peut faire du "ray casting" en algorithmique parce qu'il y a des contraintes, mais je pense que pour un tétraèdre ou un cube dont on veut faire interragir avec l'utilisateur suivant les 2 angles, là la trigonométrie me parait incontournable.

Quappelez vous de la fausse 3D ? Parce que le Doom avec les Wad sur Atari Falcon est très très lent (moins d'1 image par seconde) qui est pourtant avec un prçocesseur 68030 à 16 MHz et un DSP à 32. Je pense quand même que,les sommet des polygones sont donné via des calculs trigonométrique (ou, peut-être, par des calculs de perspectives, ce qui rejoint le MODE 7 des Super Nintendo et ce que permet le mode Perspective des CSS3). Pour le reste (mapping de texture) c'est entièrement des calculs de perspective comme indiqué ici.
Neotenien
Messages : 354
Inscription : 23 oct. 2020 19:15
Localisation : Le Mans
Contact :

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par Neotenien »

__sam__ a écrit : 18 juil. 2022 14:58
Eh bien vous avez tort!!

Essayez de faire un programme en itératif pour trouver la sortie d'un labyrinthe hors récussif, c'est IMPOSSIBLE!!
Hum je n’aime pas le ton que tu prends Neotenien :| Et cela d’autant plus que les arguments de Spotlessmind1975 sont très corrects et appuyés sur autre chose que des arguments d’autorité hors de propos, ou des intuitions non validées par l’experience (le calcul de la rotation et projection 3d sur l’écran c’est plusieurs produits matriciels 4x4 (car on travaille en espace projectif), soit plusieurs centaines d’ops fpu pour toute la figure. On est plutôt se l’ordre de 300 à 600ms par image pour un tetrahedre sur les 8 bits si on utilise pas de trucage).
Je parle ici de représentation fil de fer, on a juste besoin de calculer 4 points puis de joindre les sommets avec un "line" Les objets 3D sont basés sur des vectrex (soit des triangles).

Pour ce qui est du récursif, j'ai expliqué ce que j'appelais l'approche récursive est celle utilisant des piles, alors que l'approche itérative non (c'est peut-être de là que vient la non compréhension). Si une itération utilise des piles pour moi c'est la même chose que du récursif mais en plus complexe à programmer. Et franchement utiliser des piles en itératif c'est galère (c l'exemple du tri "Quick sort" en basic, ou même l'algorithme de découverte en cascade pour le jeu "démineur extrème" en utilisant des pile... Pfff... avec une fonction récursive ça se fait les doigt dans le nez (je l'ai fait en JavaScirpt) mais à devoir utiliser des "piles" comme variables..).
__sam__
Messages : 7923
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par __sam__ »

Tu t’enerves pour rien Neotenien.

Spotlessmind1975 a raison de dire que tout, je dis bien tout algorithme récursif peut se transformer en itératif. C’est un résultat mathématiquement prouvé qui se démontre en exercice en étude supérieures: http://zanotti.univ-tln.fr/ALGO/I51/Rec ... ursivation

C’est pas par ce que toi tu ne l’as pas vu dans tes études que ça n’existe pas tu sais. Tiens voila d’ailleurs un quick sort non recursif: https://www.geeksforgeeks.org/iterative-quick-sort/ ou encore https://stackoverflow.com/questions/299 ... -and-stack

Allez, c’est mon dernier argment sur le sujet ”impossible à faire sans récursivité”: tu n’es pas sans savoir que les machines de Turing sont universelles (si tu ne le sais pas il est temps de se documenter sur la thèse de Church). Tout ce qui est calculable peut être calculé par un machine de Turing. Dit autrement, on peut faire tourner n’importe quel algorithme avec elles. Or, quand tu regardes leur codage et leur fonctionnement, il n’y a rien de rien de récursif dedans. Elles ne peuvent faire que de l’itératif. Et pourtant on peut leur faire exécuter tous les algorithmes, y compris récursif. C’est dingue non? Et juste pour info ca ne change pas la classe de l’algorithme (un polynomial reste polynomial).

Quant aux autres affirmations, tu mélanges un peu tout au point d’écrire des absurdités. Exemple
...Et le C est très limité quant aux possibilité des librairies comparé au Pascal (il n'y a PAS d'équivalent, de bases, aux Unités Graph et CRT par exemple)"
Tu montres juste que tu ne connais rien à l’écosystème du C et considère, encore une fois, que puisque tu ne connais pas, ben ca n’existe pas.

Sam .oO(on se demande bien comment le C si limité existe encore. Il est quand même à la base de quasi tous les soft, y compris php, python (leur moteur est écrit en C), et tiens gnu-pascal là où le Pascal, pourtant si génial, n’est visible quasiment nulle part).
Dernière modification par __sam__ le 18 juil. 2022 17:04, modifié 9 fois.
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Avatar de l’utilisateur
pascalien
Messages : 964
Inscription : 21 janv. 2019 23:40
Localisation : 93200 ST DENIS
Contact :

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par pascalien »

Neotenien a écrit : 18 juil. 2022 04:04 Essayez de faire un programme en itératif pour trouver la sortie d'un labyrinthe hors récussif, c'est IMPOSSIBLE!!
Dans le cas ou l'entrée et la sortie sont sur des bords, il n'y a besoin d'aucune recursion ou mémoire.
Il suffit de longer le mur à droite ou à gauche.
Neotenien
Messages : 354
Inscription : 23 oct. 2020 19:15
Localisation : Le Mans
Contact :

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par Neotenien »

__sam__ a écrit : 18 juil. 2022 16:35 Tu t’enerves pour rien Neotenien.

C’est pas par ce que toi tu ne l’as pas vu dans tes études que ça n’existe pas tu sais. Tiens voila d’ailleurs un quick sort non recursif: https://www.geeksforgeeks.org/iterative-quick-sort/
Bizarre dans ta page il y a cette fonction

Code : Tout sélectionner

void quickSort(int A[], int l, int h)
{
    if (l < h) {
        /* Partitioning index */
        int p = partition(A, l, h);
        quickSort(A, l, p - 1);
        quickSort(A, p + 1, h);
    }
}
Qui est récursive... Et en plus c'est écrit "récursif dans la page

D'autre parts pour
__sam__ a écrit : 18 juil. 2022 16:35 ou encore https://stackoverflow.com/questions/299 ... -and-stack
Il n'y a pas de solution non récursive dans cette page. La dernière réponse donnée a cette fonction là notamment

Code : Tout sélectionner

public static void quickSort(final int size) {
    int l = 0;
    int r = size - 1;
    int q, i = 0;
    int tmpr = r;
    while (true) {
        i--;
        while (l < tmpr) {
            q = partition(l, tmpr);
            arr[tmpr] = -arr[tmpr];
            tmpr = q - 1;
            ++i;
        }
        if (i < 0)
            break;
        l++;
        tmpr = findNextR(l, size);
        arr[tmpr] = -arr[tmpr];
    }
}
ici findNextR(l, size) est une fonction avec pasage de paramètres mais utilisant des variables externes ("l" est recalculé à chaque fois...) on a passage de paramètres par valeur (pile, état) à la fonction qui est différent à chaque foi. mais création d'autres variables tableau "à la volée"
__sam__ a écrit : 18 juil. 2022 16:35 Allez, c’est mon dernier argment sur le sujet ”impossible à faire sans récursivité”: tu n’es pas sans savoir que les machines de Turing sont universelles (si tu ne le sais pas il est temps de se documenter sur la thèse de Church). Tout ce qui est calculable peut être calculé par un machine de Turing. Dit autrement, on peut faire tourner n’importe quel algorithme avec elles. Or, quand tu regardes leur codage et leur fonctionnement, il n’y a rien de rien de récursif dedans. Elles ne peuvent faire que de l’itératif. Et pourtant on peut leur faire exécuter tous les algorithmes, y compris récursif. C’est dingue non? Et juste pour info ca ne change pas la classe de l’algorithme (un polynomial reste polynomial).

Quant aux autres affirmations... humm tu mélanges un peu tout.
"Tout ce qui est calculable peut être calculable par une machine de Turing" (pour des entiers) : oui.

"Il n'y a rien de récursif là dedans"... Les fonctions récursives s'appellent elles même mais le principe de piles (pour sauver les paramètres passés) est toujours là. Que la fonction s'appelle elle même ou qu'une autre fonction l'appelle avec des paramètres d'état différent, le principe de pile de variable est toujours là. La récursivité est une utilisation des fonctions avec passages de paramètres, ma foi fort pratique (évitant les erreurs de programmatin de l'itératif, l'utiisation de variable supplémentaires et donc, des effets de bord). Et c'est d'ailleurs le role même d'une fonction mathématique. Une fonction tourne avec des paramètres qui sont des états. L'avantage majeur de la récursivité, je pense, est le gain d'espace RAM (on sauvegarde que les états nécessaire sans avoir à rajouter d'autres variables (notamment pour des boucles) et permettre égalmement une parfaite ortogonalité, c'est à dire que là, chaque fonction travaille avec un environnement propre sans devoir créer des effets de bord (et entrainer des bugs éventuiels). Le paradigme fonctionnel évite aussi ces effets de bord.

Ok je crois que ma demande initiale concernait le fait de ne pas avoir de fonction avec passage de paramètres (qui nécessite forcément des piles).

Quand je parlais d'impossibilité, c'était de dire qu'en dehors des fonctions avec passage de paramètre, il est impossible d'écrire l'algorithme de quick sort, ce sont des machines à état. Mais il faut de toute façon une "pile" pour sauver l'état de chaque variable, donc c'est une démarche "récursive" ou qui part d'une fonction récursive (en Basic Thomson c'était ce que j'avais fait pour le tri "quick sort", im), c'est pas à proprement parler d'une fonction "récursive" et pourtant le code résultant suit le même principe. Aucune des pages que tu m'as indiqué Samuel, à poropos du tri Quick Sort n'exclut une fonction récursive (je les ai biens scruté, donc OUI cet algorithme est impossible sans fonction récursive, ou du moins sans utilisation de "pile" à minima (ce qui revient au même))... Et c'est pareil pour les algorithme de sortie de labyrinthe, de l'outril "peinture" dans les logiciels de retouche photo. Ils ne peuvent se résoudre sans avoir de piles de données (qui sont des états intermédiaires), donc nécessité (à mon sens, pour de la programmation propre) d'avoir des fonctions récursives (pour éviter les effets de bord).

Je lis dans l'article wikipedia à propos de la machine de Turing "D'autre part, à chaque étape de la procédure, la personne doit se placer dans un état particulier parmi un ensemble fini d'états. La procédure est formulée en termes d'étapes élémentaires du type : « si vous êtes dans l'état 42 et que le symbole contenu sur la case que vous regardez est « 0 », alors remplacer ce symbole par un « 1 », passer dans l'état 17, et regarder maintenant la case adjacente à droite »." et justement les piles (mécanismes des fonctions récursives) servent à sauver des états. et c'est le principe même des fonctions (passages de paramètres) qui sont des états.
__sam__
Messages : 7923
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par __sam__ »

Bien entendu qu’ils montrent l’implémentation recursive de référence avant d’expliquer la version dérécursivisé (c’est le terme consacré).

Contrairement a ton affirmation, c’est bel et bien une version non recursive de l’algo. Tu confonds récursivité et utilisation de paramètres formels. Ca n’as juste rien à voir. Si tu veux tu peux passer les paramètres à findNsxtR() via des globales, ou inliner son code. Ça ne change rien. En récursif, si tu fais cela, l’algo ne marche plus.

Du reste, cette version de quicksort non recursif est parfaitement transposable en ugBasic. Elle sera tout aussi rapide que la version récursive.
Dernière modification par __sam__ le 18 juil. 2022 18:38, modifié 5 fois.
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Neotenien
Messages : 354
Inscription : 23 oct. 2020 19:15
Localisation : Le Mans
Contact :

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par Neotenien »

A supposer qu ug Basic supporete la récursivité, est ce que ce code serait bon ?

Code : Tout sélectionner

PROCEDURE factoriel[i]
IF i>1 THEN
    RETURN factoriel[i-1]*i
ELSE
    RETURN 1
END PROC
PRINT "Factoriel de 10", factoriel[10]
Neotenien
Messages : 354
Inscription : 23 oct. 2020 19:15
Localisation : Le Mans
Contact :

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par Neotenien »

__sam__ a écrit : 18 juil. 2022 18:13 Bien entendu qu’ils montrent l’implémentation recursive de référence avant d’expliquer la version dérécursivisé (c’est le terme consacré).

Contrairement a ton affirmations, c’est bel et bien une version non recursive de l’algo. Tu confonds récursivité et passage de paramètres. Ca n’as juste rien à voir. Du reste, cette version de quicksort non recursif est parfaitement transposable en ugBasic.
Oui bon je me suis planté depuis le début, j'ia confondu "état" (pile) et récursivité mais la récursivité utilise les piles quand même.,Mmais faut que je justifie la pertinence de la récursivité, et ça l'est de par la simplicité d'écrire des algorithme sur des cas complexe (labyrinthes) et d'évoiter des effets de bord. Franchement, ça aide vraiment les fonctions récursive et sans perte d eperformance (puisque si ça utilise des piles en ASS6809 ça prend moins de cycle qu'avec les LDD et STD classique et en plus ça énonomise une gestion complexe de variable, vous qui m'indiquiez utiliser la pile sur le 6809 au départ, maintenant que j'ai trouvé un argument en sa faveur...

Remarque quand j'ai dit avoir écrit un algo en basic sur le quick sort, j'ai été obligé d'utiliser des piles et j'ai fait la confusion entre les 2 aussi parce que dans mon espri, Pile = Recursif... Désolé c'est la fatigue...
Neotenien
Messages : 354
Inscription : 23 oct. 2020 19:15
Localisation : Le Mans
Contact :

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par Neotenien »

Mon tout premier petit algorithme ugbasic sans avoir recopié quoique ce soit et fonctionnel

PROCEDURE determinant[a,b,c] RETUR ... [-2,5,-1]

Mais ça ne sert à rien vu que pour le moment, ugbasic ne gère aucune fonction avec flottant (pour la racine carrée). Mais ça fonctoinne c'est déjà ça. Je trouve curieux que les paramètres dans les fonctoins soient dans des crochets et pas des parenthèse (ça coupe des habitudes des autres langages).


Sinon il y a cette fonction récursive

Code : Tout sélectionner

PROCEDURE factoriel[i]
IF i>1 THEN
    RETURN factoriel[i-1]*i
ELSE
    RETURN 1
END PROC
PRINT "Factoriel de 10", factoriel[10]
Mais globalement, les fonctions récursives ne sont à utiliser quand tous les éléments sont indépendant (forment une base en algèbre) les uns envers les autres (cas des labyrinthes, de la fonction de découverte du démineur etc), puisque souvent, dans des séries, style Somme des n premiers termes, ça peut se faire même en O(1) (c'est à dire sans boucle). Donc avant de choisir entre récursif ou itératif, se poser la question si les éléments sont indépendant les uns des autres ou pas.

La page que Samuel m'a indiqué sur le passage de récursif à itératif contient une démonstration qui date de 1998, hors il se trouve que les trucs que j'ai appris sur les fonction récursives en Pascal datent de 1992... A cette époque là on n'avat pas fait ces découvertes là.

Pour en revenir au Pascal, de très nombreux logiciels ont été écrit en Delphi pour Windows entre 1995 et 2005. Je crois que la non popularité de ce langage venait du fait qu'il étrait payant et surtout sur PC (et pas pour le projet GNU, dont les outils étaient gratuits).

Prochain petit projet en ug basic, ça sera une animation dotée de gravité (LOL) et que j'enverrai à Marco.
spotlessmind1975
Messages : 66
Inscription : 24 oct. 2021 15:47

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par spotlessmind1975 »

Neotenien a écrit : 18 juil. 2022 15:54 Lisez cet article qui vous contredit en ce qu concerne les performances.
Laissez-moi comprendre : proposez-vous les temps d'exécution de Python pour prouver que le récursif est plus efficace que l'itératif ? Je ne pense pas que vous preniez cela au sérieux comme exemple, car cela signifie que je n'ai pas été en mesure d'expliquer le problème.
Neotenien a écrit : 18 juil. 2022 15:54Et vous n'avez pas pris le soin de me lire sur les algorithme de tris quick sort, de résolution de labyrinthe, ou même la fonction "remplissage couleur" des logiciels de retouche photo, les algorithme ne peuvent qu'utilser que le récursif.
Ce n'est pas que je ne me sois pas intéressé à vos exemples pourtant très intéressants : plus simplement, je sais (au sens de savoir, pas au sens de croire) qu'il y a une interchangeabilité parfaite entre l'un et l'autre. Un algorithme de tri rapide itératif n'a rien à envier à un récursif, sinon l'élégance. Cependant, si vous êtes un bon programmeur qui connaît la machine, vous pourrez peut-être optimiser plus facilement un algorithme itératif qu'un récursif. La raison? Vous ne dépendez pas de la façon dont le compilateur gère la pile.
Neotenien a écrit : 18 juil. 2022 15:54Et pour ce qui est des performance, c'est plus rapide d'utiliser des piles (pour le récursif) que des variables tableaux (ça prend moins de cycle d'horloge).. enfin tout dépend si le processeur prend en charge les instruction de pile (comme c'est le cas du 6809 et sans doutes des proicesseurs 16 ou 32 bits).
Il y a plus de vingt ans, j'ai écrit un algorithme (en C) qui explorait un arbre de décision déséquilibré avec des récursions, composé d'environ seize millions de nœuds. La première implémentation était récursive, car elle était plus facile à écrire et les performances étaient intéressantes mais pas impressionnantes - surtout, elles ne respectaient pas certains délais critiques. Ensuite, je l'ai converti en itératif, et les performances étaient plus ou moins les mêmes. Ensuite, j'ai réalisé qu'il y avait un modèle dans l'accès à la mémoire que je pouvais exploiter, pour éviter de calculer certains décalages en mémoire à chaque fois. Les performances ont été dix fois meilleures et, surtout, elles ont été dans les temps. Et parlons des processeurs 32 bits !
Neotenien a écrit : 18 juil. 2022 15:54La réponse n'est pas en rapport avec ce que j'ai écrit mais passons...
Je crains que ce soit le problème principal, mais je crains que ce soit plus ma limitation dans l'exposition que la vôtre dans la compréhension. Je vais donc essayer de le dire avec des mots différents, en espérant que le traducteur pourra me suivre.

Le point que j'essaie de faire valoir, c'est qu'il y a une grande différence entre les langues et techniques modernes et les langues et techniques de l'époque. Si on utilise des techniques modernes avec les ordinateurs de l'époque, on se trompe, et on se trompe si on construit un compilateur qui fonctionnerait bien avec les processeurs modernes.
Neotenien a écrit : 18 juil. 2022 15:54Evidemment que j'ai étudié l'itératif et le récursif mais visiblement vous n'avez pas compris l'intérêt de cette programmation et avez décidé de l'occulter...
Quelle raison dois-je cacher ... quoi?

Ce qui vous manque, c'est que la pile est un concept abstrait, une abstraction en fait. Les langages qui prennent en charge la récursivité garantissent qu'ils utiliseront une pile mais vous ne pouvez pas négocier avec ces compilateurs une contrainte de performances. C'est comme l'exemple que je vous ai écrit tout à l'heure : je ne peux pas "sauter" au milieu d'une récursivité pour pouvoir exploiter ce qui a été précalculé de manière intermédiaire, mais avec l'itératif c'est immédiat.
Neotenien a écrit : 18 juil. 2022 15:54Eh bien je vous met au défi d'écrire ce code en Itératif (et sans Pile donc!). Il est impossible d'écrire un tel algorithme sans piles (sans sauver les états intermédiaires) hors les piles sont justement sur quoi sont basées les fonction récursives. Si dans votre code, vous utilisez des "piles" ça utilise le même principe de codage que les fonctions récursive mais en bcp plus difficile à écrire!.
Ce sera également plus difficile à écrire, mais si j'ai un moyen "intelligent" d'accéder aux données, meilleur que l'accès séquentiel ou segmenté comme l'empilement, je peux optimiser de manière à ce que la récursivité soit même impossible à imaginer.
Neotenien a écrit : 18 juil. 2022 15:54Là ça rejoint les questionnements de Daniel... C'est comme si vous essayez de travailler sur 10 chantier en même temps en appliquant les mêmes normes partout.. Hors c'est pas toujoursn possible parce que chaque terrain est différent. Mais je persiste dans mon raisonnement! Quand vous avez créé et validé une fonction Basic pour une machine, chacun des comuilateur devrait l'adopter pour chaque machine...
Au lieu de cela, à mon avis, au moins dans ce cas, vous vous rapprochez vraiment d'une compréhension, et je suis donc heureux d'avoir pu bien m'expliquer. Le fait de pouvoir créer et valider une fonction BASIC sur une machine n'implique pas qu'elle puisse être portée sur tout le monde, ni une obligation. L'obligation impliquerait une abstraction. Le porter à tous impliquerait qu'il est meilleur pour certains et pire pour d'autres. Malheureusement il n'est pas toujours possible d'adapter le langage mais les différences sont peu nombreuses par rapport aux similitudes. Les concepteurs de matériel de ces années avaient tous le même parcours, de sorte que les solutions identifiées partagent bon nombre des mêmes idées.
Neotenien a écrit : 18 juil. 2022 15:54D'ailleurs vous l'avez partiellement fait entre les MO5 (pas de gate array) et les MO5 (avec Gate Array, donc si vous avez pu le faire pour les architectures matérielles différentes, vous pouvez le faire pour les ROM non ?
Je dirais non. Les ROM ne sont pas du matériel, ce sont des logiciels, et les logiciels comportent beaucoup plus de choses qu'il n'y paraît à première vue. L'un d'entre eux : la façon dont ils utilisent la mémoire. Et puis, la nécessité pour le matériel d'être utilisé d'une manière plutôt que d'une autre. Les ROM sont des chaînes, pas des ailes.
Neotenien a écrit : 18 juil. 2022 15:54Pour la nème fois, je le répère, c'est simplement pour économiser de la RAM! Quand vous réécrivez (à l'identique) des fonctions existant en ROM dans la RAM en assembleur c'est de la place en moins pour le logiciel lui même. Et quand j'ai soumis le petit algorithme pour les animations de Ken et Blanka et quen ça a été confronté à ce probème de RAM (et qu'il fallait déjà utiliser d'autre bank)... Vous dites que les 8 bits sont limités en RAM mais si vous la gaspiller à réécrire des procédure existante dans la ROM. L'écriture complète des caractères et des fonction en mode bm16 est parfaitement justufiée, mais dans les autres modes ? Oui c'est complexe à écrire mais on n'a jamais dit que l'informatque était simple.
Le "petit" problème de Ken et Blanka n'a rien à voir avec le fait de ne pas utiliser de ROM, également parce que vous ne pouvez pas dessiner ces personnages dans BM16 avec des ROM. Alors, qu'il les supporte ou pas, ça change très peu.

L'utilisation des ROM est une économie qui a un coût, un coût très élevé : c'est ce qu'on appelle "l'addiction". Aujourd'hui est utile, demain est un obstacle et personne ne connaît demain.

À l'inverse, lorsque vous maîtrisez parfaitement vos dépendances, vous êtes en mesure de réaliser d'énormes économies. Prenez, par exemple, ces instructions que je vous ai suggérées à propos de ugBASIC, celles DEFINE SCREEN MODE UNIQUE, etc. Chacune de ces instructions donne au compilateur un indice sur ce qui peut être supprimé du code compilé. Littéralement. Cela permet d'économiser plusieurs kilo-octets et vous n'avez rien à faire avec votre code. Sans oublier que si vous n'écrivez rien, aucun caractère n'est redéfini.
Neotenien a écrit : 18 juil. 2022 15:54Et pour ce qui est de l'abstraction, on a smeble-t-il pas la même définition de ce c'est, du moins en POO
La définition de l'abstraction, dans un sens général, est étrangère à la programmation orientée objet. L'abstraction est la solution que l'informatique a toujours introduite pour niveler les différences. Pascal introduit une abstraction lorsqu'il affirme qu'une fonction accepte des paramètres. Pouquoi? Car pour le CPU, il n'y a pas de notion de "paramètre", encore moins des notions telles que "visibilité variable". Si vous me parlez de Microsoft BASIC alors je peux répondre que oui, Bill Gates a eu une intuition juste : rendre le matériel fongible en partageant le même langage, à l'exception de petites variantes liées au matériel, comme des instructions spécifiques pour chaque architecture. Le principe est similaire à ugBASIC, à la différence que Microsoft BASIC est un interpréteur et présente donc des avantages en souplesse et des inconvénients en rapidité d'exécution. C'est pourquoi Microsoft BASIC prend en charge la virgule flottante.
Neotenien a écrit : 18 juil. 2022 15:54J'ai suffisamment d'expérience en C pour en connaitre les problématique et limites (j'ai commencé dans les années 90 et j'utilise des langages de types PHP qui ont la mêmes syntaxe que le C mais sans les inconvénients de RAM)... Vous pouvez considérer que j'ai au moins 5 ans d'expérience en C (dans l'étude). Et le C est très limité quant aux possibilité des librairies comparé au Pascal (il n'y a PAS d'équivalent, de bases, aux Unités Graph et CRT par exemple). Eh non il n'y a PAS de base les problèmes de gestion de RAM en Pascal. Les poinyeur en Pascal ont été intriduit tardivement et l'Objet également, mais peut de développeur Delphi utilisent les Objet et de nos jours, les ingénieurs commence enfin à comprendre que le concept objet est un énorme problème à plein de pont de vue! Et que finalement ça a couté des milliard d'euros à des enytreprises d'avoir opté pour cette tecno pour des résultats bien en dessous des attentes comparé à l'ippératif (alors que quand j'ai appris l'objet au début des années 2000 je n'y voyais pas di'ntérêt comparé justement aux pointeurs des langages C et Pascal (pointeurs de variables et de fonctions), c'était exactement la même chose. Les poinyteurs sont un énorme problème dans ces langage s'il n'y a pas de système de gestion de RAM... Le Pascal a un système de ramasse miette (que ça soit pour les pointeurs que pour les objets) qui n'existe pas en C.
Je respecte votre expérience, mais d'après la façon dont vous écrivez, cela ne semble pas être le cas. Définir le C limité comme des bibliothèques versus Pascal me rappelle la célèbre blague anglaise selon laquelle s'il y a du brouillard sur la Manche, l'Europe est isolée.

Si telles sont les prémisses, je ne suis pas surpris par votre jugement sur la programmation orientée objet, ou votre réduction à des pointeurs et des fonctions, mais au moins dans ce cas vous avez un facteur atténuant : la programmation orientée objet a été mal comprise par le vaste majorité de ceux qui l'ont adopté. S'il est bien utilisé (et moi, modestement, donc je l'ai utilisé), il réduit de moitié (et plus) l'effort de programmation de comportements complexes, et il est intéressant de constater que l'on peut (dé)écrire des algorithmes de composition simple de classes. Cependant, pour que cela fonctionne bien, il est nécessaire d'introduire des concepts tels que l'héritage multiple, que seul C++ fait de manière cohérente et complète, et que ni Java ni Delphi ni d'autres langages ne font.

Cela dit, ajouter le concept "d'objet" à un langage ne le rend pas orienté objet. Delphi est comme une de ces voitures gonflées, qui peuvent rouler à 400km/h, et auxquelles on ajoute des ailes dans l'espoir qu'elles puissent voler.
Neotenien a écrit : 18 juil. 2022 15:54Quappelez vous de la fausse 3D ?
Peut-être que nous nous éloignons un peu trop du sujet, mais DOOM utilise un algorithme à deux dimensions.
spotlessmind1975
Messages : 66
Inscription : 24 oct. 2021 15:47

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par spotlessmind1975 »

Neotenien a écrit : 18 juil. 2022 19:55 Prochain petit projet en ug basic, ça sera une animation dotée de gravité (LOL) et que j'enverrai à Marco.
J'ai hâte de la voir! :)
__sam__
Messages : 7923
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par __sam__ »

La page que Samuel m'a indiqué sur le passage de récursif à itératif contient une démonstration qui date de 1998, hors il se trouve que les trucs que j'ai appris sur les fonction récursives en Pascal datent de 1992... A cette époque là on n'avat pas fait ces découvertes là.
Tu plaisantes Bruno ? Ca devient fatiguant. La derecursivisation d’algorithmes a toujours existé. L’informatique ne se limite pas, loin de là, à ce que tu avais vu en cours si bons étaient ils. Ce n’est pas parce-que tu ne connais pas que ca n’existait pas depuis longtemps.

Tu t’es planté sur la récursivité. C’est pas grave. Ca arrive. Il est temps de
1) te documenter un peu plus sur l’algorithmique avant d’affirmer l’impossibilité de résoudre tel ou tel problème comme ci ou comme ca (je recommande la lecture de "the art of computer programming” par Knuth)
2) passer á autre chose. Amuse toi avec ce qui existe au lieu de râler dès qu’un truc n’existe pas ou ne marche pas comme tu crois qu’il le devrait.
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Neotenien
Messages : 354
Inscription : 23 oct. 2020 19:15
Localisation : Le Mans
Contact :

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par Neotenien »

spotlessmind1975 a écrit : 18 juil. 2022 20:46
Neotenien a écrit : 18 juil. 2022 19:55 Prochain petit projet en ug basic, ça sera une animation dotée de gravité (LOL) et que j'enverrai à Marco.
J'ai hâte de la voir! :)
Le mot gravité à toute son importance LOL, et j'espèce que ça va marcher...

Pour en revenir à l'objet, il y a des articles récents qui disent que les entreprises ont perdu des miliard à tout miser sur ce concept

La POO en théorie parait simple à mettre en place mais en vérité, ça ce noie sous des choses abstraite très complexe et on a perdu de vue le coeur de la programmation. De plus la loi de Wirth s'paplique plus que jamais et au détriment de choses fiable... Le fait de penser que les ressources informatique sont ilimitées c'est une énorme erreur! Le site de facebook par exemple, combien de fois je dois éteindre mon ordinateur à chaud parce que la page n'a pas de limite et que la RAM s'épuise vite ? Idem pour IG ou tous les sites et logiciel qui pense qu'il n'y a aucune limite aux ressources informatiques.

Enfin vous dites que seul le C++ permet l'héritage multiple, eh bien je n'ai peut-êre pas votre expérience en C++ etc, mais je sais depuis au moins 20 ans qu'on peut parfaitement faire de la POO avec du C ou le pascal non objet simplement avec les ponteurs (de variables et de fonctions), ce qui est rendu possible également pour le Pascal (qui ont également des pointeurs).

C'est simple, les types structurés permettent d'y ajouter n'importe quel type de variable, (dont des pointeurs) ainsi que des pointeurs de fonctions. Avec les structure en C vous avez donc la possibilité de créer des objets simplement avec des types structurés et comme vous pouvez y mettre que des variables de types pointeurs (propriétés), des fonctons de types pointeurs (méthodes) ou d'autres structures de types pointeurs (héritage ou aggrégation), vous avez là une base de POO. C'est Pascal Barlier, un éminent développeur sur Atari qui a écrit des articles à ce sujet dans ST Mag. Et tout dans le C ou langage Pascal peut être rapporté à de la POO sans l'implantation du mot clé "class" ou "object" (en pascal). Les notions objet tels que : polymorphisme, aggrégation, héritage multiple etc, sont donc parfaitement faisable en C ou en Pascal (et sans doute dans d'autres langages utilisant les "pointeurs"...). Pascal Barlier avait d'ailleurs développé les logiciels d'Oxo système en langage Pure C rien qu'avec ces paradigmes Objets.Et c'était des logiciels innovant à l'époque (et le sont toujours d'ailleurs! "XXL" est un tableur multidimensiionnel qui n''existe nulle part ailleurs à ma connaissance. Mais à choisir entre le langage Pascal ou le C, le Pascal est préférable parce qu'il a un système de ramasse miettes (gestion de la RAM) évitant, les problèmes de RAM qu'on a en C (bien meilleur que les malloc, calloc et free du C parce q'en Pascal on d).

Ce que les objets appelle des "références" c'est tout simplement la même technique que ce qu'on appelle "des pointeurs" en impératif. Dans les 2 cas, la variable est une adresse vers l'emplacement de ladite variable, c'est juste la gestion "plus stricte" dans les classes qui en diffèrent. C'est juste le nom qui change. Essayez en C, créez une structure que de pointeur de variables, de fonctions et de structures... Vous aurez les bases d'une "classe" (méthodes, propriété, ...). La POO est un paradigme, un modèle, une vue en programmation. Et ce qu'on appelle niveau d'abstraction est également un concept en POO correspondant à la hiérarchie des classes d'objets.
__sam__
Messages : 7923
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par __sam__ »

Bien bien... je ne suis absolument pas d’accord, mais jen vais pas entrer dans la discussion car ceci nous éloigne du sujet. Tu nous le montres quand ton mystérieux programme pour ugBasic ?
.oO( tiens donc, il suffit d’avoir des pointeurs sur fonctions pour être objet. C’est mon assembleur qui va être content d’apprendre ça )
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
spotlessmind1975
Messages : 66
Inscription : 24 oct. 2021 15:47

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par spotlessmind1975 »

Je précise que, bien sûr, je ne suis pas du tout d'accord avec ce que tu écris, Neotenien, mais il est aussi vrai que comme l'écrit justement Samuel, tu fais beaucoup de confusion entre différentes choses. Comme je vous l'écrivais, les pertes sont liées à une compréhension superficielle de la POO, la même qui permet de définir des langages sans héritage multiple "aux objets". Personnellement, l'entreprise pour laquelle je travaillais n'a subi aucune perte, bien au contraire. Cependant, ne l'ayant jamais utilisé Neotenien, et encore moins sur de gros projets, je dirais qu'il est inapproprié de porter des jugements.

Fermée cette petite parenthèse et pour rester dans le sujet, je voudrais donner un exemple de la façon dont l'approche ugBASIC est différente des autres langages, en particulier le manque d'abstractions. C'est aussi pour répondre à Samuel sur la question des "banks".

La première implémentation d'ugBASIC n'utilisait que la RAM disponible et adressable par le processeur (généralement 16 bits = 64 Ko) et cela s'applique aussi bien au Commore 64 qu'au MSX ou au Thomson. Justement, à l'époque un développeur m'a demandé comment il serait possible de développer des jeux sur la Thomson qui a beaucoup plus de RAM que ce qui est visible, mais qui n'est accessible qu'en changeant de banque.

À ce stade, j'ai commencé à me demander comment ils avaient résolu ce problème dans les années 1980. Bien sûr, la solution de Thomson était l'une de celles possibles, mais étaient-ils vraiment les seuls à franchir la limite de 64 Ko ? J'ai donc fait une petite recherche. Dans Commodore, par exemple, des mécanismes similaires à ceux de Thomson ont souvent été introduits mais avec des "fenêtres" plus petites. Dans MSX (et similaire), il y a le concept de "MEGAROM" et ainsi de suite.

À ce stade, j'ai élaboré quelques primitives de l'ugBASIC qui pourraient exprimer, sans trop entrer dans les mérites, le potentiel de chaque approche. C'est ce qui en est ressorti. Clairement, chaque compilateur implémente ce concept différemment (ou ne l'implémente pas du tout), mais gérer ces différences de manière « centralisée » dépasse les capacités d'une seule personne. C'est pourquoi les compilateurs sont différents. Par exemple, il me semble que 6 banques de 16 Ko sont disponibles sur le Thomson MO6, clairement elles se réduisent à 4 banques si vous utilisez le double buffering en mode BM16. Si on passe sur le Commodore 64, la base de code du compilateur est complètement différente, et pour cela la notion de banque n'existe même pas. Et c'est là le cœur de l'isomorphisme : il n'y a pas de "contrainte" d'implémentation, seulement des indications que le programmeur peut donner.

Lorsque, par exemple, on m'a fait remarquer à quel point l'espace était gaspillé pour les éléments graphiques ou sonores, j'ai décidé d'introduire la compression des données. Cependant, la compression (ou plutôt la décompression) a besoin d'un espace intermédiaire pour stocker le résultat, afin qu'il soit utilisable. Hé, mais le concept de "fenêtre d'échange" est ce qu'il nous faut ! La fenêtre d'échange est cette zone mémoire qui sert "d'intermédiaire" entre le banc mémoire et la mémoire RAM. Le Thomson MO6 s'est donc trouvé un avantage sur les autres plates-formes, mais du point de vue du langage rien n'a changé, car la compression/décompression est effectuée par chaque compilateur unique, selon les besoins.

J'espère qu'avec cet exemple, j'ai expliqué pourquoi il existe différents compilateurs pour chaque cible, et pourquoi cela n'implique pas l'utilisation de ROM système.
Répondre