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 »

pascalien a écrit : 16 juil. 2022 22:54 La Z-machine d'infocom c'est 1979.
https://fr.wikipedia.org/wiki/Z-machine

Le p-code du pascal c'est entre 1971 et 1973.
Merci pour l'info!! Et ça recadre...

Je savais que l'UCSD Pascal de 1977 (18 ans avant le Java!!) utrilisait le p-code, mais je pensais que c'était le premier à l'avoir utilisé... mais apparemment non, du couop, le p-code a été créé 22 ans avant le byte code Java... MDR et dire que tout le monde fantasme sur Java... Ils doivent boire trop de café.

Ya eu un UCSD Pascal sur les Thomson (vers 1986-1987) même des articles dans des journaux Thomson (mais manquant cruellement de précision)
spotlessmind1975
Messages : 66
Inscription : 24 oct. 2021 15:47

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par spotlessmind1975 »

Neotenien a écrit : 16 juil. 2022 18:21 Sorry but I don't know how to compile, and as I use Linux and use Wine... I'll wait for the next version if ugbasic so (until that I'll have time to end my personnal game).
If you use Linux it should be very easy to compile ugBASIC: there is a guide here and some other suggestions here. Feel free to ask me if you need any help, or ask in the group.
Neotenien a écrit : 16 juil. 2022 18:21there is no mathematical function (about trigonometry), and even no floating var...
The functionalities are independent. Floating point numbers are one thing and trigonometric functions are one thing.

Keep in mind that, as Samuel writes well, floating point numbers were introduced late on 8-bit computers, while fixed-point numbers are much faster and more manageable. I don't know if floating point number support will be implemented, because not all processors lend themselves well to this type of computation. On the other hand, fixed point numbers are much better, from all points of life, and it is not excluded that they will be implemented.

Regarding the trigonometric functions, their punctual calculation requires a computational capacity that is not very compatible with the speeds of the processors. Most applications that need trigonometric functions and have to implement them by themselves, do not calculate their value "on the fly" but, starting from pre-calculated tables, calculate the required value by means of interpolations.

The latter will be, I think, the best approach for ugBASIC.

So, yes, in the future they will be implemented but not the way you think: calculating SIN (3.00) will be transformed into a lookup on a table with maybe 16 pre-calculated values ​​for the SIN (maybe the two values ​​of SIN (2.74) and SIN ( 3.14) and then interpolated, which means that the trigonometric functions will occupy space and will be approximated.
Dernière modification par spotlessmind1975 le 17 juil. 2022 15:31, modifié 2 fois.
spotlessmind1975
Messages : 66
Inscription : 24 oct. 2021 15:47

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par spotlessmind1975 »

Neotenien a écrit : 17 juil. 2022 14:37 Et je persiste à dire que le langage Pascal reste le meilleur des langages de hauts niveaux à TOUT point de vie (comparé au C, ou à Java), notamment du fait que ce n'est pas un langage permissif (et donc évite des bugs tou en ayant des compilateurs très performants
Personnellement, je ne sais pas si Pascal est le meilleur langage de programmation. Ce que je peux dire en revanche, c'est que c'est depuis la fin des années 90 que la vérification de la syntaxe n'est plus considérée comme une "garantie" de l'absence de bugs. Le code que vous compilez compile, mais il n'est pas forcément exempt de bugs. La seule façon de s'assurer qu'il n'y a pas de bugs est de tester le code compilé.
Neotenien a écrit : 17 juil. 2022 14:37Dans une étude de 2019 , Le langage Pascal est classé parmi les 3 langages les plus performants,
Dans ce cas également, je ne veux pas déséquilibrer, mais je pense que ce classement se réfère aux ordinateurs modernes.

Par exemple, Pascal (comme tous les langages) utilise la pile ("stack") comme primitive. Étant donné que les processeurs 8 bits ont une pile native ("CPU stack") ridicule, le code émis par les compilateurs Pascal contient généralement une sorte "d'abstraction" de la pile (stack). Cela introduit une pessimisation notable.

ugBASIC n'utilise pas de piles et est donc structurellement plus rapide.
Neotenien a écrit : 17 juil. 2022 14:37Par exemple, avoir choisi d'avoir 2 noms pour une même fonction ne fait qu'embrouiller!!
Quel est le problème exactement?
Neotenien a écrit : 17 juil. 2022 14:37la déclaration "GLOBAL" qui a un autre mot synoyme
Il ne me semble pas qu'il ait un synonyme, mais il a une commande complémentaire. Vous pouvez utiliser GLOBAL au niveau du programme principal et SHARED au niveau de la procédure.
Neotenien
Messages : 354
Inscription : 23 oct. 2020 19:15
Localisation : Le Mans
Contact :

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par Neotenien »

Réponse à Samuel (à propos des nombres à virgules)

Je connais très bien le codage IEEE754 ça a été un des premiers cours que j'ai eu au CNAM en langage Pascal (et ça m'est resté en mémoire), le fait d'utiliser le premier (ou 2 premiers) octets en temps qu'exposant et que les autres octets servent de mantisse ne me paraissent guère différent en terme de performance que la techno à virgule flottante. Quand on fait des divisions ou multiplicatoin, et qu'il y a des retenus, ya juste qu'à décaler à gauche ou à droite l'exposant, et on peut faire des algorithme facilementr (voici par exemple, un algo que j'ai pondu pour Pure Pascal sur Atari Falcon pour compléter les fonction de ce compilo par rapport à Delphi : Frexp)

