Reprise du message précédent :
Tu peux expliquers plus en détail ta dernière phrase ca m'interesse.
Merci

C'est souvent un problème d'alignement : sur SPARC, quand tu veux accéder à une donnée codée sur n octets, son adresse en mémoire doit être alignée sur ce même nombre d'octets. Sur x86, ce n'est pas obligatoire, bien qu'il y'ait une perte de performances si elle ne l'est pas.

Petit exemple concret :

Je ne saisis pas ce que tu dis. Il me semblait que malloc et free, c'etait toujours implemente dans la libc. Me trompe-je?

intéressant.
 
Merci pour l'exemple détaillé deather2

Un exemple bête que j'ai vu récemment, sur un gros projet opensource (dont je tairais le nom tellement c'est une daube sans nom): un exemple de cast sur des pointeurs pas alignés (marche sur x86 32bits, mais pas sur du sparc 64, j'expliquerai pourquoi):
 
L'antithèse même des boulets qui prétendent faire de l'opensource, mais qui au final se retrouve à faire des progs qui vont tourner sur du nunux sur de l'i386. Effet de mode peut être
 

 
seg->content est un char * (pointeur d'octets).
 
Or uint32_t, c'est 4 octets (non signés). "(uint32_t *)(seg->content + 1)": cast d'une adresse de chaine d'octets, vers un uint32. L'adresse qui est pointée n'étant pas alignée (google pour comprendre la signification) pour un type uint32 (c'est un pointeur de char * incrémenté de 1), lors du déréférencement:
- sous x86, ca ne te dira rien. La magie du x86.
- sous sparc 64, tu vas manger un bon petit SIGBUS.
 
Solution:
- #ifdef, avec les appels qui vont bien pour l'architecture donnée
- utiliser une fonction de copie du contenu, genre memcpy:
 

 
Ce genre de connerie, c'est pas ce qui manque dans de l'opensource, surtout pour des projets SSII/SSLL qui ne jurent que par nunux sur du dell.
 
Faut savoir ce que l'on fait dès que l'on manipule des adresses. D'une certaine manière, les java like n'ont pas cet inconvénient. En contrepartie, tu payes ca sur le runtime. A un moment ou a un autre, il faut bien gérer des références, donc c'est soit en frontend soit en backend. Il faut garder à l'esprit que plus il y aura de couches, plus ca sera lent et difficile à maitriser de bout en bout. C'est la mode du moment.

 
Les fonctions oui, mais elles font ensuite des appels systèmes brk(2)/sbrk(2) pour gérer les allocations. Donc un changement de contexte.
 
Si tu regardes un malloc.c typique, tu verras qu'à aucun moment, la libc ne garde l'information elle même sur l'allocation qu'elle fait. Du coup, si tu veux savoir ce qui a été exactement alloué, il faut le demander, et ca passera forcément par un appel.
 
C'est différent sur des opérations I/O, qui sont toujours couteuses en temps d'execution. C'est pour ca qu'elles sont (presque) toute bufferisées.

perso, c'est les archis incapables de réaligner les accès, au moins sur l'espace caché, que je trouve nul.
 
ton sparc 64 il a un cache, il y a des lignes de cache ? si oui tout accès mémoire sur un espace caché doit déclencher une transaction par une ligne de cache.
 
que ça déclenche un bus trap error / sigbus sur des espaces non cachés, des espaces de périphériques soit.....
 
mais bon au moins sur la mémoire système cachée, c'est vilain de pas avoir de découplage entre l'alignement d'adressage et la largeur des bus.
 
que les performances se dégradent avec le non alignement sur la largeur des bus ou non alignement avec la taille des lignes de cache, soit, mais que ça déclenche un exception, on se croirait dans les années 80.

+1

Ah ouais, dire que l'archi sparc c'est de la merde, c'est très très fort. Merci de m'avoir fait rire

C'est surtout vilain de la part du programmeur d'écrire du code dégueux. Le cast n'est pas là pour ca.

Ouais. Tiens d'ailleurs, je me demande pourquoi la MMU doit avertir sur les erreurs de segmentation, au lieu d'écraser le contenu de la mémoire. On se croirait dans les années 70.

Puis tant qu'a faire, "aussi", pourquoi se faire chier à faire tourner des process en userland, c'est tellement mieux de faire ca en mode kernel. Pourquoi se faire chier avec des rings, je me le demande aussi.  

Edit: ah oui, et tant qu'a faire, tolérons donc aussi les structs mal foutues qui gaspillent inutilement de l'espace rien que pour aligner leur contenu. Pourquoi on se ferait chier avec ca.

 
si tu fais une archi qui bus trap sur les accès non alignés, le jour où le sous-système mémoire change, c'est tout le parc applicatif qu'il faut changer.
 
un cpu 16/32/64 bits tu peux le coupler avec un sous-système mémoire 8/16/32/64/256/1024 bits.
 
un fabricant qui conserve des restrictions d'alignement (dans le sens exception matérielle) dans certaines situations s'expose a un verrouillage technologique de son sous-système mémoire.
 
encore sur les drivers qui font des accès a des espaces de registres ou de mémoire sur des péripéhriques, je dis pas (ou au niveau de micro-code ou de firmware pérphérique), mais sur la mémoire centrale, cacheable, ça a moyennement du sens, où plustôt c'est de l'économie de bout de chandelles.
 
j'ai jamais dit que l'archi sparc c'était de la merde, je DIS que bus trapper sur un espace cacheable est dangeureux au niveau évolutivité technologique. (car une fois que toutes les applis ont été écrites pour se conformer a une restriction hardware, la restriction hardware deviens une feature d'architecture pour toute une famille de processeur)

