Les membres ayant 30 points peuvent parler sur les canaux annonces, projets et hs du chat.
La shoutbox n'est pas chargée par défaut pour des raisons de performances. Cliquez pour charger.

Forum Casio - Discussions


Index du Forum » Discussions » Créer un compilateur fxsdk utilisable sur calculatrice
Yannis300307 Hors ligne Membre Points: 297 Défis: 0 Message

Créer un compilateur fxsdk utilisable sur calculatrice

Posté le 10/09/2022 17:46

Bonjour, ça fait un moment que je me demandais si c'était possible de créer un compilateur C (comme fxsdk) utilisable directement sur calculatrice. Je pence que ce serais pratique de ne pas avoir besoin d'un ordi pour compiler (même si la compilation pourrais durer longtemps).

Je voulais avoir votre avis à ce propos.

Merci


Lephenixnoir Hors ligne Administrateur Points: 24678 Défis: 170 Message

Citer : Posté le 10/09/2022 17:56 | #


Salut ! C'est... possible, au sens technique du terme. Note que le fxSDK n'invente pas un compilateur, on utilise juste GCC qui existe depuis longtemps.

Écrire un compilateur C nécessite pas mal de connaissances techniques, et tu ne pourras pas tricher en réutilisant un petit compilateur publié en ligne puisque ces projets-là ne cibleront jamais le processeur SuperH de nos calculatrices.

Personnellement, je ne pense pas que « ne pas avoir besoin d'un ordi pour compiler » se matérialiserait comme tu l'espères, parce que vue la vitesse de frappe sur la calculatrice ça sera toujours beaucoup plus efficace de programmer sur le PC (sans compter la taille de l'écran pour les messages d'erreur, la navigation dans le code, etc).

Cela dit, les compilateurs sont un sujet fascinant, et je suis toujours partant pour démystifier ce qu'ils font et montrer comment en créer un en pratique (ce qui est totalement biaisé par le fait que je fais de la recherche en compilation...). Il y a déjà quelques topics assez détaillés à ce sujet, comme celui-ci de Shadow.