D'ailleurs j'invite les forumeurs à voir cette page où j'ai créé plus de 25 fonctions mathématiques avancées à partir des fonctions de bases de Pure Pascal. Ca pourra même servir à Marco éventuellement.

Par contre, c'est vrai que je ne sais pas comment donner des fonctions tels sin, cos, racine carrée, ln en algorithmique, ni même le tracé de cerle, mais fort heureusement, les moteurs de recherches sont là pour nous aider et pour le cercle, il y a l'algorithme d'Andres (qui ne fai( pas de trou). Est ce cet algorithme que Marco a utilisé dans les compilateurs d'Ug Basic ? C'est intéressant internet comment on apprend des trucs! Je pense qu'on peut avoir les mêmes genre d'articles pour les sin, cos, racine carrée et ln. Donc en vérité, c'est pas le problème des codages IEEE754 et vircule fixe qui posent problème, mais plutôt les fonctions utilisant des réelles (comme on le voit pour la trigonométrie, soit ça utilise des tableaux de valeurs soit la méthode CORDIC)

Pour les algo de sin/cos, finalement, la méthode la plus simple est d'utiliser des valeurs pour un octant (1/8 de cercle) comme expliqué ici : https://fr.wikipedia.org/wiki/Sinus_(ma ... C3%A9rique. On peut utiliser pour une étendue de Pi/4 ou 45°, 256 valeurs à la rigueur (ou même 180) ce qui donnera une précision de l'ordre de 0.25 degré ou Pi/1000. Si on a les valeurs pour sin on peut extrapoler pour cos, et tan... et ainsi de suite. D'ailleurs j'ai chez moi un vieux carton imprimé où sont inscrit ces valeurs là (si je parviens à remettre la main dessus ?).

J'habite le Mans et je peux dire que, les MMA (la compagnie d'assurance, pas le sport de combat en arène MDR), qui sont au Mans, utilisent SMalltalk depuis les origines (1969) et c'est un langage qui apparemment est très fermé... Mais depuis quelques années, je crois qu'ils se sont décidé à passer à un autre langage (Java je crois ?) quoiqu'il en soit si vous connaisse des spécialistes en Smalltalk (il ne doit pas y en avoir bcp) sachez qu'ils en recherchent... Juste au moins pour la migration vers un meilleur langage.
Neotenien
Messages : 354
Inscription : 23 oct. 2020 19:15
Localisation : Le Mans
Contact :

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par Neotenien »

Marco:

About trigonometric function I already answered about that indicating that it can only be manage by a value array of octant (45° wide) so that you can use a 256 (or 128, it could be suffisiant) bytes (or word) array of sinus value, from 0 to 45°, as an octant. And as it can be reproduce for 7 other octants, and also for cos, it's ok.... Oh I just see that you answer exactly the same... So yes this is the best way. And using 128 value of word doesn't not take many place (whatever the nuùber format, fixed point, IEE754 or just a mantisse with a predefined power of 10)

I agree about the fact that flotting point and trigo functions are 2 differents ways. And really the IEE754 norms is not so slower than fixed point to managed. And in both case we have the limitation of precision due to the limited byte (for instance, doing 124000+0.0002 may not give the true result!). Thomson computer (and PC128) have a extramoniteur that can manages IEEE754 foating point number and having many maths function as Ln, Cos, Sin and Exp. As all other function are from this basic ones... I think to create a tetraedron to rotate (with lines) on ug basic, we neeed these features, what do you think about that ? Ug Basic manage 4 bytes long, so managing IEEE754 with a byte for exponant and 3 for mantissa may not be a problem. At worse, we can use 4 bits for exponent and 12 for mantissa (for 2 bytes) we could have here some flotting until +8.nnnnn and -8.nnnn (including sign)

