Blog PureBasic: Nouvel article

[Marc56]

Hello,

Fred à posté un nouvel article sur le blog.
https://www.purebasic.fr/blog/?p=480

(Pour ceux qui ne seraient pas anglophones et n'auraient pas accès à un traducteur en ligne ou au blog, traduction automatique ci-dessous)

TL;DR pas de LLVM car après essais c'est finalement plus compliqué qu'autre-chose, le back-end sera désormais en C et c'est bien pour la suite.

PureBasic et les variétés croissantes de CPU

Les premières versions de PureBasic ont débuté sur Amiga, avec le support de la série de CPU Motorola 680×0. PureBasic a été conçu dès le départ pour générer du code assembleur brut, et le premier back-end assembleur CPU fonctionnel était celui du 680×0. Comme l'audience sur Amiga diminuait rapidement, nous avons décidé de passer au PC. En 1998, il n'y avait qu'une seule architecture de CPU PC, le x86, et il a été décidé d'ajouter un nouveau back-end d'assemblage pour celui-ci. C'est une tâche qui prend beaucoup de temps et qui demande beaucoup d'apprentissage pour être capable de gérer un nouvel assemblage. Les architectures 680×0 et x86 sont assez opposées, mais elles s'adaptaient à l'architecture PureBasic et PureBasic pour x86 était une réalité.

Peu de temps après, nous avons décidé d'opter pour la multiplateforme et de prendre en charge OS X, qui fonctionnait sur des processeurs PowerPC. Un nouveau back-end d'assemblage était nécessaire et nous avons recommencé, pendant presque une année entière pour obtenir quelque chose de fonctionnel. Peu de temps après, Apple a annoncé qu'ils allaient abandonner le support de PowerPC et choisir x86 à la place ! Ce fut un coup dur pour nous, et une perte de temps considérable. Entre-temps, x86-64 est sorti et a lentement gagné en popularité et nous savions que nous devions le supporter également. Contrairement à ce que le nom suggère, x86 et x86-64 sont deux bêtes différentes, et beaucoup de travail a été nécessaire pour y parvenir. Mais l'informatique évolue rapidement et une nouvelle architecture de CPU est apparue et a pris le monde d'assaut, d'abord sur les mobiles, puis sur les petits ordinateurs et maintenant sur les ordinateurs de bureau : ARM et ARM-64.

Pour prendre en charge ces nouvelles plates-formes, nous sommes à nouveau confrontés au même problème : nous avons besoin de nouveaux back-ends d'assemblage. En tant que petite entreprise, nous ne pouvons pas consacrer une année entière à chaque fois qu'un nouvel assemblage émerge, nous devons donc trouver une solution à l'épreuve du temps. Entre-temps, un fork du compilateur PureBasic a été créé pour générer un langage de haut niveau au lieu de l'assembleur brut. Cela a permis de créer SpiderBasic, un langage similaire à PureBasic qui peut fonctionner sur le navigateur en générant du code JavaScript.

Lorsqu'Apple a annoncé que ses nouveaux ordinateurs fonctionneraient sur ARM, nous savions que nous devions changer notre façon de gérer l'architecture des nouveaux processeurs et nous avons décidé de tirer parti du travail déjà accompli par SpiderBasic et de le porter à nouveau pour PureBasic. Nous avons beaucoup expérimenté avec LLVM depuis un certain temps déjà, mais c'est un casse-tête de le trouver sur toutes les architectures. De plus, c'est une sorte de mélange entre le code d'assemblage et le langage de haut niveau, ce qui ne correspondait pas à l'architecture dorsale de PureBasic ou de SpiderBasic. Au cours des 8 derniers mois, nous avons décidé de nous concentrer sur un nouveau back-end de haut niveau pour PureBasic : le langage C.

La bonne nouvelle est que l'ensemble des tests du compilateur PureBasic fonctionne avec succès sur le back-end C. Nous sommes donc très confiants quant à la possibilité d'avoir un compilateur prêt à tester rapidement. Restez à l'écoute, plus de détails à venir !

Traduit avec http://www.DeepL.com/Translator (version gratuite)

--- VO

PureBasic and increased varieties of CPU

Early versions of PureBasic started on Amiga, with the support of the Motorola 680×0 CPU series. PureBasic has been designed from start to generate raw assembly code, and the first working CPU assembly back-end was the one for 680×0. As the audience on Amiga was quickly falling, we decided to move on PC. In 1998, there was only one PC CPU architecture, the x86, and it was decided to add a new assembly back-end for it. It is a very time consuming task and requires a lot of learning to be able to handle a new assembly. 680×0 and x86 architectures are quite opposite but it fitted in the PureBasic architecture and PureBasic for x86 was a reality.

Shortly after, we decided to go really cross-platform and support OS X, which was running on PowerPC processors. A new assembly back-end was needed and we did it again, during almost a full year to get something working. Shortly after, Apple announced they will drop support for PowerPC and choose x86 instead ! That was a huge blow for us, and a lot of time wasted. In the meantime, x86-64 was released and slowly gaining traction and we knew we should support it as well. Unlike the name suggests it, x86 and x86-64 are two different beasts, and a lot of work was needed to make it happen. Once done, we though we could finally focus on functionalities for a while, but computer science is evolving at quick rate and a new CPU architecture appeared and took the world by storm, first on mobiles, then on tiny computers and now on desktop: ARM and ARM-64.

So here we are, to support these new platforms, we face the same issue again: we need new assembly back-ends. As a small company, we can’t dedicate a whole year every time a new assembly emerge, so we need to find a future proof solution. Meanwhile, a fork of the PureBasic compiler has been created to generate high-level language instead of raw assembly. This allowed to create SpiderBasic, a PureBasic-like language which can run on the browser by generating JavaScript code.

When Apple announced their new computers will be running on ARM, we knew we needed to change our way to handle new processors architecture and we decided to leverage the work already done of SpiderBasic and port it back for PureBasic. We experimented a lot with LLVM for quite a time now, but it is an headache to find it on all architectures. Also it’s a kind of mix between assembly code and high-level language so it didn’t fit either PureBasic or SpiderBasic back-end architecture. For the past 8 months, we decided to focus on a new high-level back-end for PureBasic: the C language.

The good news is the whole PureBasic compiler test suit is successfully running on the C back-end, so we are very confident we could have a compiler ready to test quickly. Stay tuned, more details to come soon !

--- La suite des réactions (en anglais) ci-dessous
https://www.purebasic.fr/english/viewto ... 92#p567092

[Thyphoon]

C'est une super nouvelle ^_^

[Ar-S]

Je vois bien que c'est une super nouvelle mais je vois pas trop pourquoi ?
ça signifie qu'on va pouvoir installer PB sur Rpi ou les M1 d'apple dans la prochaine mouture ?

[Thyphoon]

Je vois bien que c'est une super nouvelle mais je vois pas trop pourquoi ?
ça signifie qu'on va pouvoir installer PB sur Rpi ou les M1 d'apple dans la prochaine mouture ?

Il y a des chances

[Ar-S]

ça ce serait top. En espérant qu'un effort soit fait pour l'installe sur linux.

[kernadec]

bjr
c est une bonne nouvelle

Donc, si j'ai bien compris PureBasic ne sera plus compilé en ASM directement
mais va etre converti en langage C pure et dur de base..
qui pourra ensuite etre compilé sur n importe quel version de processeur...
tout comme SpiderBasic qui devient du javascript pour etre executer
par un run java sous chaque processeur...

Cordialement

[Marc56]

Spiderbasic produit du Javascript, pas du Java

[kernadec]

Salut Marc56
Merci, c est corrige
C est vrai java et un langage compile.
Une question se pose maintenant que deviendra SPiderBasic

Cordialement

[Kwai chang caine]

@Marc56
Merci pour cette info
Depuis le temps qu'on parle d'un autre systeme pour PB surement LLVM on sait déjà que ce sera pas lui
Maintenant se baser sur le C qui est fiable et qui a derrière lui X codeurs, c'est pas une mauvaise idée, c'est un peu comme si la team doublait ou même plus
L'idée était bonne d'utiliser l'ASM, mais c'est trop prêt de la machine, et à chaque nouveau système faut tout recoder
Faut dire qu'à l'époque, personne n'aurait pu se douter des révolutions de systèmes qui se sont opérées ces dernières années même pas BILOU qui s'est bien fait trombiner en ne croyant pas à ANDROID
Et en plus, du peu que j'ai vu du C, c'est facile aussi d'obtenir l'ASM à partir de lui, et y'a pas mal de compilateurs gratuits
Et ben...ça va encore donner du boulot à la TEAM de changer le moteur de PB, avec tous les dangers que ça comporte
On est pas prés de les avoirs nos nouvelles fonctions.... maintenant notre FREDO il fait surement ce qu'il peut...bien que ses voies restent toujours impénétrables

Donc, si j'ai bien compris PureBasic ne sera plus compilé en ASM directement
mais va etre converti en langage C pure et dur de base..

Si c'est ça !!!!! Retour dans le futur à coté c'est de la gnognote !!!!

Si FRED revient au C, comme tous les développeurs de la vieille école, ça va me permettre de me foutre de la gueule de tous ceux qui se seront foutus de la mienne, lorsque je leur parlais de mon amour pour ce langage "Obsolete" comme ils disent ....



Maintenant par C, FRED entends peut être C++, il va peut être pas ressortir le gourdin et le silex

Une question se pose maintenant que deviendra SPiderBasic

C'est aussi la première question que je me suis posé
Peut être un pur web createur, plus d'android ou autres joyeuseries du genre ....

[blendman]

salut

Alors là, wahoutch ! Je suis tombé de mon slip en lisant cette news
Punaise de bistouflaïlle, je trouve que c'est une super nouvelle, pour plein de raisons !
Tout d'abord, ça montre que non seulement purebasic n'est pas prêt d'être abandonné (youpi !), mais en plus, Fred (et la pb team) travaillent carrément pour qu'il devienne encore plus pérenne, performant et puisse être facilement utilisable sur un maximum d'appareils (si j'ai bien compris, puisqu'ils parlent de processeur x86, x64, arm, etc).

Je suis toujours épaté (et le mot est faible), par la ténacité, le courage, la persévérance et l'immense motivation que Fred a concernant le purebasic.
Je ne connais pas d'autres exemples de langages ou logiciels maintenu ainsi et amélioré pendant plus de 23 ans par la même personne, et qui prévoit de continuer à le développer encore. Il est quand même exceptionnel notre Fred (oui, c'est le notre, oui).