Pour répondre plus clairement à ta question : c'est possible, mais à moins que tu aies un master caché c'est probablement trop ambitieux. Cependant, si tu veux t'amuser avec un langage plus simple que le C et que t'es pas trop pressé alors là ça devient réaliste.
Mon graphe (11 Avril): ((Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; passe gint 3 ; ...) || (shoutbox v5 ; v5)
Shadow15510 Hors ligne Administrateur Points: 5504 Défis: 18 Message

Citer : Posté le 10/09/2022 18:05 | #


Ow, ce projet jamais terminé !
Ça me donne envie de lui passer un petit coup de chiffon, tellement de choses à faire et si peu de temps rhaaa >.>
"Ce n'est pas parce que les chose sont dures que nous ne les faisons pas, c'est parce que nous ne les faisons pas qu'elles sont dures." Sénèque

Yannis300307 Hors ligne Membre Points: 297 Défis: 0 Message

Citer : Posté le 10/09/2022 19:10 | #


Je n'est vraiment pas le niveau pour faire ça mais si quelqu'un s’ennuie fortement et a le niveau, il pourrait essayer de le faire !
WOW ! Mais qu'est-ce-que je vois ??!! Une extension VS Code qui permet de simplifier le développement sur calculatrices ??!! C'est ici : Casio Dev Tools. C'est incroyable ! C'est prodigieux !
Calamari En ligne Membre Points: 402 Défis: 0 Message

Citer : Posté le 16/10/2022 00:43 | #


I was just writing up a bunch of notes on a hybrid approach where the add-in's wouldn't need to be standalone (having them compile to standalone add-ins brings a lot of complexity). But, I came to one inescapable conclusion: I honestly think you'd be a lot better off first writing something like C.Basic. A lot of the work will be quite reusable for the compiler and you'll also gain valuable experience that will directly help you in writing a compiler later:

• You're going to want the program to spend as much time as possible inside library calls, because that's less code that the user has to write on the calculator. I'd imagine you'd even want to provide some kind of game engine. But, then, those library functions and the game engine are already going to be running at native speed. Unless you're writing something involving a lot of computation (chess program, raytracer, etc), I'm not seeing much of a speed advantage. And since you'll be writing a library, if you do go on to write a compiler, you can make direct use of it.

• Any approach would require a way to edit and debug the programs. This would inevitably involve F-key menus, etc. So, writing some kind of IDE is needed. And that could be later be reused for the compiler.

• There are already some painting add-ins, but you'll probably need to implement something as part of the IDE to be used for creating fonts and pixel art, where it could handle transparency, images smaller than the display, etc. It might also be nice to be able to at least import from some kind of simple standard graphics format, such as PPM.

• You're going to need to tokenize the C code using lexical analysis (and maybe even perform this as a pre-run step, as Python does). This lexer code can be directly reused later for a compiler.

• You're probably aware of this, but compilers are doing some level of interpretation during the compilation and optimization process. If you write "(3 + 4 * 5)" any decent compiler is going to turn that to 23 rather than actually emitting any multiply or add instructions. And, of course, being able to do this is something you'll need for the interpreter, so you'll gain experience for the compiler as well. I recommend researching algebraic to RPN conversion, recursive descent parsing, and LL grammars.

• You're going to end up thinking about many topics that you'll need for writing the compiler: How C expressions work at a low level, how things are arranged in memory, branching and function calls, calling conventions, etc.

Before you get to any of that, though...

I strongly recommend attempting to write a simple four-function integer calculator that respects the order of operations. Just "+", "-", "*", "/", negative numbers, and parenthesis.

When I was learning how to program, the fact that the computer could understand the order of operations was like magic to me. And, even after I'd implemented it myself and understood how it worked, it continued to be highly inspirational and motivational to me. I went on to write a number of interpreters and compilers for fun, a couple of which others used to write games. Looking back, I'm not exactly proud of the code I wrote for those, but I'm still proud of my accomplishment in doing so. And let me tell you, when someone uses a compiler you created to write and release a game, your ankles won't just swell, they will be in danger of bursting. I've also ended up writing this kind of code on the job to solve parsing problems that none of my coworkers knew how to handle, so it has professional uses as well.

There are many approaches and even automation tools you can use to write this calculator very easily. But, I'm going to recommend that you not use any tools and that you implement your calculator using a recursive descent parser. It's a simple, but very powerful approach to parsing that you can even use later to parse almost any type of familiar programming language (including C, although you might to use a tool for a compiler that complex).

To start writing your calculator, first write (by hand) a lexer that splits an input into tokens. Each token would have a type, either a number or an operator, and it would hold the value of the number or the type of operator. For the input "12 + (3 - 4) * -5" it should be able to output: Number: 12, Operator: ADD, Operator: OPEN PAREN, Number: 3, Operator: SUBTRACT, Number: 4, Operator: CLOSE PAREN, Operator: MULTIPLY, Operator: SUBTRACT, Number: 5. Don't attempt to combine "-" and "5" to "-5". Instead, that will be handled later and allows you to learn how to parse unary operators vs binary operators. Reserve an operator type of NEGATE for it, though.

Next, take those tokens, and write a recursive descent parser to convert the algebraic ordering of the syntax to RPN. Trust me, do not use the "shunting yard algorithm" for this, write an actual recursive descent parser. At first, just implement RPN output of numbers, MULTIPLY, and ADD.

Next, write a calculator that takes that RPN output and computes the answer. You now have a simple calculator that can properly compute "2 + 3 * 4"!

Once that works, output DIVIDE and SUBTRACT, and add those to the RPN calculator. Then handle parsing negative numbers and add NEGATE to RPN. Finally handle parenthesis. For me parenthesis felt extremely daunting, but the actual implementation turned out to be trivial, so in retrospect I worried for nothing.

And you've done it! Believe it or not, you're now well on your way to writing a simple compiler. Sure, maybe not some sophisticated optimizing compiler, but you'll start to see how you could write a simple compiler using what you've learned. Then you can go one study things like an AST.

If you attempt the calculator project please feel free to ask me anything. I'll try to help any way I can.
“Remember to have fun doing this, or it ain't worth it.” — Robert Alan Koeneke
“They call me the king of the spreadsheets, got 'em all printed out on my bedsheets.” — “Weird Al” Yankovic
Lephenixnoir Hors ligne Administrateur Points: 24678 Défis: 170 Message

Citer : Posté le 16/10/2022 09:03 | #


Excellent write-up, I fully agree with both the approach and the recommandations!

I'd like to nuance just one thing:

• You're probably aware of this, but compilers are doing some level of interpretation during the compilation and optimization process. If you write "(3 + 4 * 5)" any decent compiler is going to turn that to 23 rather than actually emitting any multiply or add instructions. And, of course, being able to do this is something you'll need for the interpreter, so you'll gain experience for the compiler as well. I recommend researching algebraic to RPN conversion, recursive descent parsing, and LL grammars.

The three recommended topics here are for parsing, which comes quite a while before the compiler turns 3+4*5 into 23. Analyses and optimizations typically occur on the AST after you've built it, on the IR if you have one, and optionally on the assembly code at the end.
Mon graphe (11 Avril): ((Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; passe gint 3 ; ...) || (shoutbox v5 ; v5)
Calamari En ligne Membre Points: 402 Défis: 0 Message

Citer : Posté le 16/10/2022 09:40 | #


For less sophisticated compilers you can skip the AST step and output tokens from the RDP. You won't get the benefit of optimization, but simple numerical calculations are almost free... you can just detect whether all the tokens are numeric and perform the calculation right in the RDP.
“Remember to have fun doing this, or it ain't worth it.” — Robert Alan Koeneke
“They call me the king of the spreadsheets, got 'em all printed out on my bedsheets.” — “Weird Al” Yankovic
Lephenixnoir Hors ligne Administrateur Points: 24678 Défis: 170 Message

Citer : Posté le 16/10/2022 09:41 | #


Right I think that is called that a Syntax-Directed Translator. I don't think it would scale to a language like Basic or C though
Mon graphe (11 Avril): ((Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; passe gint 3 ; ...) || (shoutbox v5 ; v5)
Calamari En ligne Membre Points: 402 Défis: 0 Message

Citer : Posté le 16/10/2022 09:47 | #


What can I say... I wrote two fully functional Basic compilers using exactly that method. Thanks for putting a name to it, I had no idea that's what it was called.
“Remember to have fun doing this, or it ain't worth it.” — Robert Alan Koeneke
“They call me the king of the spreadsheets, got 'em all printed out on my bedsheets.” — “Weird Al” Yankovic
Lephenixnoir Hors ligne Administrateur Points: 24678 Défis: 170 Message

Citer : Posté le 16/10/2022 09:50 | #


I stand corrected!
Mon graphe (11 Avril): ((Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; passe gint 3 ; ...) || (shoutbox v5 ; v5)

LienAjouter une imageAjouter une vidéoAjouter un lien vers un profilAjouter du codeCiterAjouter un spoiler(texte affichable/masquable par un clic)Ajouter une barre de progressionItaliqueGrasSoulignéAfficher du texte barréCentréJustifiéPlus petitPlus grandPlus de smileys !
Cliquez pour épingler Cliquez pour détacher Cliquez pour fermer
Alignement de l'image: Redimensionnement de l'image (en pixel):
Afficher la liste des membres
:bow: :cool: :good: :love: ^^
:omg: :fusil: :aie: :argh: :mdr:
:boulet2: :thx: :champ: :whistle: :bounce:
valider
 :)  ;)  :D  :p
 :lol:  8)  :(  :@
 0_0  :oops:  :grr:  :E
 :O  :sry:  :mmm:  :waza:
 :'(  :here:  ^^  >:)

Σ π θ ± α β γ δ Δ σ λ
Veuillez donner la réponse en chiffre
Vous devez activer le Javascript dans votre navigateur pour pouvoir valider ce formulaire.

Si vous n'avez pas volontairement désactivé cette fonctionnalité de votre navigateur, il s'agit probablement d'un bug : contactez l'équipe de Planète Casio.

Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 95 connectés | Nous contacter | Qui sommes-nous ? | Licences et remerciements

Planète Casio est un site communautaire non affilié à Casio. Toute reproduction de Planète Casio, même partielle, est interdite.
Les programmes et autres publications présentes sur Planète Casio restent la propriété de leurs auteurs et peuvent être soumis à des licences ou copyrights.
CASIO est une marque déposée par CASIO Computer Co., Ltd