Portage de SBCL vers la Nintendo Switch

État actuel

• Le runtime et le compilateur SBCL ont désormais été portés pour fonctionner sur la Nintendo Switch
• L’interface avec les bibliothèques partagées est également possible, et diverses bibliothèques de portabilité entre systèmes d’exploitation ont aussi été portées
• Cependant, un crash se produit lorsque le ramasse-miettes de SBCL se met en marche
• Sortie audio indisponible, problème avec le mécanisme de callback C
• Des problèmes de performances sont également à prévoir

Aperçu

• La Switch utilise une puce ARM64 Cortex-A57 et 4 Go de RAM, et fonctionne sur un système d’exploitation à micro-noyau propriétaire
• SBCL dispose déjà d’un port ARM64 Linux, ce qui règle les problèmes de génération de code
• La Switch est la seule console à prendre en charge la bibliothèque graphique OpenGL, ce qui facilite le portage de la bibliothèque graphique de Trial
• Pour commencer le développement, un kit de développement a été acheté auprès de Nintendo of Europe et le SDK a été installé

Processus de build de SBCL

1. build-config : collecte les options de configuration de build et les affiche dans un format lisible
2. make-host-1 : construit un compilateur croisé avec le compilateur Lisp hôte
3. make-target-1 : génère le runtime C avec le compilateur C cible
4. make-host-2 : construit le système Lisp cible
5. make-target-2 : charge le cold core dans le runtime cible et termine le bootstrap

Build pour la Switch

• La Switch n’est pas un environnement PC, et ne dispose ni de shell, ni de ligne de commande, ni de compilateur
• Il est impossible de créer des pages exécutables, donc la compilation à l’exécution n’est pas possible
• La majeure partie du code est indépendante de la plateforme et peut être compilée pour ARM64
• fasteval est utilisé pour remplacer la compilation à l’exécution

Ramasse-miettes

• Le GC standard de SBCL est "gencgc", un ramasse-miettes générationnel
• Des problèmes de déplacement d’objets surviennent dans un environnement multithread
• Sur les systèmes Unix, les threads sont mis en pause à l’aide d’un mécanisme de signaux, mais cela est impossible sur la Switch
• Une stratégie de "safepoints" est utilisée pour que les threads se mettent eux-mêmes en pause

Travaux à venir

• Figer autant que possible CLOS et explorer la précompilation
• Des optimisations supplémentaires sont nécessaires en raison du processeur peu performant de la Switch
• Le ramasse-miettes doit être rendu entièrement fonctionnel
• Le problème des callbacks C doit être résolu

Conclusion

• En raison d’un NDA, il n’est pas possible de rendre public tout le travail, mais ce qui peut l’être est en cours de publication
• Un soutien est demandé via Patreon, GitHub et Ko-Fi

Résumé de GN⁺

• Cet article traite du processus et des défis liés au portage du runtime Common Lisp vers la Nintendo Switch
• De nombreuses difficultés techniques apparaissent en raison du système d’exploitation propriétaire de la Switch et des contraintes matérielles
• Les principaux défis concernent le ramasse-miettes et le multithreading, ainsi que la compilation à l’exécution
• Ce projet fournit des informations utiles aux développeurs Common Lisp et aux développeurs de jeux

[GN⁺]

Avis sur Hacker News

• Pendant quelques semaines, j’ai testé le développement de jeux en Common Lisp avec Trial, et l’expérience a été très agréable

  • Le gros avantage est qu’on peut modifier presque toutes les parties pendant que le jeu tourne
  • J’espère que ce portage réussira

• SBCL est une excellente implémentation du langage, et j’avais envie de faire du développement CL pour une « vraie » console de jeu

  • J’ai été surpris d’apprendre que Shinmera travaillait là-dessus
  • La brève fois où j’ai regardé l’intérieur de SBCL, ça m’a intimidé, donc bravo à lui
  • Je me demande si SBCL (+ threading/SDL2) fonctionne sur Raspberry Pi

• Merci à l’auteur d’avoir écrit un article intéressant et détaillé

  • Ce niveau de détail n’est généralement rendu public qu’une fois la durée de vie de la console terminée
  • Chaque fois que je lis ce genre de travail en profondeur, je jalouse le logiciel monotone que j’utilise toute la journée

• Je me demande pourquoi le SDK officiel a été utilisé

  • Peut-être que Nintendo n’autorise pas la publication officielle de jeux créés avec un SDK tiers

• J’ai acheté Kandria

  • Je ne joue pas beaucoup, mais élargir les frontières du monde Lisp comme le fait Shinmera mérite d’être soutenu

• SBCL - « Steel Bank Common Lisp »

  • SBCL est un compilateur Common Lisp haute performance, open source/logiciel libre
  • En plus d’un compilateur et d’un système d’exécution pour ANSI Common Lisp, il fournit de nombreuses extensions, comme un débogueur, un profileur statistique, des outils de couverture de code, etc.

• Son travail est impressionnant

  • Pour quelqu’un comme moi qui aime utiliser CL un peu partout, cela me procure une grande joie

• J’aimerais que Nintendo et Sony soutiennent ce genre d’efforts

  • Lancer des programmes comme GitHub Accelerator serait une autre façon de créer des jeux (IP) pour les consoles

• Un peu hors sujet, mais porter Yuzu sur Nintendo Switch serait incroyable

• C’est exactement pour ce genre de choses que je viens sur HN

  • Bravo à l’OP et à son collègue
  • Ce serait une vraie bénédiction si Nintendo pouvait être un peu plus ouvert à propos de son système