C'est là ou je ne suis pas d'accord. La restriction hardware, justement, c'est de tolérer ce genre de choses. Le mieux étant l'ennemi du bien. Tu te fermes complètement le monde de l'embarqué avec des idées comme celle la. Et ca n'est pas l'apanage de l'archi sparc, arm aussi va souffrir.

Une appli codée proprement doit se soucier des problèmes d'alignement, et ne pas laisser ca salement à l'architecture qui est derrière. C'est justement comme cela que l'on néglige totalement la portabilité, et qu'on se retrouve avec une appli qui va tourner sous x86 et pas ailleurs. Quand on manipule des pointeurs/adresses, on fait ca proprement. Sinon on fait pas, et on se tourne sur d'autres environnements/langages qui évitent ce genre de souci.

Maintenant, tu noteras qu'avoir des alignements corrects te permet justement de faire abstraction des problèmes d'adressage, que tu passes de 16 bits au 32, puis 64, 128, ou changer d'architecture. Niveau propreté du code, il n'y a pas besoin de se faire des nœuds infernaux au cerveau pour y arriver.

qu'est-ce qui est le plus crade d'un point de vue développeur ?
 
- faire une indirection sur un pointeur de type
 
- composer un type à la main à partir de plusieurs indirections de "mots" mémoire (variant dans le temps) avec des shifts et des ou ?
 
allons...
 
dans le cas des accès non alignés sur des espaces cachés, la logique d'extraction d'un mot large d'une ligne de cache peut être triviale (enfin je dis ça ptet pas ).
 
que ça bus trap sur autre chose que la mémoire cachée je veux bien. (après faut voir la stratégie en écriture, si on prefetch la ligne et ce sera du coup fait en write-back)
 
le bus trap c'était bien sur les 68000 sans cache, mais au bout d'un moment ça saoule.

Utiliser du #ifdef et du memcpy en cas de risque.

Ca devrait arriver extrêmement rarement. Je verrais ca surtout dans les bdd (qui sont au point à ce niveau, postgres ne fait pas du cast à tout va), et les piles réseaux (flux de données qu'on passe son temps à encapsuler/décapsuler).

Ouais, on en dira pas tant. En attendant, si aujourd'hui, on doit s'amuser avec des couches de compat binaire 32bits sur du 64bits, c'est bien qu'il y a du code crade la dedans. Je compte même plus les applis présentement "open source" et qui ne sont pas 64 bits safe.

En ce qui me concerne, pour ce que j'ai vu, porter netbsd + userland sur amd64 s'est fait en 2 semaines montre en main. La par exemple, j'ai cyrus imapd en cours d'installation dans un de nos labos, ben cette "chose" foire majestueusement en environnement 64bits. Bravo.

Ca saoule, et c'est pour une bonne raison. En attendant je maintiens ce que je dis, si on dégage tout ce qu'il faut sous prétexte que ca emmerde un progueux qui fait sa tambouille à la va vite, ben c'est simple, soit il code pour x86 et il assume les critiques qui viendront avec, soit il change de langage pour un plus haut niveau qui ne manipule pas d'adresse, ou il se tourne vers les webeuries 2.0.

Hé, on critique pas les webeuries 2.0, Rails c'est très bien
 
(mais c'est en vous lisant que je remarque combien on ne fait que aborder le C à l'école et que finalement j'suis content de pas en avoir plus mangé que ça )

c'est de l'archi c'est pas du C (on est HS)

 
moi aussi je me maintiens ce que je dis: les bus trap sur les espaces cachés, ça pue du cul

Certes mais j'imagine qu'aujourd'hui, si tu vas utiliser du C pour un projet de ce genre c'est que tu vas bosser en assez bas niveau et que donc t'as plutôt intéret à savoir sur quelle plateforme tu travailles non ? J'ai fait un peu de C sur microcontrolleur PIC, on avait en permanence la datasheet de Microship sur les genoux Je veux dire, aujourd'hui avec JAVA, C# et autres langages plus haut niveau ( Python, Ruby etc... ) y a t-il encore une raison d'utiliser du C pour des "gros projets" (sauf quand on veut travailler très bas niveau bien sur)

Tout ce qui est prog système, ou avec des programmes très massifs en temps de calcul ou en ressources (bdd, traitements multimédias), on y coupe pas.

Pour le reste, tout ce qui est client (webeuries, applis clientes...), intérêt nul.

Chaque langage a un domaine particulier d'applications. Suffit de voir que fortran, cobol, ada... sont toujours présents. C'en est même devenu mauvais, les compétences sont rares, les besoins bien présents, du coup les tarifs très élevés.

Encore une fois, le C "de base" ne requiert pas un niveau démentiel. A moins de se lancer dans de la prog pointue, tu ne verras jamais ce genre d'erreurs. Tout fonctionne autour de toolkits aujourd'hui.

Merci pour tous ces détails c'est super intéressant