About Pascal, it's many easyer not to have bug coz there is a really true control of RAM space, about each variable... Whereas you have to do it in your coe in C... And as I told before it exist many Pascal compilers on 8 bits computers (6 on C64!) and some produced a very fast code (on Atari XL for instance). Alm not sure that PAscal use always stack... Only in case of recursive fonction, and maybe for have a good management of array var, but for other var (real, integer, ...) clearly NO. Pascal compiler are the faster in the world and code produced is more stable than the one of C. Even if Pascal introfduce Var pointer (and then Object) at end on 1980 yers, but here, it exist a principle of "ramasse miettte" saying that it same as in Java finally.

Am not agree about using 2 words as SHARED and GLOBAL for doing the same thing, you don'tnapply here the "ORTHOGONALITY" principle in programmation : saying, using a same word for same fonction, independant about variable kind or environment. It's not advice to use different different name for function doing exactly the same.
Problem is that :
- confusing for coders
- reduice the potential name of user variable or functions
- not have a polymorphism paradigm.
__sam__
Messages : 7909
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par __sam__ »

On s’eloigne de ugBasic sur Olivetti Pc128, mais bon....

Les flottants sont totalement inefficaces et inutiles pour faire des trucs rapides sans support hardware. Les calculs avec eux est de plusieurs ordres de grandeurs au dessus des virgules fixes. Au moins 10 à 50 fois plus lents en flottants. Ya pas photo.

Fais le test indiqué plus haut avec Mandelbrot au lieu de te baser sur des impressions. Sinon tu peux lire (et faire confiance) cette these de 1983 qui parle de 0.5ms par addition/soustraction et 1ms pour les multiplications et 2ms pour les divisions en moyenne sur 6809. C’est d’une lenteur, et pourtant ils considèrent leur code optimisé comme super efficace !

Pour le calcul du sin/cos avec des tables de 256 entrées (soit déjà 1ko de ram) donnant un sinus precis à seulement 1e-3 près sont loin d’être suffisantes. Les floats sont conçus pour être precis. On fait du calcul scientifique avec. Un float 32bits attends 1 000 à 10 000 fois plus de précisions (1e-7) et beaucoup, beaucoup plus avec les flottants 64bits. On utilise d’autres techniques (approximants de Padé, algorithm de Remez, etc). On en a déjà parlé, crois que je radote.

Quant à Pascal, on sais que tu l’aimes bien. Mais il faut se rendre à l’évidence: il n’a pas percé ni apporté tant d’innovations reprises partout ailleurs. Il fait maintenant parti de l’histoire passée, pas présente. C’est triste, mais c’est ainsi. Les langages deviennent obsolètes. Le p-code ucsd n’a pas non plus donné naissance au bytecode java. Ils ont juste d’être en commun des bytecodes pour machine virtuelles. Je ne sais pas pourquoi tu relies toujours les deux. De nos jours on retrouve du bytecode pour machine virtuelle partout et dans des trucs plus à la mode que java: python, llvm, dot.net, etc. Le p-code ucsd n’était pas non plus la première utilisation d’un bytecode. Le BCPL de 1966 en utilisait déjà un. Le seul truc sympa du p-code Ucsd est le fait qu’il tournait partout pareil via l’UCSD p-system, un os complet qui abstrayait complètement la machine sur laquelle il était installé. Paradoxalement, c’est justement le truc que tu reproches à ce Pascal sur thomson. :|

Enfin ne parles pas de l’extramon avec ugBasic, c’est hors-sujet. On le trouve où l’extramon sur MO5, Coco ou C64 ? UgBasic est multi-machines ! Tu n’as pas besoin de l’extramonitor pour faire tourner des polyèdres en 3d. Example, sur un minitel: https://youtu.be/a2HD6OzNoEo?start=146
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
fneck
Site Admin
Messages : 17389
Inscription : 01 avr. 2007 12:03
Localisation : Drôme Provençale (26)
Contact :

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par fneck »

Moi je me pose une question, depuis un petit moment d'ailleurs, le sujet est-il encore bien dans la catégorie "Hardware 8-bits" ou devrait il plutôt être dans "Développements actuels" ?

[edit 18/07/2022] topic déplacé [/edit]
Fabien https://www.system-cfg.com
Les bonnes pratiques de l'utilisateur du forum viewtopic.php?f=14&t=3
__sam__
Messages : 7909
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par __sam__ »

"Développements actuels" me semble plus approprié. 8)
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 »

__sam__ a écrit : 17 juil. 2022 20:41 "Développements actuels" me semble plus approprié. 8)
Je suis d'accord aussi, d'ailleurs je m'excuse de ne pas avoir vu plus tôt qu'il y avait une zone plus adaptée. :)
spotlessmind1975
Messages : 66
Inscription : 24 oct. 2021 15:47

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par spotlessmind1975 »

