C'est complètement arbitraire, parce que je n'ai plus de x86-32 sous la main pour tester1. Et puis, quand on a un peu goûté à l'asm x86-64, on n'a plus trop envie de se replonger dans le 32, si limité en registres :)
Toute la logique du link est strictement identique en 32 et 64 bits, "seules" les structures de données diffèrent. Il n'est pas du tout exclu que bold supporte un jour le x86-32, voire même d'autres architectures (là je m'avance peut-être un peu, encore que...).
Certaines parties on un peu été codées à la Rache® et demanderont une réorganisation pour pouvoir gérer le 32 bits facilement.
Bon, je dois aussi admettre que l'esprit de la Demo, c'est un peu de faire ce que personne n'a fait avant et les intros pour x86_64 sont rares :)
1) Comme je n'utilise pas du tout la libc, il faut faire appel aux syscalls, qui ne sont pas couverts par la couche de compatibilité 32 bits offerte par Linux. Cela dit, le runtime de bold n'en utilise qu'un : SYS_exit.
[^] # Re: .
Posté par Amand Tihon (site web personnel) . En réponse au journal Bold: un linker particulier. Évalué à 10.
Toute la logique du link est strictement identique en 32 et 64 bits, "seules" les structures de données diffèrent. Il n'est pas du tout exclu que bold supporte un jour le x86-32, voire même d'autres architectures (là je m'avance peut-être un peu, encore que...).
Certaines parties on un peu été codées à la Rache® et demanderont une réorganisation pour pouvoir gérer le 32 bits facilement.
Bon, je dois aussi admettre que l'esprit de la Demo, c'est un peu de faire ce que personne n'a fait avant et les intros pour x86_64 sont rares :)
1) Comme je n'utilise pas du tout la libc, il faut faire appel aux syscalls, qui ne sont pas couverts par la couche de compatibilité 32 bits offerte par Linux. Cela dit, le runtime de bold n'en utilise qu'un : SYS_exit.