bearbecue (./23) :
genre des archis tordues ou les pointeurs data/code ne sont pas comparables / dans le meme espace d'adressage ?

oh oui plein, surtout en embarqué

architecture harvard ça s'appelle, avec ça tu peux foutre 64k de code ET 64k de data sur un bus 16 bits (datas de 8 bits évidemment).

c'est pas si tordu, c'est même assez commun. Intel 8051, Microchip PIC, y'en a d'autres probablement (les atmega je sais pas). tout ce qui est un peu "industriel" en fait.
du coup pas d'exec en RAM.

(a coté de ça le Z80 et le 68HC11 ont des espaces von neumann normaux unifiés, ils sont plus destinés à être des microprocesseurs que des microcontrôleurs.)

sur ces deux controleurs, avec sdcc, par exemple, on a des pointeurs __code de 3 octets (20 bits) qui peuvent pas pointer dans les __data, et des pointeurs __data qui font 2 octets et peuvent pas pointer vers du code.

et puis t'as des pointeurs génériques de 24 bits dans lesquels les 4 MSbits disent le type du pointeur, et puis chaque dereference est remplacé par un call vers _gptrget(adr) ou _gptrput(adr,val) , deux fonctions qui font ce qu'elles disent - et génèrent du code de merde si tu sais pas ce que tu fais ^^

du coup des fois t'as des merdes d'incompatibilités entre les tableaux et les pointeurs:
const unsigned char[] values = {1,2,3,4};
unsigned char *ptr = values; //FAIL : const implique __code mais ptr est générique!

et ils sont en train de généraliser le truc pour avoir le support du banking transparent et des zones de mem non mappées en mémoire style carte SD, avec des types de pointeurs pour lesquels tu dois filer explicitement les fonctions get et put #trimalade#