Hello Neotenien!
Neotenien a écrit : 17 juil. 2022 16:32And really the IEE754 norms is not so slower than fixed point to managed.
I'm sorry but I totally agree with Samuel's analysis.
Neotenien a écrit : 17 juil. 2022 16:32I think to create a tetraedron to rotate (with lines) on ug basic, we neeed these features, what do you think about that ?
I think you are overestimating the computing capabilities of an (any) 8-bit computer. Truthfully, any kind of 8-bit 3D attempt falls into two categories: it's a "fake 3D" or it's pre-computed. In neither case is it necessary to have neither trigonometric functions nor floating point numbers (in fact you don't even need fixed point numbers).
Neotenien a écrit : 17 juil. 2022 16:32Ug Basic manage 4 bytes long, so managing IEEE754 with a byte for exponant and 3 for mantissa may not be a problem. At worse, we can use 4 bits for exponent and 12 for mantissa (for 2 bytes) we could have here some flotting until +8.nnnnn and -8.nnnn (including sign)
In principle it would not be impossible... but you're overlooking the small problem that no routine can use floating point numbers directly, and converting to integers comes at a cost, especially if repeated. It's one of the problems I've run into with ugBASIC with integer types, let alone with these new types!
Neotenien a écrit : 17 juil. 2022 16:32And as I told before it exist many Pascal compilers on 8 bits computers (6 on C64!) and some produced a very fast code (on Atari XL for instance).
Making comparisons is not easy, but I suspect that the code generated by ugBASIC is faster, especially in presence of procedures.
Neotenien a écrit : 17 juil. 2022 16:32Alm not sure that PAscal use always stack... Only in case of recursive fonction, and maybe for have a good management of array var, but for other var (real, integer, ...) clearly NO.
In general, whenever you define a local variable in a procedure, you necessarily use the stack. Whenever you pass more parameters than the number of CPU registers, you are forced to use the stack. When you have two codes running at the same time (multitasking), you use a portion of the stack for each. The problem is that the stack, on 8-bit computers, was not born to do these things and therefore the Pascal compiler will dedicate an area of memory for stack use. But this memory area is not as efficient as the CPU stack. This is true for Pascal as well as for C, of course.

Conversely, ugBASIC is stackless. When you define a local variable in a procedure, it occupies a specific location in RAM. If you pass a parameter, you pass it by exploiting an area of RAM. The return value the same. You never use the stack to pass these things, and RAM is STATICALLY defined. There are no calculations to be done, there is no stack to manage. It is all immediate and converted in immediate asm instructions. Very fast! Another advantage is that there is a clear separation between code and data, and this allows you to natively implement multitasking, which Pascal does not have on 16-bit or 32-bit processor, as well.
Neotenien a écrit : 17 juil. 2022 16:32Am not agree about using 2 words as SHARED and GLOBAL for doing the same thing, you don'tnapply here the "ORTHOGONALITY" principle in programmation : saying, using a same word for same fonction, independant about variable kind or environment. It's not advice to use different different name for function doing exactly the same.
I don't think syntax can compromise the orthogonality of a language, but I understand that in Pascal there is indeed a risk. In other less formalized languages (such as BASIC), orthogonality derives from the guarantee that commands and functions do not conflict.

In the specific case, since there is no obligation to define the variables (as happens with Pascal), the SHARED keyword was created to emphasize the fact that a certain variable is not defined in the function - therefore it is global. On the other hand, the GLOBAL keyword is used to reserve a variable (or a set of variables) in advance for shared use with all functions, not one in particular.
Neotenien a écrit : 17 juil. 2022 16:32confusing for coders
:roll:
Neotenien a écrit : 17 juil. 2022 16:32reduice the potential name of user variable or functions
In ugBASIC there is no such risk since language keyword is always UPPERCASE.
Neotenien a écrit : 17 juil. 2022 16:32not have a polymorphism paradigm
Since ugBASIC is not OOP, there is no such constraint.
Neotenien
Messages : 354
Inscription : 23 oct. 2020 19:15
Localisation : Le Mans
Contact :

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par Neotenien »

YA quand même des choses pas forcément judicieux dans ce qui est écrit

Oui les opérations sur flittant prennent bcp de cycles, mais c'est normal au vue de la complexité du truc quand on voit que l'algorithme de multiplication d'un simple 8x8 sur les non 6809 prennent déjà au moins 35 cycles (algoirithme optimisé basé sur des déclaages et additions). Alors 500 cycles ou 1000 cycle pour une multiplication de flottant 4 octets, n'a rien d'étonnant mais ça reste rapide quand même (mois d'1 ms!!) pour un processeur à 1 MHz! Les ordinateurs les plus puissant qui soient ont aussi leur limites (cf la loi de With, le créateur de Pascal, Oberon et Modula)