Concernant le fait de passer à un compilateur C, je trouve que c'est une super nouvelle et une top idée aussi.
Déjà, je pense que Fred maitrise ce langage, donc il n'a pas à tout réapprendre. En plus, il trouvera sans doute plus facilement de l'aide pour mettre ça en place.
Qui plus est, le C est un langage très robuste, performant, ancien et donc solide, avec des compilos réalisés par des experts, qui ont fait leurs preuves depuis plus de 20 ans.
Mais l'autre chose intéressante, c'est que pas mal d'utilisateurs de purebasic connaissent aussi le C (si j'ai bien lu sur le forum eng), et donc, il y aura un engouement et des possibilités bien plus grandes d'ajout de code dans nos codes pb, comme on peut faire avec l'asm aujourd'hui.
Il est même possible que ça amène de nouveaux utilisateurs qui connaissent le C vers Purebasic, qui sait.
Enfin, un autre avantage, non des moindres, c'est qu'on va apprendre petit à petit à mieux connaitre ce langage (le C), car contrairement à l'asm qui est un peu obscure et incompréhensible, le C, c'est beaucoup plus compréhensible.
Des bouts de codes en C, on en trouve à la pelle sur le net.
En plus, si j'ai bien tout compris sur le forum anglais, il est probable que nos applications soient plus rapides du coup, plus performantes, etc... (enfin, ça, on vérifiera quand on pourra compiler).

