search

stevenvar / OMicroB

An OCaml generic virtual machine for microcontrollers
Other
138 stars 23 forks source link

Less ifdef #18

Closed Vertmo closed 5 years ago

Vertmo commented 5 years ago

I'm in the process of getting rid of the #ifdef __PC__, #ifdef __AVR__, ... scattered in the byterun. It seems to be going well for now. The architecture specific functions and macros are now housed in the files src/byterun/{simu,avr}/arch-specific.{c,h}

Vertmo commented 5 years ago

I've run a set of the tests, and everything seems to work correctly :)

lambdaz1739 commented 5 years ago

Bonjour,

On avait parlé de créer une arborescence : architectures/modeles (arch/models ou targets) où l’on pourrait trouver avrs suivi de arduboy ou arduino_uno,

là je ne vois que avrs à la racine.

j’arrive à compiler mais j’ai ensuite des erreurs en faisant make tests : clang: error: unknown argument: '-mno-skip-bug' et des warnings

c’est sur mac avec clang

à bientôt. Emmanuel...

Le 3 sept. 2019 à 16:17, Steven Varoumas notifications@github.com a écrit :

Merged #18 https://github.com/stevenvar/OMicroB/pull/18 into generic.

— You are receiving this because your review was requested. Reply to this email directly, view it on GitHub https://github.com/stevenvar/OMicroB/pull/18?email_source=notifications&email_token=AFNA24EPDWAXM2BM3HHXM4TQHZWXRA5CNFSM4ITE3EY2YY3PNVWWK3TUL52HS4DFWZEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW5KTDN5WW2ZLOORPWSZGOTMY722I#event-2603744617, or mute the thread https://github.com/notifications/unsubscribe-auth/AFNA24APRNB5D7CY5NBRVW3QHZWXRANCNFSM4ITE3EYQ.

Vertmo commented 5 years ago

Bonjour, En fait tout ce qui est dans arch-specific.c est commun à tous les modèles d'AVRs. Pour le moment comme je n'ai pas réintégré les changements permettant de passer d'un Avr à l'autre, je n'ai pas encore fait la partie "choix de modèle" (j'attends le consensus général sur #19 pour savoir quelle version de avr.ml et avr.mli garder lors d'un gros rebase). On peut effectivement penser à une vraie arborescence, avec un fichier registers.c dans chaque sous dossier décrivant la correspondance numéro de registres/addresse du registre. Pour le Caml je pense qu'il est plus simple d'avoir plusieurs sous modules avec signature commune dans le même module (i.e. dans le même fichier .ml. Pour ce qui est de clang je ne saurai pas vraiment dire, il me semble que tout le projet est principalement prévu pour utiliser gcc (je n'ai jamais utilisé clang personnellement donc je ne saurais pas trop vous aider)

stevenvar commented 5 years ago

J'ai déplacé le dossier avrs dans un autre dossier targets qui contient une ébauche d'implémentation des fonctions spécifiques au matériel (sur l'exemple de ce qu'a fait @Vertmo ). La hiérarchie des répertoires me semble mieux comme ça.

Normalement ça continue de compiler sans problème pour AVR.

Il faudra néanmoins adapter au maximum les configure et Makefile pour compiler correctement selon la cible (par exemple : utiliser arm-none-eabi-gcc versus avr-gcc + tout ce qui a trait au link)

Concernant la compilation sur mac je n'ai pas de souci de mon côté concernant clang, mais un problème d'OCaml :

Error: This variant expression is expected to have type Avr.level The constructor true does not belong to type Avr.level

Ça me semble suffisamment explicite ;)

Vertmo commented 5 years ago

L'erreur en rapport avec Avr.level se produit quand tu compiles quoi ? Un test en particulier. Effectivement l'organisation semble assez propre, mais du coup on avait pas prévu de pouvoir passer d'un Avr à l'autre dynamiquement ? Comment prends on cela en compte dans cette organisation ?