D'autres part, même le 64 bits ne donnera une opération le plus précis possible à cause de la limites de bits... Mais ne pas oublier que les appareils de captages numériques ont aussi leur limites, c'est à dire qu'on n'aura jamais la valeur exacte Avoir une précision à 128 bits est déjà énorme et a-t-on beosin de plus ? En astronomie pour attendre un objectif lointain, la précision est indispensable, idem pour des sciences tels que l'atomistique, mais entre les 2 la précision à 10-7 est largement suffisant. Sinon il y a aussi les nombres illimités en char dans des langages tels Python ou PHP (librairie BC Maths).mais est ce bien nécessaire ?

Enfin pour en revenir aux fonctions, si Marco me dit que ugBasic n'utilise pas les piles, ça signifie que ça n'utilise pas la récursivité et ça pose un gros problème! Pour le jéu "démineur extreme" que j'ai programmé, j'ai justement utilisé les piles pour la découverte des cases en cascade (avec PULU PSHU) pour le 6809 et c'est (les fonctions récursives) une méthode ultra-utilisée dans l'algorithmique. La limite est la quantité de RAM qu'on utilise pour les piles... Mais j'ai quand même écrit un démineur avec des grilles allant jusqu'à 30x16 et donc une pile qui peut, potentiellement avoir plus de 100 processus fils en assembleur 6809. Les langages Pascal pour ordinateurs 8 bits dont j'ai parlé avant, utilise les piles.

J'espèrais que UG Basic peut utiliser les fonctions récursives, et c'est ce que j'espérais en voyant qu'il existait des processus, sinon ce langage n'a AUCUN intérêt pour moi et je retourne à l'assembleur!!

Pour ce qui est de l'extramoniteur des TO8/MO6, oui ça n'existe pas sur MO5, mais justement, je pensais que ug Basic ne compilait des fonctions que si ça existait sur telle ou telle machine, et sachant qu'il y a un compilateur pour MO6 et un pour MO5, je croyais que ça pouvait faire des fonctions existantes sur MO6 et pas sur MO5... Mais apparemment d'après Marco, le fait qu'il y ait différents compilateurs pour différentes machine ne signifie pas que c'est pour adapter à chaque machine mais juste pour suivre un schéma de MAJ pour chaque machine... Bon ben tant pis. Peut-être que je n'ai pas compris le fonctionnement après tout.

Le langage Pascal est loin d'être obsolète!! Maintenant c'est Free Pascal, ou Gnu Pascal qui ont pris la relève de Delphi mais ça reste du Pascal basé sur Turbo Pascal 7 (et +). Je vous invite à lire ceci à propos du Pascal comparé au C...

Pour ce qui est d'écrire des animations en fil de fer, non le but n'est pas d'avoir des "faux" 3D en fil de fer, le Thomson est capable de le faire, i y a tout d'inclus dans l'extramonitor pour ça et vu quo'n est dans un écran faible résolution, les flottant à 4 octets sont largement suffisant. Et si ça met 1 ms pour une multiplication c'est + qu'il nen faut (même à 10 ms!!)