Par contre, je n'ai rien vu sur la licence ou la forme que ça va prendre :
cela va-t-il être une nouvelle version de purebasic (genre purebasic 6.0) ?
Ou carrément un nouveau logiciel et une nouvelle licence (comme spiderbasic), par exemple un "Purebasic-C" ou "purebasic II", avec achat d'une nouvelle licence ?

vivement la suite en tout cas
Je trouve que c'est vraiment une formidable nouvelle !

[Kwai chang caine]

Tout a fait, j'aurais aussi pas dit mieux
Vive le C et vive notre Fred et son courage
Pourrons dire ce qu'ils veulent les ricains et autres français qui parlent pas français ...mais il est à nous "Capitaine Framd" venu d'une autre galaxie
Comme tu le dis, je serais curieux de voir si un seul des PBien a su créer un giciel fini de cette envergure et l'entretenir pendant 26 longues années sans abandonner en chemin

Bon...maintenant qu'on a appris qu'on allait avoir une belle blonde compatible à 70% , c'est comme dans "Marié au premier regard" les jours qui nous séparent de la visite chez monsieur le maire, pour pouvoir juger nous même de cette statistico-compatibilité vont paraître long....mais looooooong !!!!!

[Mesa]

Le problème du C, c'est son temps de compilation qui est très lent, du à l'optimisation du code et peut prendre plusieurs secondes... et ceci à chaque compilation. Donc au revoir la compilation instantanée. La correction des coquilles pourrait être une galère, comme en C.

