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

jasz
Messages : 1313
Inscription : 05 oct. 2016 20:05
Localisation : Quelque part dans le 31

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par jasz »

Le problème avec ces langages c'est que ils vont utiliser des routines système (ou moniteur) qui, elles utilisent beaucoup de TM
Le mieux c'est le pur langage machine. Car peut être pas gain de place mais plutôt de rapidité :wink:
Daniel
Messages : 17316
Inscription : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par Daniel »

Quels sont les langages qui utilisent des routines système ? Ce n'est pas ugBASIC, car il est complètement indépendant de la ROM.
Daniel
L'obstacle augmente mon ardeur.
jasz
Messages : 1313
Inscription : 05 oct. 2016 20:05
Localisation : Quelque part dans le 31

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par jasz »

Daniel a écrit : 20 juil. 2022 22:10 Quels sont les langages qui utilisent des routines système ?
L'assembleur et les compilateurs :roll: Le pur LM c'est à la main sans utiliser les swi ou les jsr système 8)

Le ugBasic est interprété donc...

Comme le GFA basic sur atari et le devpac et ses macros méchantes :evil:
spotlessmind1975
Messages : 66
Inscription : 24 oct. 2021 15:47

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par spotlessmind1975 »

jasz a écrit : 20 juil. 2022 22:32 Le ugBasic est interprété donc...
Peut-être que le traducteur ne traduit pas bien, mais ugBASIC n'est pas réellement interprété : le compilé (le résultat de la compilation) est du langage machine pur et grâce à l'effort de certains développeurs (dont l'excellente contribution de Samuel, qui a écrit un optimiseur vraiment innovant pour le Motorola 6809), il est également optimisé sur certaines machines.
Daniel
Messages : 17316
Inscription : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par Daniel »

jasz a écrit : 20 juil. 2022 22:32 L'assembleur et les compilateurs :roll: Le pur LM c'est à la main sans utiliser les swi ou les jsr système 8)
Il n'y a pas de rapport entre l'assembleur et le moniteur système. C'est le programmeur qui décide s'il appelle ou pas des routines en ROM. Qu'il programme directement en langage machine ou qu'il utilise un assembleur ne change strictement rien.

D'ailleurs les assembleurs 6809 sur PC que nous utilisons ne savent même pas que les ordinateurs Thomson existent. Comment pourraient ils appeler des routines en ROM ? Et c'est pareil pour le compilateur ugBasic : il génère du langage machine qui ne fait aucun accès à la ROM système. Elle est totalement ignorée.

Autre remarque : Pourquoi les routines système des ordinateurs Thomson seraient elles plus mauvaises que du code écrit par un programmeur ? Elles ont été écrites par des ingénieurs Thomson qui n'étaient pas moins bons que nous en programmation. Si on sait ce qu'on fait on peut très bien les utiliser pour diminuer la taille en RAM de nos programmes.
Daniel
L'obstacle augmente mon ardeur.
spotlessmind1975
Messages : 66
Inscription : 24 oct. 2021 15:47

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par spotlessmind1975 »

Daniel a écrit : 21 juil. 2022 08:23 Autre remarque : Pourquoi les routines système des ordinateurs Thomson seraient elles plus mauvaises que du code écrit par un programmeur ? Elles ont été écrites par des ingénieurs Thomson qui n'étaient pas moins bons que nous en programmation. Si on sait ce qu'on fait on peut très bien les utiliser pour diminuer la taille en RAM de nos programmes.
En général vous avez raison, dans le sens où si l'on sait ce qu'il fait, il n'y aurait aucune raison de ne pas les utiliser pour gagner du temps (on ne peut rien dire, en général, sur la qualité du code). Cependant, cette connaissance est souvent "a posteriori", pas a priori, c'est-à-dire qu'on ne sait qu'après implémentation combien cette caractéristique est "clé" pour son application (langage, programme, ...).

Permettez-moi de mieux expliquer avec un exemple.