Et pour répondre à ceci "Truthfully, any kind of 8-bit 3D attempt falls into two categories: it's a "fake 3D" or it's pre-computed. In neither case is it necessary to have neither trigonometric functions nor floating point numbers (in fact you don't even need fixed point numbers).", je ne suis pas d'accord!! Le thomson TO/MO est capable de faire de la 3D, il y a au moins 3 logiciels de 3D/CAO qui ont été créé sur cette plate forme. Les thomson n'ont pas pour but d'être des ordinateurs de la NASA, faire des calculs avec une incertitude de 1% au pire est largement suffisant.
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 00:18 Enfin pour en revenir aux fonctions, si Marco me dit que ugBasic n'utilise pas les piles, ça signifie que ça n'utilise pas la récursivité et ça pose un gros problème!
Êtes-vous sûr? Je pense que c'est un problème uniquement pour ceux qui ne savent pas comment convertir un algorithme récursif en un itératif, et c'est un exercice que je pense qu'ils font en première année de n'importe quel cours d'informatique. Bref, cela ne me semble pas être un gros problème, compte tenu plutôt des énormes avantages en termes de performances.
Neotenien a écrit : 18 juil. 2022 00:18J'espèrais que UG Basic peut utiliser les fonctions récursives, et c'est ce que j'espérais en voyant qu'il existait des processus, sinon ce langage n'a AUCUN intérêt pour moi et je retourne à l'assembleur!!
Les fonctions récursives et l'efficacité ne se retrouvent presque jamais dans la même phrase, encore moins si nous incluons également le mot assembleur.
Neotenien a écrit : 18 juil. 2022 00:18Peut-être que je n'ai pas compris le fonctionnement après tout.
Plus que comprendre, vous devez être conscient des conséquences de la création de dépendances. La décision de ne pas s'appuyer sur des bibliothèques (ROM) pour certaines fonctionnalités BASIC dépend du fait que l'utilisation d'une bibliothèque externe introduit une dépendance et une abstraction, qui n'existent pas nécessairement dans d'autres environnements. Cela ne vous permettrait pas d'écrire le code une seule fois et de le faire fonctionner partout. ugBASIC est capable de faire des choses sur toutes les résolutions et tous les modes graphiques, ce que les ROM Thomson ne peuvent pas faire. Cet avantage est infiniment supérieur à essayer de recycler les fonctions ROM. Et parlons de quelque chose d'assez simple. Il existe d'autres fonctionnalités, telles que la possibilité de "piloter" l'écran avec des commandes intégrées dans des chaînes, qui dans BASIC sont essentielles et rarement implémentées de manière cohérente par toutes les ROM.
Neotenien a écrit : 18 juil. 2022 00:18Je vous invite à lire ceci à propos du Pascal comparé au C...
Continuer à faire des comparaisons entre différentes langues pour présumer pouvoir démontrer la supériorité de l'une ou de l'autre, sans évaluer le contexte d'application, n'est à mon avis pas une approche correcte.
Neotenien a écrit : 18 juil. 2022 00:18Et si ça met 1 ms pour une multiplication c'est + qu'il nen faut (même à 10 ms!!)
Une animation de qualité minimale doit avoir au moins 3 images par seconde. Cela nous donne 333 ms pour chaque trame. Si un produit prend 1 ms, cela signifie qu'il n'est pas possible d'en faire plus de 333, ce qui exclut clairement le temps de faire d'autres opérations (pas nécessairement mathématiques).

Je ne me souviens pas du détail des transformations 3D mais je rappelle que dans le cas très simplifié où l'origine coïncide avec le point de vue, il doit y avoir au moins un produit et une division pour chaque composant. En supposant que la division coûte deux fois plus qu'un produit, nous avons que chaque point prend 6 ms. On ne peut donc pas dépasser environ 50 points par image, ce qui équivaut à environ 12 tétraèdres.

Quand je parle de "fake 3D" je fais référence au rendu de l'équivalent de nombreux dizaines de tétraèdres avec un minimum de 6-8 images par seconde. D'autre part, avec le pré-calcul, la limite est uniquement la bande passante disponible pour transférer les coordonnées et la mémoire disponible pour stocker la totalité des coordonnées.

Avec 8 bits, à mon avis, cela fait beaucoup de différence.
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 01:23
Neotenien a écrit : 18 juil. 2022 00:18 Enfin pour en revenir aux fonctions, si Marco me dit que ugBasic n'utilise pas les piles, ça signifie que ça n'utilise pas la récursivité et ça pose un gros problème!
Êtes-vous sûr? Je pense que c'est un problème uniquement pour ceux qui ne savent pas comment convertir un algorithme récursif en un itératif, et c'est un exercice que je pense qu'ils font en première année de n'importe quel cours d'informatique. Bref, cela ne me semble pas être un gros problème, compte tenu plutôt des énormes avantages en termes de performances.
Neotenien a écrit : 18 juil. 2022 00:18J'espèrais que UG Basic puisse utiliser les fonctions récursives, et c'est ce que j'espérais en voyant qu'il existait des processus, sinon ce langage n'a AUCUN intérêt pour moi et je retourne à l'assembleur!!
Les fonctions récursives et l'efficacité ne se retrouvent presque jamais dans la même phrase, encore moins si nous incluons également le mot assembleur.
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!! Parce 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) et un autre exemple, l'algorithme de Tri Quick Sort, le plus rapide au monde, utilise justement les fonctions récursives (d'ailleurs au début des années 90 je m'étais amusé à créer la version Basic Thomson de cet algorithme, ça a été galère de créer des variables tableau pour les piles, mais l'algorithme fonctionnait et le tri était nettement plus rapide sur le Basic Thomson quie les tri Bulle, Sélection, Insertion)!! Visiblement vous n'avez pas fait des études dans une grande école d'informatique comme le CNAM... Et il existe un tas d'autres exemple où le récursif est nécessaire... Evidemment si votre référence est l'algoritme de calcul du nombre de Fibonacci par la mauvaise méthode (c'est à dire par addition de 1 à chaque fois) et pas par les fonctions récurrentes, c'est sûr qu'au niveau des performances c'est pas top.

Mon 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 :
, là aussi c'est indispensable!
spotlessmind1975 a écrit : 18 juil. 2022 01:23
Neotenien a écrit : 18 juil. 2022 00:18Peut-être que je n'ai pas compris le fonctionnement après tout.
Plus que comprendre, vous devez être conscient des conséquences de la création de dépendances. La décision de ne pas s'appuyer sur des bibliothèques (ROM) pour certaines fonctionnalités BASIC dépend du fait que l'utilisation d'une bibliothèque externe introduit une dépendance et une abstraction, qui n'existent pas nécessairement dans d'autres environnements. Cela ne vous permettrait pas d'écrire le code une seule fois et de le faire fonctionner partout. ugBASIC est capable de faire des choses sur toutes les résolutions et tous les modes graphiques, ce que les ROM Thomson ne peuvent pas faire. Cet avantage est infiniment supérieur à essayer de recycler les fonctions ROM. Et parlons de quelque chose d'assez simple. Il existe d'autres fonctionnalités, telles que la possibilité de "piloter" l'écran avec des commandes intégrées dans des chaînes, qui dans BASIC sont essentielles et rarement implémentées de manière cohérente par toutes les ROM.
A 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 fait que le langage est universel n'implique pas que la façon de compiler le programme pour chaque machine soit la même... Le GNU C est un langage ayant la même synthaxe et pourtant il existe pour plein de processeurs différents! 68k, Power PC, Intel, ARM. La distrubution Gnu Debian existe ous plus de 5 microprocesseur différent ( ceux que j'ai cité + un nouveau le ColdFire qui est une amélioration en terme de performance et d'économie d'énergie des 68k).