Toutefois Fred nous promet un temps de compilation très faible en dev mode et tant que l'on n'utilise pas le mode optimisation ou le mode release du compilo. Sinon, un simple "openwindow()" pourrait prendre de 3 à 5 secondes de compilation, c'est tout à fait possible en mode release (création de l'exe) ! A voir donc.

Un Inline C sera supporté, ce qui veut dire que l'on pourra réutiliser les nombreux codes C du net, ce qui est bien mais avec le risque que les pbsiens abandonnent le basic pour la facilité du copier-coller de codes en C ! ?
On verra à l'usage.

M.

[Ar-S]

Tant qu'on est pas obligé d'importer 50 libs géantes pour faire un prog de 500ko ça me va.
Perso je ne code pas en C. Trouver des routines "prêtes à l'emploi" pourra être bien pratique mais la syntaxe PB restera mon fer de lance en ce qui me concerne.

[Kwai chang caine]

avec le risque que les pbsiens abandonnent le basic pour la facilité du copier-coller de codes en C

Peut être qu'on pourra rajouter du C au milieu du PB comme pour l'ASM après c'est peut être ce que veut dire "inline C"

Quoi qu'il en soit, si il doit en rester qu'un qui utilisera toujours le PB, je serais celui là
Ca fait 26 ans que je sais que y'a de l'ASM accessible derrière PB, à part l'admirer, et le copier coller comme tu dis, je me suis jamais amusé à toucher ne serais ce qu'une virgule de l'ASM, vu la puissance de dingue du langage, de peur de changer de PC

J’espère que si FRED passe par là, il pourra nous dire si il parle de C ou de C++, et si il a déjà une idée duquel il voudrait se servir
Je sais qu'il a utilisé Microsoft pour son debugger et sa "simplicité" (tout est relatif avec le C ) de programmation, j'avais trouvé bizarre qu'il n'utilise pas GCC ou ce genre de truc puissant gratuit et reconnu du monde entier.
Je sais aussi qu'il avait dit il y a bien longtemps que si il devait tout recommencer il utiliserait QT....

En tout cas merci MESA de cette explication, je ne savais pas que le C était long à compiler
Ce que tu viens de dire me fait comprendre pourquoi compiler Firefox prenait plusieurs heures sur mes machines

[G-Rom]

C'est une bonne nouvelle, compilé en PB sur Arduino ou mes Rpi , ca peut être super cool.

Le problème du C, c'est son temps de compilation qui est très lent

Fred utilisera surement gcc , les libs purebasics seront dejà compilé en .o , seul ton code sera compilé , le reste linké , ce qui sera rapide , pas autant que PB actuel , mais rapide tout de même.
enfin , si j'étais à la place de fred , c'est comme cela que je ferais.

quand à spiderbasic... bah il ne servira plus à rien , avec emscriptem , le nouveau PB pourra compilé partout , le web, le desktop , l'embarqué , etc...
le langage risque vraiment de décollé pour le coup. en tout cas, c'est clair que je l'utiliserais.



@blendman
Content de te relire, j'espère que tu vas mieux

Code : Tout sélectionner

Déjà, je pense que Fred maitrise ce langage

Oui, oui , t'inquiète pas pour cela, toutes les lib PB sont faites en C/C++.

Code : Tout sélectionner

Un Inline C sera supporté, ce qui veut dire que l'on pourra réutiliser les nombreux codes C du net, ce qui est bien mais avec le risque que les pbsiens abandonnent le basic pour la facilité du copier-coller de codes en C ! ?
On verra à l'usage.

Mouais, faire du copié coller fait de la personne qui le pratique un mauvais codeur. et entre copier collé du code et se faire un environnement de dev en C/C++ solide , il y a un monde. je suppose que PB te serviras la soupe
comme il le fait actuellement en facilitant l'environnement de dev, il n'y a d'ailleurs à ma connaissance aucun service identique pour le C , peut être raylib qui fourni un environnement de dev complet. pour le reste c'est les mains dans le cambouis


en tout cas, hâte que cela arrive, l'import de lib va être un jeu d'enfant , plus de wrapper de merde à faire ^^