Kevin Kofler (./129) :
Enfin, il restera(it?) probablement quelques tensions parce que Onur veut imposer la portabilité dans le langage (accès aux fonctions natives uniquement à travers son runtime), alors que pour ce que je compte faire, il faut pouvoir interfacer avec du code C arbitraire.

mieux que ça, le code généré par etpc pour ses instructions peut faire des appels à des fonctions implémentées en C. Donc meme pas besoin d'include au niveau d'etp, ça peut se faire à l'édition de liens, genre avec une libetp68k.a, elle même implémentée en C, assembleur, etc.

en effet, une spécification du langage (en cours quoi ) va dire que le langage n'a pas un accès explicite aux romcalls, pour s'affranchir de l'implémentation bas niveau, genre si on veut tester sur PC, on fournit une fonction Locate lig,col,text pour console, etc..
A nous de définir l'API qui fera la liaison entre les appels de fct générés par etpc et les fonctions elles mêmes, ie quelles seront nécessaires, etc...

désolé de présenter tout ça si mal, on a en effet besoin de spécifs claires.