De la façon dont c'est agencé j'aurai pu penser que vous ayiez créé des exécutables de compilation ug basic propre à chaque machine (avec des librairies)... Personnellement, 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... Par exemple, en compilant pour le 64, il y aura un include de librairie propre au 6502 (pour l'assembleur) et une autre pour le C64 qui inclut les trucs propres à cette machine (dont la ROM pour éviter de recopier), ça me parait cohérent comme démarche.

En Pure pascal par exemple, pour programmer un logiciel portable, il y aura la librairie des fonctions commune à chaque langages (des algorithmes comme l'ensemble des fonction mathématique inexistante en Pure Pascal que j'ai écrite) et la librairie de l'environnement de fenêtres qui doit être réécrite pour chaque machine, mais avec des noms commun (par exemple, une fonction open_win() sera écrite d'une manière pour les ATari TT/Falcon et différemment sur Windows, QT etc)... Je ne sais pas si vous comprenez ce que j'essaie de dire...
spotlessmind1975 a écrit : 18 juil. 2022 01:23
Neotenien a écrit : 18 juil. 2022 00:18Je vous invite à lire ceci à propos du Pascal comparé au C...
Continuer à faire des comparaisons entre différentes langues pour présumer pouvoir démontrer la supériorité de l'une ou de l'autre, sans évaluer le contexte d'application, n'est à mon avis pas une approche correcte.
Si ç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... En gros, en C on a un peu les mêmes soucis "technique" de développement qu'on a en assembleur alors qu'en Pascal on ne les a pas tout en ayant des logiciels solides et performants. Par exemple, je suis sûr qu'un logiciel comme LazPaint aurait mis 4 fois plus de temps à être développé en C.
spotlessmind1975 a écrit : 18 juil. 2022 01:23
Neotenien a écrit : 18 juil. 2022 00:18Et si ça met 1 ms pour une multiplication c'est + qu'il nen faut (même à 10 ms!!)
Une animation de qualité minimale doit avoir au moins 3 images par seconde. Cela nous donne 333 ms pour chaque trame. Si un produit prend 1 ms, cela signifie qu'il n'est pas possible d'en faire plus de 333, ce qui exclut clairement le temps de faire d'autres opérations (pas nécessairement mathématiques).
Vous ne prenez pas le problème par le bon bout. On sait que les processeurs 8 bits ne sont qu'à 1 MHz et ne peuvent pas soutenir la comparaison avec des processeur 4000 fois plus rapides (en MIPS). Mais pour le tracé d'un tétraèdre ou d'un cube, on a juste besoin de calculer les positions 2D de quelques points points et si, pour chaque point (en calculant l'angle/centre de gravité de chaque point du cube (8 pts)) on met moins de 10 ms (temps largement surestimé, surtout si on utilise les nombre à point fixe), on a 8 pts = 80ms... et le tracé des 12 lignes du cube, on est largement plus rapide que les 3 image/seconde... A titre d'exemple, je vous invite à regarder cette vidéo du,meilleur jeu de labyrinthe 3D sur Thomson MO5, Minotaure 3D, je pense que tous les "noeuds" ici sont calculés en temps réel suivant les mouvements du joueur (la preuve on a des rotations gauche droite et haut bas):