On m'a conseillé de me tourner vers les routines du système pour écrire sur l'écran. Tous les ordinateurs 8 bits (Commodore, MSX, Dragon, ...) ont de telles routines, donc cela semblerait être une bonne astuce similaire à ce que vous proposez. Sauf que, chaque ordinateur l'implémente différemment et "exposer" cette diversité au niveau d'un langage ne semble pas une bonne idée : imaginez un pauvre programmeur qui doit écrire "BONJOUR" sur un ordinateur et "X2FAUCB" sur un autre, simplement parce que l'encodage ASCII est différent. Pire encore dans le cas Thomson, où les ingénieurs ont "oublié" que leur ordinateur dispose d'un mode spécifique, appelé BM16, pour lequel... ils n'ont rien implémenté !

En adoptant ces routines on obtient donc un avantage mais deux inconvénients :
1) nous créons une dépendance ;
2) nous nous limitons à ce qui était disponible à l'époque.

Ce sont deux limites très strictes.

D'un autre côté, il peut parfois ne pas être judicieux de repartir de zéro. J'utilise moi-même certaines routines de la ROM Thomson pour lire les blocs de la bande. Dans ce cas, la dépendance est masquée (car elle n'est pas visible pour le langage, car effectué au démarrage) et la bande est juste ce qui était là à ce moment-là. Les limites sont donc négligeables par rapport à l'avantage. Sur d'autres ordinateurs où la ROM peut être désactivée pour avoir plus de RAM, cela peut toujours n'avoir aucun sens de créer une dépendance car nous forcerions l'exécutable à avoir une certaine "disposition" en mémoire (limite 1).

Bref, la considération sur la qualité du code est secondaire, même si j'ai tendance à croire que le code moderne est meilleur que celui de l'époque, du fait de la possibilité d'utiliser des outils (tels que des optimiseurs) qui ne peuvent bien fonctionner qu'aujourd'hui, sur des ordinateurs modernes dotés de grandes ressources de mémoire et de calcul.
Daniel
Messages : 17316
Inscription : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par Daniel »

Êntièrement d'accord avec spotlessmind1975. Ma remarque précédente ne concernait pas ugBasic, mais uniquement les développements en assembleur.
Daniel
L'obstacle augmente mon ardeur.
Neotenien
Messages : 354
Inscription : 23 oct. 2020 19:15
Localisation : Le Mans
Contact :

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par Neotenien »

Je pense avoir les compétence suffisante sur l'Objet pour en discuter sans problème... Quand je dis qu'on peut faire de l'Objet avec du C ou du Pacal seul et que vous me dites ne pas être d'accord du tout, je vous ai pourtant dit comment ça se faisait (et je connais quelqu'un qui a procédé ainsi en créant des logiciels sur Atari Falcon). Une classe est coimme un type STRUCT avec des pointeurs de variables et fonction. L'héritage multiple est comme déclarer une structure ayant, dans ses variables, d'autres structure. Le polymorphisme existe déjà en C et Pascal...

Certes en dév JavaScript, tout est objet et la POO là est utile (un exemple est de faire un jeu avec des objets graphique, entre CSS3 et Canvas 2d où on doit tout redessiner à chaque fois, ça apporte un net +) mais c'est pas ce qui est le plus intéressant dans la programmation... La POO est un + haut niveau, on à juste à se concentrer sur les propriété (et certanes fonctions) de l'orjet et pas des aspect technique de ceci qu'on devrait programmer en l'impératif (quoique si on a les librairies existante on n'a pas non plus à s'occuper de ça). Moi ce qui me pose problème sur l'objet, c'st la complexité de certaines démarche, notamment l'instanciation d'un objet, je trouve ça hyper compliqué parfois la pricédure d'instance dans les langage ayant fait une implémentation complète.

Pour ce qui est de la compression pour UG Basic, à la question que je me pose est pour la perte de performance : écriren un algorithme qui dessine des sprites en brut prend moins de temps que passer par une compression ou un compactage quelconque, mais c'est au détriment de la RAM...

Je suis heureux que Daniel se pose les mêmes questions que moi sur la ROM. Je suis partiellement d'accord avec Marco ou Daniel, mais on peut utilser la ROM si l'algorithme écrit pour telle ou telle fonction est la meilleure et validée (exemple : si en ROM il existait une fonction qui calcule la somme les carrés des N premier entier optimisé du type "N×(N+1)×(2N+1)/6" ça ne servirait à rien de l'écrire à noueau en assembleur au risque de gaspiller de la RAM. Pour ce qui est de l'algorithme de RND, Samuel m'a montré qu'il n'était pas optimisé dans l'extramoniteur, ok ça marche.

En fait tout cela me fait penser à des approches de développement de navigateurs web. Pour ce qui est de Firefox/Chromium/Opêra, ça utilise des librairies partagées... Alors qu'un logiciel tel "Vivaldi" utilise ses propres librairies, et on voit ici une totale maitrise du code... Mais bon je pense encore au problème du peu de RAM des ordinateurs 8 BIT et on sait que la RAM c'est précieux... Chaque choix a ses avantages et inconvénients.
spotlessmind1975
Messages : 66
Inscription : 24 oct. 2021 15:47

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par spotlessmind1975 »

Neotenien a écrit : 21 juil. 2022 15:54 Je pense avoir les compétence suffisante sur l'Objet pour en discuter sans problème...
La façon dont vous en parlez, vous le réduisez à une question de "sucre syntaxique". Et c'est normal, car (comme je l'ai déjà écrit) la plupart des gens qui ont des compétences en programmation orientée objet se sont arrêtés à Java ou "[mettez le nom du langage ici] orienté objet". Cependant, je le répète, sans héritage multiple, vous n'avez pas accès à tout un ensemble de potentiels expressifs. C'est comme essayer de décrire les couleurs tout en étant aveugle.
Neotenien a écrit : 21 juil. 2022 15:54 Pour ce qui est de la compression pour UG Basic, à la question que je me pose est pour la perte de performance : écriren un algorithme qui dessine des sprites en brut prend moins de temps que passer par une compression ou un compactage quelconque, mais c'est au détriment de la RAM...
C'est peut-être vrai pour les décompresseurs traditionnels, et il y a quelques jours, j'ai demandé à un groupe de programmeurs quel était l'algorithme de compression le plus efficace pour les processeurs 8 bits. Cependant, à mon avis, MSC1 est un format de compression prometteur car il exploite la localité des données et est très compact (l'ensemble du décompresseur dans ASM 6809 occupe 89 octets). Malheureusement, je n'ai pas les mesures de performances sous la main, également parce qu'elles concernaient l'algorithme écrit en C et non en assembleur. Cependant, si vous vous en souvenez, votre première implémentation d'une animation dans ugBASIC utilisait une seule fenêtre partagée entre les deux sprites. Même si toutes les images étaient décompressées à chaque fois que vous dessiniez une image de l'un des personnages, c'était encore assez rapide pour être utilisable.
Neotenien a écrit : 21 juil. 2022 15:54 si l'algorithme écrit pour telle ou telle fonction est la meilleure et validée
Tout d'abord, il faut prouver que c'est mieux, et souvent cela n'est connu qu'après l'avoir écrit, le code. Cependant, souvent nous n'écrivons pas de code non pas parce que nous savons que ce ne sera pas mieux mais seulement par paresse, car nous savons qu'il "existe déjà". En ce sens, le manque de mémoire peut facilement devenir une excuse, mais comme je l'ai déjà écrit, c'est une excuse coûteuse en tant qu'effet secondaire. On découvre souvent les inconvénients lorsqu'il est trop tard.
Avatar de l’utilisateur
pascalien
Messages : 965
Inscription : 21 janv. 2019 23:40
Localisation : 93200 ST DENIS
Contact :

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par pascalien »

Malgré quelques recherches Google, je n'ai pas réussi à trouver des informations sur cet algorithme MSC1 .
spotlessmind1975
Messages : 66
Inscription : 24 oct. 2021 15:47

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par spotlessmind1975 »

pascalien a écrit : 21 juil. 2022 20:23 Malgré quelques recherches Google, je n'ai pas réussi à trouver des informations sur cet algorithme.
Vous trouverez ici une description de l'algorithme et ici l'implémentation du compresseur / décompresseur en langage C.

Les implémentations (non optimisées) d'un décompresseur pour les différents processeurs 8 bits peuvent être trouvées ici :
:arrow: Morotola 6809
:arrow: MOS 6502
:arrow: Zilog Z80
__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__ »

@Neotenien C’est hors sujet et pollue le sujet ugBasic donc je ne donnerais pas mon avis sur la programmation orienté objet..oO( tu confonds la programmation orientés prototypes (ex: js, lua) et les la programmation orientés objets (ex: c++, smalltalk) ) Ouvres un sujet dédié si tu le souhaites.

Pour la perte de performance, nous verrons bien. Seule l’expérimentation est juge de paix.

La ROM est généraliste et donc pas optimale du tout pour les primitives qui devraient être très rapide. A ton avis, pourquoi aucun starfield thomson n’appelle la routine plot du moniteur ou de l’extramon ? Elle sont trop lentes ! Elles doivent tester et gérer entre autre le statut attr pour savoir si l’écran est en mode forme seule, gérer aussi le cas des couleurs négatives, le mode xor de dessin pour l’extramon, voire le plot en mode caractères. Certaines fonctions de la rom sont en outre trop grosses et font de la commutation de rom en cours de route (à partir du to9, le moniteur est sur plusieurs bank rom), bref plein de trucs dont on a pas besoin pour faire une demo ou un décor de jeu qui ne ramme pas (penser aux étoiles dans Choplifter: pas via la rom). Par contre si tu fais un logiciel de compta bien pépère, oui tu peux passer par la rom. Tout dépend des cas d’usage. UgBasic est conçu, dès le départ comme Amos ou Stos pour faire des jeux, pas de la compta.

@Marco tu peux améliorer le code 6809 du décompresseur en retirant les cmpb#0 suivant une operation ALU (arithmétique ou logique bit á bit) ou load/store car sur 6809 ces opérations positionnent les flags dont N (résultat négatif) et Z (résultat nul). Tu peux aussi utiliser le mode indexé ”,X++" plutôt qu’avoir un LEAX 2,X juste après.

Le compresseur le plus performant du moment sur 8 bits est, à ma connaissance, Zx0: https://github.com/einar-saukas/ZX0
La version 6809 est là https://github.com/dougmasten/zx0-6x09
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
hlide
Messages : 3469
Inscription : 29 nov. 2017 10:23

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par hlide »

__sam__ a écrit : 21 juil. 2022 21:56 Le compresseur le plus performant du moment sur 8 bits est, à ma connaissance, Zx0: https://github.com/einar-saukas/ZX0
C'est effectivement celui que j'utilise : il est simple et reste très efficace par rapport à mes besoins. Pour un écran de texte et couleurs, je passe quasiment de 1 Ko à 100 o. Du coup, j'utilise ce décompresseur pour afficher directement un écran.
spotlessmind1975
Messages : 66
Inscription : 24 oct. 2021 15:47

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par spotlessmind1975 »

Bonjour Samuel !
__sam__ a écrit : 21 juil. 2022 21:56 @Marco tu peux améliorer le code 6809 du décompresseur en retirant les cmpb#0 suivant une operation ALU (arithmétique ou logique bit á bit) ou load/store car sur 6809 ces opérations positionnent les flags dont N (résultat négatif) et Z (résultat nul). Tu peux aussi utiliser le mode indexé ”,X++" plutôt qu’avoir un LEAX 2,X juste après.
En attendant, merci pour les excellentes suggestions, vous êtes toujours très gentil. Je confirme que certaines de vos suggestions sont déjà reçues par l'optimiseur, qui entre également en fonction pour optimiser les codes d'assemblage des bibliothèques - donc les 89 octets ne contiennent pas le contrôle s'il est nul [CMP #$0]). Après avoir introduit votre optimisation supplémentaire (X++), je suis tombé à 84 octets. Ouah!

J'ajoute, pour les non-initiés, que ugBASIC possède un excellent optimiseur de code pour les processeurs Morotola 6809 écrit par Samuel. Ainsi lorsque vous compilez un code pour Thomson MO5, Olivetti Prodest PC128 et Dragon 32/64, sachez que si le code est particulièrement rapide et efficace c'est grâce à cet optimiseur, pas au mien.
__sam__ a écrit : 21 juil. 2022 21:56 Le compresseur le plus performant du moment sur 8 bits est, à ma connaissance, Zx0: https://github.com/einar-saukas/ZX0
La version 6809 est là https://github.com/dougmasten/zx0-6x09
Tout d'abord merci beaucoup pour l'astuce ! C'est vraiment intéressant comme algorithme, en fait je trouve beaucoup de similitudes avec le MSC1.

Lors de l'examen préliminaire, je vois deux différences dans le niveau de sortie de compression. Le premier est dans le format : MSC1 n'utilise que deux éléments de codage (littéral ou doublon), distingués par un bit mais librement utilisables tandis que ZX0 en utilise trois (littéraux, doublons et doublons sans décalage), mais avec des contraintes (ils ne peuvent pas être utilisés tous, dans n'importe cet ordre). La seconde est que ZX0 utilise le "encodage Elias" pour représenter une partie de l'offset et la longueur des littéraux, tandis que MSC1 utilise la valeur réelle (donc limitée à une "plage" de 1Ko / 32 répétitions / 127 littéraux, pour l'emplacement des données) et une longueur fixe de répétitions de 4 octets. Pour ceux qui se demandent pourquoi il y a des limitations aussi strictes, je réponds que le compresseur a été créé pour compresser les images des films rendus avec des caractères PETSCII.

Image
J'ai essayé d'essayer de compresser la version TMS9918 (compresseur MSC1 pour Z80) d'une image spécifique d'un petit tigre (taille source : 4099 octets) et avec MSC1 j'obtiens 2671 octets alors qu'avec ZX0 j'obtiens 1135 octets. Donc, cela économise définitivement de la mémoire.

Cependant, au niveau du décompresseur, la version plus rapide du ZX0 (car je suppose qu'il est optimisé) pour Z80 occupe 673 octets alors que la version plus lente ne fait que 68 octets (mais elle est même 30% plus lente !). La seule version non optimisée pour Z80 du décompresseur MSC1 occupe 92 octets.

Image

C'est le graphique trouvé sur le site, avec la vitesse officielle de ZX0. Je ne sais pas si cela fait référence à la version 8 bits (je ne pense pas), cependant il serait intéressant de comparer la vitesse de décompression sur les machines 8 bits car je crains que l'encodage Elias ne soit un vrai "goulot d'étranglement" . Pour expliquer pourquoi il suffit de considérer qu'il s'agit d'un type de code "orienté bit", donc il faut "compter les bits" pour "reconstruire" la valeur plus tard. . Dans le diagramme, j'ai dessiné la zone dans laquelle MSC1 est le plus susceptible d'être placé. Une mise en garde : elle est purement théorique (après tout, la gamme de résultats est vraiment large !), elle ne repose pas sur des données complètes et comparables. En une demi-heure je n'ai pas pu faire de benchmark ! :D
jasz
Messages : 1313
Inscription : 05 oct. 2016 20:05
Localisation : Quelque part dans le 31

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par jasz »

Daniel a écrit : 21 juil. 2022 08:23 Et c'est pareil pour le compilateur ugBasic : il génère du langage machine qui ne fait aucun accès à la ROM système. Elle est totalement ignorée.
Je me fourvoie peut-être :roll:
J'aie cependant une petite question. Comment interprète t-il un simple print"bonjour"? Comme tous les interpréteurs de langage genre je stocke la chaine de caractère "bonjour" quelque part en ram, je pointe dessus et je fais appel à une routine système pour l'afficher? Ou va-t'il construire une routine, plus longue, pour afficher ce pauvre "bonjour"?
Répondre