spotlessmind1975 a écrit : 18 juil. 2022 01:23 Je ne me souviens pas du détail des transformations 3D mais je rappelle que dans le cas très simplifié où l'origine coïncide avec le point de vue, il doit y avoir au moins un produit et une division pour chaque composant. En supposant que la division coûte deux fois plus qu'un produit, nous avons que chaque point prend 6 ms. On ne peut donc pas dépasser environ 50 points par image, ce qui équivaut à environ 12 tétraèdres.
On a un centre de gravité, une distance/rayon de chaque sommet du polyèdre/centre de gravité, un angle vertical et un angle horizontal. Une fois qu'on a trouvé la coordonnée en 3D, on fait une épure (c'est à dire on applique un sin pour apliquer sur un écran 2d). Ce sont les coordonnées sphériques. Pour chaque point (en supposant que le rayon est en pxl, ça fera un calcul de moins), on applique juste 2 fois un angle sachant que x=r.sin(a).cos(b), y=r.cos(a).cos(b) et que z=r.sin(b).

Maintenant, il faut quand même dire qu'il y a eu de nombreux jeux 3D développé sur Atari ST ou Falcon 030 qui tournaient à 2 voire 1 image/seconde en utilisant la 3D (mais à faces pleines). Il y a eu un développeur qui a adapté le Doom des PC sur Atari Falcon 030 en utilisant les Wad, et le jeu trournait parfois à moins d'1 image par seconde... Donc les Thomson n'auront pas à rougir s'ils font de la 3D à 3 images par seconde (ou alors faut utiliser un 6309 avec les fonctions arithmétique supérieures et une fréquence de 8 MHz pour donner un truc fluide à faces pleines).
spotlessmind1975 a écrit : 18 juil. 2022 01:23 Quand je parle de "fake 3D" je fais référence au rendu de l'équivalent de nombreux dizaines de tétraèdres avec un minimum de 6-8 images par seconde. D'autre part, avec le pré-calcul, la limite est uniquement la bande passante disponible pour transférer les coordonnées et la mémoire disponible pour stocker la totalité des coordonnées.
Je suppose que ça se rapproche de la démo "Blue cube" de Prehisto sur Thomson TO8
spotlessmind1975 a écrit : 18 juil. 2022 01:23 Avec 8 bits, à mon avis, cela fait beaucoup de différence.
Ce n'est qu'un avis...Voir les logiciels Anima 3D et C.A.O.
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 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.
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").
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.
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.
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.
Neotenien a écrit : 18 juil. 2022 04:04De la façon dont c'est agencé j'aurai pu penser que vous ayiez créé des exécutables de compilation ug basic propre à chaque machine (avec des librairies)...
Avec ugBASIC, j'ai décidé de ne pas faire de compromis, de ne pas frapper une pièce avec un marteau pour tenter de la forcer à l'intérieur jusqu'à ce qu'elle prenne forme. J'ai commencé par étudier comment étaient conçues les machines 8 bits, les solutions identifiées à l'époque, qui ne me paraissent pas fausses. J'ai essayé de construire autour de ça un langage qui avait des primitives qui faisaient sens, et qui se déclinaient selon les caractéristiques de chaque machine. Cela a conduit à une complexité considérable qui a justifié la "segmentation" des compilateurs, mais pas parce que le but était de différencier leur comportement mais de garder la complexité contrôlable.
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.
Neotenien a écrit : 18 juil. 2022 04:04dont la ROM pour éviter de recopier
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.
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.
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.
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.
spotlessmind1975 a écrit : 18 juil. 2022 01:23Je suppose que ça se rapproche de la démo "Blue cube" de Prehisto sur Thomson TO8
Pour la "fausse 3D", l'exemple typique est DOOM, qui n'est pas de la vraie 3D.
spotlessmind1975 a écrit : 18 juil. 2022 01:23Ce n'est qu'un avis...
Je suis désolé, mais je ne pense pas qu'ils soient supérieurs à un exemple didactique.
__sam__
Messages : 7909
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: ugBASIC est arrivé sur Olivetti Prodest PC128!

Message par __sam__ »

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

Laisses Marco faire ugBasic comme il le veut. Ok c’est pas ce que tu veux toi, mais d’une part tu n’es pas tout seul, et ce que tu désires n’est pas forcément réaliste.

Dis toi que si ce que tu veux a du sens, que c’est forcément cela qu’il faut faire, alors ugBasic finira bien, en suivant la pente naturelle à passer par le point que tu indiques.

Sois juste un peu patient et surtout moins agressif. C’est très désagréable pour moi qui te connaît un peu sur un autre forum, alors je n’imagine pas quelle mauvaise impression tu laisses auprès de ceux qui ne te connaissent pas bien.
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
Répondre