sorte de self modifying code en C - Page 4

Et ça a aussi des applications pour des trucs comme la virgule fixe.

Kevin Kofler :
Le type de données naturel pour des Sprite64 est long long [64].

Et pour les Sprite48, c'est mediumly long [48] ?

et le Sprite29 ?

./73: En C++, le preprocesseur, c'est mal

Ca dépend ce que t'en fais. Je vois mal comment tu peux faire de la compilation conditionnelle sans.
Notamment pour placer des extern "C", et éventuellement des trucs comme
#ifdef __cplusplus
using namespace std;
#endif
Bon, ok tu me diras je triche, parce que si je fais ça c'est que j'ai aussi du C qui traine pas loin.
Mais il me reste le debug (__LINE__ & Cie), et la compilation conditionnelle à la autoconf.

Après je suis d'accord que si c'est pour autre chose, c'est mal.

Pollux :
Raison de plus pour les laisser à 64 bits.

A oui ? Et lorsque les long font 64 bits deja ?
Ca ne sert a rien d'avoir les long long a 64 bits...

[cite
Mais pourquoi appeler ça "long long" et pas "__int128" ? A moins que la portabilité n'entre pas du tout en ligne de compte, tous les progs actuels utilisant des "long long" vont prendre 2x plus de RAM et être 2x plus lents, sans rien gagner
[/cite]
Un programme portable ne fait pas la supposition que long long = 64 bits...
Le but est d'avoir des entiers allant jusqu'a 2^128 !!!! Tu es vraiment bouche.
Et question portabilite tu peux etre sur que si une architecture survient et qu'elle a long long = 128 bits, ben la taille des long long ne sera pas le truc le plus dur question portabilite.

Moi non plus. Pkoi changer la taille des long long actuels alors qu'il n'y a aucune bonne raison de les faire passer à 128 bits ?

On se demande deja pkoi ils font 64 bits alors que ca sert a rien sur une architecture 32 bits...

A part le cas où les pointeurs passeraient à 128 bits et où on aurait donc besoin d'un size_t de 128 bits et où ce serait donc envisageable que long long soit au moins un size_t (même si c pas obligatoire, hein), ou encore le cas où l'architecture du compilo serait extrêmement rigide et ne supporterait que 5 types entiers différents, je ne vois vraiment pas ce qui pourrait pousser à une telle décision.

Mais dans ce cas, ca serait plutot long qui passerait en 128 bits, mon cher
Les long long feront alors 256 bits.
Et de toute facon, les ptr ne passeront pas en 128 bits avant ~ 30 ans. (Et encore).

>Après je suis d'accord que si c'est pour autre chose, c'est mal.
Si vous voyez comment je me sers du preprocesseur.

PpHd
:

Pollux :
Raison de plus pour les laisser à 64 bits.

A oui ? Et lorsque les long font 64 bits deja ? Ca ne sert a rien d'avoir les long long a 64 bits...

Si, à ce que les progs existants qui utilisent des long long ne bouffent pas 2x plus de mémoire en étant 2x plus lents... Tu crois que le 'long' est passé à 64 bits qd les 'int' sont passés à 32 bits ?

Mais pourquoi appeler ça "long long" et pas "__int128" ? A moins que la portabilité n'entre pas du tout en ligne de compte, tous les progs actuels utilisant des "long long" vont prendre 2x plus de RAM et être 2x plus lents, sans rien gagner

Un programme portable ne fait pas la supposition que long long = 64 bits...

Qui t'a parlé de ça ? Justement, comme précisément il ne peut pas exploiter de caractéristique des long long supérieure à 64 bits, il ne va utiliser des long long que pour des calculs 64 bits, calculs qui sont significativement plus longs à faire en 128 bits !!!

Le but est d'avoir des entiers allant jusqu'a 2^128 !!!!

int128_t ?

Tu es vraiment bouche.

Non. Je n'ai pas dit à un seul moment qu'il fallait supposer que sizeof(long long)=8, c'est toi qui l'as imaginé... Si effectivement les calculs 128 bits étaient miraculeusement 3x plus rapide que les 64 bits et/ou que ça permettait un gain substantiel sur la taille des opcodes / l'architecture du proc / l'accès aux données, alors ce serait une bonne solution.
Mais je n'y crois pas, _justement_ parce qu'on aura besoin de gros entiers seulement pour des trucs spéciaux, et que donc on aura certainement pas des pointeurs 128 bits, et que donc l'architecture reposera avant tout sur des entiers <= 64 bits, et que donc les entiers 64 bits ne seront pas un pb au niveau architecture.

Et question portabilite tu peux etre sur que si une architecture survient et qu'elle a long long = 128 bits, ben la taille des long long ne sera pas le truc le plus dur question portabilite.

J'ai dit ça ?

Moi non plus. Pkoi changer la taille des long long actuels alors qu'il n'y a aucune bonne raison de les faire passer à 128 bits ?

On se demande deja pkoi ils font 64 bits alors que ca sert a rien sur une architecture 32 bits...

Parce qu'il n'y avait pas de type standard dont la taille était garantie >= 64 bits. Donc ils l'ont rajouté, ça s'appelle un "long long". Aujourd'hui, il n'y a pas de type standard de taille >= 128 bits garantie. Il faut créer un nouveau type si on en a besoin, pas essayer de hacker le système existant...

A part le cas où les pointeurs passeraient à 128 bits et où on aurait donc besoin d'un size_t de 128 bits et où ce serait donc envisageable que long long soit au moins un size_t (même si c pas obligatoire, hein), ou encore le cas où l'architecture du compilo serait extrêmement rigide et ne supporterait que 5 types entiers différents, je ne vois vraiment pas ce qui pourrait pousser à une telle décision.

Mais dans ce cas, ca serait plutot long qui passerait en 128 bits, mon cher
Les long long feront alors 256 bits. Et de toute facon, les ptr ne passeront pas en 128 bits avant ~ 30 ans. (Et encore).

Si tu lis bien mon post, tu constates que le coup des pointeurs à 128 bits n'est qu'une idée farfelue qui est là pour dire que je ne vois _vraiment pas_ ce qu'on pourrait trouver comme bonne raison de faire ça. Ma phrase n'a pas du tout pour but d'examiner les propriétés d'une archi 128 bits.

Tu commences a me donner mal a la tete, deja si tot ce matin, alors que j'ai eu un bonne nuit de sommeil. Tu es doue tu sais ?
Bon reprennons a 0.

Je ne dis pas que les long long doivent imperativement faire 128 bits, je dis juste que ca serait bien.
Les types definis par stdint_t sont en fait des typedef des types existant.
Pour definir int128_t, il faudrait definir un type natif au compilo compatible.
Si on reflechit 2s, on se rend compte que le seul mapping possible a l'heure actuelle est:
char=1, short=2, int=4, long=8, long long=16.
Dans ce cas de mapping, le standard peut etre parfaitement respecte par la libc.

Pkoi 128 bits ? Car l'opteron permet de travailler en 128 bits a faible cout: add/adc sub/subc, et mul 64x64 -> 128 (x4)permet de se debrouiller pour faire un type 128 bits vraiment rapide compare a ce qu'on doit faire pour l'emuler en soft.
En plus, les progs existant ne boufferont pas 2x de RAM et ne seront pas 2x+ lent. Faut etre neuneu pour le croire ou le penser. Toutes les donnees ne seront pas en long long, et je te signale que sur cette architecture, les long font deja 8 octets, et l'alignement est force a 8 octets. Tu comptes le nombre d'octets perdus a cause de cet alignement #newbies#. Le but des long long n'est pas d'etre rapide, et je te rappelle que question portabilite les long font deja 64 bits, donc tu peux faire une croix sur la portabilite de tes programmes.

Ensuite tu persistes a penser qu'un programme utilise des long long pour faire du calcul 64 bits. C'est faux. Un programme un minimum correct, utilise stdint.h et int64_t pour faire du calcul seulement 64 bits! C'est la seule maniere portable de faire du calcul 64 bits rapide. Tu as meme intfast64_t si tu preferes (Dans le cas ou faire des calculs en plus de 64 bits serait plus rapide).
On peut voir le type int comme le type d'entier primaire (alignement, vitesse optimal). Long comme l'equivalent avec les ptrs memoires. Et long long comme le type juste au dessus des possibilites de la machine. Certes c'est totalement faux, mais c'est comme ca que je vois les choses.
De toute facon, je n'ai aucun pouvoir sur ce genre de decisions.

Et je comprends pas pkoi tu dis que c'est hacker le systeme en mettant les long long sur une plate-forme 64 bits en 128 bits.
Et sur une architecture 128 bits, on aura les long long 64 bits, et les long 128 bits, c'est ca ? #couillon#

Je me demande a quel point tu me prends pour un con, et j'espere avoir ete assez mechant dans mon post sans depasser les regles de bonnes conduites.

PpHd :
Je ne dis pas que les long long doivent imperativement faire 128 bits, je dis juste que ca serait bien.
Les types definis par stdint_t sont en fait des typedef des types existant. Pour definir int128_t, il faudrait definir un type natif au compilo compatible.

Types existants != types ANSI standard. C'est de toute façon non-standard pour le header de supposer qu'il y a un type entier 128 bits, donc le header sera forcément dépendant du compilo. A partir de là, le choix d'un type spécifique au compilo est préférable.

Si on reflechit 2s, on se rend compte que le seul mapping possible a l'heure actuelle est: char=1, short=2, int=4, long=8, long long=16.

Oui, mais rien n'oblige à prendre un mapping "type ANSI". Surtout qu'en plus on sera bien emmerdé le jour où on voudra faire du 256 bits...

Dans ce cas de mapping, le standard peut etre parfaitement respecte par la libc.

Je vois pas comment définir un int128_t de manière portable, moi (en C, pas en C++)

Pkoi 128 bits ? Car l'opteron permet de travailler en 128 bits a faible cout: add/adc sub/subc, et mul 64x64 -> 128 (x4)permet de se debrouiller pour faire un type 128 bits vraiment rapide compare a ce qu'on doit faire pour l'emuler en soft.

Je veux bien que le surcoût de calcul soit faible sur certaines archi, mais il n'empêche qu'il reste le pb de la RAM et du débit mémoire.

[/cite]En plus, les progs existant ne boufferont pas 2x de RAM et ne seront pas 2x+ lent. Faut etre neuneu pour le croire ou le penser.[/cite]
Alors je suis neuneu. Si tu veux un type 128 bits sur un Opteron, ben ça prend 2x plus de place, je suis désolé. Pareil pour la bande passante.

Toutes les donnees ne seront pas en long long, et je te signale que sur cette architecture, les long font deja 8 octets, et l'alignement est force a 8 octets. Tu comptes le nombre d'octets perdus a cause de cet alignement #newbies#

Ce qui est précisément le but de la fin de mon post précédent : comme on a des chances très fortes de penser que les pointeurs ne dépasseront pas 64 bits avant la fin des temps ou presque (et donc size_t, et donc tout entier représentant un nombre d' "objets"), on a des chances très fortes de penser que si une architecture se mettait à exiger un alignement de 128 bits, et bien la moitié de la RAM serait remplie de padding... (sauf éventuellement les instructions, si l'alignement n'est pas nécessaire pour elle -- mais on a pleins de raisons de croire qu'à terme, 95% de la RAM sera des données et pas du code) Ca serait un désastre au niveau performance : p-ê qu'on pourrait lire les données 2x+ vite (en fait un peu moins), mais en même tps la moitié des données serait inutile.

Donc mon parallèle avec la taille des pointeurs est bien pertinent : on a toutes les raisons du monde de croire que le type 64 bits sera plus efficace au niveau taille que n'importe quel type plus gros.

Le but des long long n'est pas d'etre rapide, et je te rappelle que question portabilite les long font deja 64 bits, donc tu peux faire une croix sur la portabilite de tes programmes.

Bah, c'est au moins compatible C99.

Ensuite tu persistes a penser qu'un programme utilise des long long pour faire du calcul 64 bits. C'est faux. Un programme un minimum correct, utilise stdint.h et int64_t pour faire du calcul seulement 64 bits! C'est la seule maniere portable de faire du calcul 64 bits rapide. Tu as meme intfast64_t si tu preferes (Dans le cas ou faire des calculs en plus de 64 bits serait plus rapide).

Je ne connaissais pas intfast64_t, qui correspond effectivement à peu près à mon idée du "long long". Mais je ne vois alors plus l'intérêt du "long long" ? (surtout si, pour réaliser ton idée, la définition de intfast128_t marcherait très bien aussi)

On peut voir le type int comme le type d'entier primaire (alignement, vitesse optimal). Long comme l'equivalent avec les ptrs memoires. Et long long comme le type juste au dessus des possibilites de la machine. Certes c'est totalement faux, mais c'est comme ca que je vois les choses.

Si on suit ton raisonnement il faut que long long fasse 256 bits sur opteron ?
En tout cas comme je l'ai dit ce raisonnement ne pourra certainement pas se prolonger à l'infini, puisqu'on a que 5 types de base... Et prendre des définitions qui varient autant selon les plateformes, ça me paraît un peu bizarre...

En plus je crois que certaines architectures 64bits font du 16/32/32/64 avec des ptr 64 bits, donc ça ne colle pas trop avec ton idée du long long... (ou alors on n'aurait pas "de base" un type entier 64 bits)

De toute facon, je n'ai aucun pouvoir sur ce genre de decisions.

Moi non plus, rassure-toi ^^

Et je comprends pas pkoi tu dis que c'est hacker le systeme en mettant les long long sur une plate-forme 64 bits en 128 bits.

Parce que si un prog utilise effectivement les 64 bits de poids fort de ton long long 128 bits, il ne sera pas portable. Il vaudrait mieux déclarer clairement et de manière portable (et donc de préférence pas avec des switch de compilo) quels sont les besoins du prog, et intfast128_t m'a l'air bien plus sain... En plus l'erreur a l'avantage de se produire à la compilation et pas à l'exécution en cas de non-support ^^

Et sur une architecture 128 bits, on aura les long long 64 bits, et les long 128 bits, c'est ca ? #couillon#

Non, il faudrait avoir des long long 128 bits... (mais je pense que tu t'en doutais )

Je me demande a quel point tu me prends pour un con, et j'espere avoir ete assez mechant dans mon post sans depasser les regles de bonnes conduites.

Mais non, j'étais pas méchant

>Types existants != types ANSI standard. C'est de toute façon non-standard pour le header de supposer qu'il y a un type entier 128 bits,
>donc le header sera forcément dépendant du compilo. A partir de là, le choix d'un type spécifique au compilo est préférable.
>Oui, mais rien n'oblige à prendre un mapping "type ANSI". Surtout qu'en plus on sera bien emmerdé le jour où on voudra faire du 256 bits...
1. ANSI est une norme americaine.
2. Elle correspond a la norme ISO C 89.
3. Cette norme ne possede pas de type "long long".
4. Le header definissant int128_t est FORCEMENT dependant du systeme/compilo ! C'est evident!
5. Mais stdint.h definit ce qu'il faut pour toi, donc tu n'as pas a definir ton type toi meme.
6. Evidement tu devras attendre la revision du standard possedant int128_t.
7. Sauf que intmax_t peut tres bien etre egal a 128 bits (ou long long), sans enfeindre le standard.

>Je veux bien que le surcoût de calcul soit faible sur certaines archi, mais il n'empêche qu'il reste le pb de la RAM et du débit mémoire.
Mais si on a besoin de calculer en 128 bits, le pb de la RAM et du debit memoire resteront, meme si long long = 8.

>Alors je suis neuneu. Si tu veux un type 128 bits sur un Opteron, ben ça prend 2x plus de place, je suis désolé. Pareil pour la bande passante.
Parce que tu penses que tous les types utilises seront des long long ?
Parce que les opcodes des instructions sont codes avec des long long ?

>Ca serait un désastre au niveau performance : p-ê qu'on pourrait lire les données 2x+ vite (en fait un peu moins), mais en même tps la moitié des données serait inutile.
On disait la meme chose au passage du 16 au 32 bits, et du 32 au 64 bits...

>Donc mon parallèle avec la taille des pointeurs est bien pertinent : on a toutes les raisons du monde de croire que le type 64 bits sera plus efficace au niveau taille que n'importe quel type plus gros.
C'est bien d'enoncer des evidences, mais ca ne fait pas avancer le debat... que dis-je ? Le double-monologue.

>Je ne connaissais pas intfast64_t, qui correspond effectivement à peu près à mon idée du "long long". Mais je ne vois alors plus l'intérêt du "long long" ?
On se calme.
intfast64_t est definie (conditionnellement) par la libc en fonction des types supportes par ton compilateur.
"long long" est un type definie par GCC, contrairement a intmax_t et co qui sont definies par la libc.

> Si on suit ton raisonnement il faut que long long fasse 256 bits sur opteron ?
Nan, 128 bits.

>En tout cas comme je l'ai dit ce raisonnement ne pourra certainement pas se prolonger à l'infini, puisqu'on a que 5 types de base...
Non bien sur.

>Et prendre des définitions qui varient autant selon les plateformes, ça me paraît un peu bizarre...
C'est pour ca que stdint.h a ete cree.

>En plus je crois que certaines architectures 64bits font du 16/32/32/64 avec des ptr 64 bits, donc ça ne colle pas trop avec ton idée du long long... (ou alors on n'aurait pas "de base" un type entier 64 bits)
Lesquelles ? C'est pas des alphas, pas des ia64, pas des amd64, pas des sparck64 (leger doute pour sparck64). Donc ?

>Parce que si un prog utilise effectivement les 64 bits de poids fort de ton long long 128 bits, il ne sera pas portable.
Parce qu'un programme utilisant les 16 bits de poids fort d'un int est portable ?
Le but des types d'un compilo n'est pas d'etre portable. stdint.h existe !

PpHd :
>Types existants != types ANSI standard. C'est de toute façon non-standard pour le header de supposer qu'il y a un type entier 128 bits,
>donc le header sera forcément dépendant du compilo. A partir de là, le choix d'un type spécifique au compilo est préférable.
>Oui, mais rien n'oblige à prendre un mapping "type ANSI". Surtout qu'en plus on sera bien emmerdé le jour où on voudra faire du 256 bits...
1. ANSI est une norme americaine. 2. Elle correspond a la norme ISO C 89.

s/ANSI/ISO/ ...

3. Cette norme ne possede pas de type "long long".

Je voulais parler de (ISO) C99. Si on se restreint au C89, c'est certain que la définition de "long long" n'a aucune incidence puisque ça n'existe pas

4. Le header definissant int128_t est FORCEMENT dependant du systeme/compilo ! C'est evident!

Oui, donc à partir de là un type spécifique au compilo ne pose pas de pb.

5. Mais stdint.h definit ce qu'il faut pour toi, donc tu n'as pas a definir ton type toi meme.
6. Evidement tu devras attendre la revision du standard possedant int128_t. 7. Sauf que intmax_t peut tres bien etre egal a 128 bits (ou long long), sans enfeindre le standard.

Mais si tu demandes que intmax_t >= 128 bits, tu enfreinds le standard. Donc autant prendre un int128_t, si ton système le propose... (si ton système ne le propose pas et qu'il a qd même des entiers 128 bits, ben effectivement le hack temporaire est de prendre intmax_t, mais c bof pour des raisons 1] de sécurité : si le code compile, il n'est pas forcément correct; 2] de rapidité : à chaque nouvelle génération de machine, ton code bouffe 2x plus de BP mémoire, donc si c le facteur limitant, ton code ne va pas s'améliorer avec le tps )

>Je veux bien que le surcoût de calcul soit faible sur certaines archi, mais il n'empêche qu'il reste le pb de la RAM et du débit mémoire. Mais si on a besoin de calculer en 128 bits, le pb de la RAM et du debit memoire resteront, meme si long long = 8.

Ah oui, absolument. Mais je te parle des trucs existants qui utilisent des long long. Si tu écris un programme "from scratch" et que tu es prêt à ce qu'il ne marche que sur ta plateforme précise, pas de pb à ce que long long = 42. Sauf qu'un compilo a en plus des impératifs comme compiler n'importe quel prog, pas que les tiens : et si il adopte long long=16, tous les progs existants utilisant intensivement des calculs 64 bits deviendront 2x plus lents et gourmands en RAM.
Sachant que ça ne te coûte rien d'utiliser int128_t plutôt que long long, et qu'en plus ça te fournit une garantie statique de portabilité, je ne vois pas le pb, vus les gains de vitesse qu'il peut y avoir

>Alors je suis neuneu. Si tu veux un type 128 bits sur un Opteron, ben ça prend 2x plus de place, je suis désolé. Pareil pour la bande passante. Parce que tu penses que tous les types utilises seront des long long ?

Je me place dans le cas (suggéré par tes posts) où c'est une application gourmande de calculs entiers (mais qui n'a besoin que de 64 bits)

Parce que les opcodes des instructions sont codes avec des long long ?

Pareil, typiquement le code sera en cache donc ça n'a aucune influence. Alors que si les données à manipuler sont grosses et qu'on ne peut pas s'arranger pour faire tenir ça dans le cache, c'est la BP mémoire qui sera limitante. Et le code sera 2x plus lent.

>Ca serait un désastre au niveau performance : p-ê qu'on pourrait lire les données 2x+ vite (en fait un peu moins), mais en même tps la moitié des données serait inutile. On disait la meme chose au passage du 16 au 32 bits, et du 32 au 64 bits...

Sauf que les "int" restent en 32 bits, par exemple. Et qu'il n'y a aucun gain à utiliser ça : on n'aura pas besoin de 128 bits de pointeurs. Donc (cf post précédent ) les entiers 64 bits seront tjs gérés d'une manière privilégiée...

>Donc mon parallèle avec la taille des pointeurs est bien pertinent : on a toutes les raisons du monde de croire que le type 64 bits sera plus efficace au niveau taille que n'importe quel type plus gros. C'est bien d'enoncer des evidences, mais ca ne fait pas avancer le debat... que dis-je ? Le double-monologue.

Ce n'est pas du tout une évidence : tu parles de l'alignement à 64 bits sur opteron... Je te dis qu'un alignement plus grand (genre 128 bits) serait une catastrophe.

>Je ne connaissais pas intfast64_t, qui correspond effectivement à peu près à mon idée du "long long". Mais je ne vois alors plus l'intérêt du "long long" ?
On se calme.
intfast64_t est definie (conditionnellement) par la libc en fonction des types supportes par ton compilateur. "long long" est un type definie par GCC, contrairement a intmax_t et co qui sont definies par la libc.

Et ? Cette séparation est parfaitement arbitraire...

> Si on suit ton raisonnement il faut que long long fasse 256 bits sur opteron ? Nan, 128 bits.

Bah non, puisque c'est "dans" les capacité du proc et pas "au-dessus"

>En tout cas comme je l'ai dit ce raisonnement ne pourra certainement pas se prolonger à l'infini, puisqu'on a que 5 types de base... Non bien sur.

Ce qui en dit long sur la pertinence de ces hypothèses... Le modèle "5 types ISO surjectifs mappés en des alias" n'est clairement pas satisfaisant, donc je ne vois pas pkoi retarder d'une génération.

>Et prendre des définitions qui varient autant selon les plateformes, ça me paraît un peu bizarre... C'est pour ca que stdint.h a ete cree.

Donc pkoi ne pas s'en servir et pkoi "casser" les progs existants ? (entendre : les ralentir)

>En plus je crois que certaines architectures 64bits font du 16/32/32/64 avec des ptr 64 bits, donc ça ne colle pas trop avec ton idée du long long... (ou alors on n'aurait pas "de base" un type entier 64 bits) Lesquelles ? C'est pas des alphas, pas des ia64, pas des amd64, pas des sparck64 (leger doute pour sparck64). Donc ?

Oh, c'est une architecture pas très connue, et qui va certainement faire un flop : Windows 64 bits
(j'avais pas donné de nom parce que j'étais pas trop sûr, mais je viens de vérifier sur MSDN)

>Parce que si un prog utilise effectivement les 64 bits de poids fort de ton long long 128 bits, il ne sera pas portable.
Parce qu'un programme utilisant les 16 bits de poids fort d'un int est portable ? Le but des types d'un compilo n'est pas d'etre portable. stdint.h existe !

* parce que je présume que les Unix qui utilisent des int 32 bits sont antérieurs à ANSI
* parce que le "int" a un statut bien plus particulier dans le langage que le "long" ou le "long long" : par exemple, n'importe quel constante entière est naturellement un "int". Ca devait avoir une importance cruciale à l'époque des prototypes K&R...
Et ensuite, comme il se trouvait que 32 bits, ct qd même un peu trop pour l'époque (cf les TI, int=16 bits) et que donc tous les OS n'avaient pas tous int=16 bits, ben c logique de définir un truc vague comme ça.

Aujourd'hui, ça n'a plus lieu d'être et c'est préférable d'utiliser les types de stdint.h, qui sont bien plus clairs, moins limités et plus portables.

-

c de la faute de PpHd

tiens j'ai trouvé un truc interessant dans la définition du C89 :

Les objets de type int tout cours prennent la taille naturelle des nombres pour l'architecture de la machine utilisée ; les autres tailles (NDG: les short int et long int) permettent de répondre à des besoins particulier. La taille mémoire des entiers longs est au moins égale à celle des entiers cours, mais c'est l'implémentation qui détermine si les entiers ordinaires (NDG: les int) sont long ou courts.

Mon mal a la tete prend des proportions gigantesques.

>Mais si tu demandes que intmax_t >= 128 bits, tu enfreinds le standard. Donc autant prendre un int128_t, si ton système le propose...
Aucun systeme ne le propose. Mais tu peux le verifier avec un configure.

>Oh, c'est une architecture pas très connue, et qui va certainement faire un flop : Windows 64 bits
Quelle version ? Et est-ce quelle compile au moins en mode natif 64 bits ?
En tout cas, ca fait une raison de plus de ne pas prendre windows, puisqu'on peut pas faire de cross-multiplication 64x64 -> 128.

inline long long mul(long x, long x) {return (long long) x * y; }

Au lieu de ca tu dois faire 4 produits 32x32 -> 64. Vraiment puissant, alors que ca existe dans le proc.
(Remarque je comprends pkoi ils ont choisi ca: pour continuer de faire tourner les programmes buggues.).

>Donc pkoi ne pas s'en servir et pkoi "casser" les progs existants ? (entendre : les ralentir)
Les progs existant utilisant stdint.h comme ils le doivent ne seront pas ralentis.

>(j'avais pas donné de nom parce que j'étais pas trop sûr, mais je viens de vérifier sur MSDN)
Adresse ?

>* parce que je présume que les Unix qui utilisent des int 32 bits sont antérieurs à ANSI
Linux est sorti apres la norme ISO-C89 et suppose que les int == 32 bits.

>Mais je te parle des trucs existants qui utilisent des long long.
Donc le programmeur n'a pas demande un type de 64 bits mais un type d'au moins 64 bits.
S'il voulait un intfast64_t, il l'aurait demande, non ?
Mais j'ai l'impression que tu confonds programmation portable == programmation portable pour les windows...

>Sauf qu'un compilo a en plus des impératifs comme compiler n'importe quel prog, pas que les tiens : et si il adopte long long=16, tous les progs existants utilisant intensivement des calculs 64 bits deviendront 2x plus lents et gourmands en RAM.
S'ils utilisent des long long, c'est qu'ils voulaient faire des calculs en precisions d'au moins 64 bits. Et ils seront content d'avoir plus de precisions que 64 bits.

>Le modèle "5 types ISO surjectifs mappés en des alias" n'est clairement pas satisfaisant, donc je ne vois pas pkoi retarder d'une génération.
Ca peut etre plus complexe. Utiliser des attributs de GCC pour augmenter la precision des long par exemples.

>Et ? Cette séparation est parfaitement arbitraire...
Non, car ils ne doivent pas etre definis si on n'inclut pas stdint.h.

>Bah non, puisque c'est "dans" les capacité du proc et pas "au-dessus"
... Nan, c'est juste au-dessus de ce qu'il peut faire.

>Je me place dans le cas (suggéré par tes posts) où c'est une application gourmande de calculs entiers (mais qui n'a besoin que de 64 bits)
Une telle application utilise donc intfast64_t.

>Je te dis qu'un alignement plus grand (genre 128 bits) serait une catastrophe.
On n'en ait pas encore la.

>Alors que si les données à manipuler sont grosses et qu'on ne peut pas s'arranger pour faire tenir ça dans le cache, c'est la BP mémoire qui sera limitante. Et le code sera 2x plus lent.
Je vais perdre mon calme. Pas si l'application utilise intfast64_t comme elle le fait si elle voulait utiliser des types de 64 bits!

Mais je me demande pkoi je continue a discuter avec quelqu'un qui veut que long = 4 long long = 8, alors que ce n'est pas impose par le standard, et qu'aucune application ne doit supposer que long long est la maniere la plus rapide de faire du calcul 64 bits.

PpHd :
1. ANSI est une norme americaine. 2. Elle correspond a la norme ISO C 89.

Cette norme n'existe pas. ANSI C89 = ISO C90.

6. Evidement tu devras attendre la revision du standard possedant int128_t.

Le C99 le "possède" déjà, au même titre que les autres intnnn_t, qui sont tous facultatifs! Rien ne te garantit que int32_t existe, par exemple.

Pollux
:

>En plus je crois que certaines architectures 64bits font du 16/32/32/64 avec des ptr 64 bits, donc ça ne colle pas trop avec ton idée du long long... (ou alors on n'aurait pas "de base" un type entier 64 bits) Lesquelles ? C'est pas des alphas, pas des ia64, pas des amd64, pas des sparck64 (leger doute pour sparck64). Donc ?

Oh, c'est une architecture pas très connue, et qui va certainement faire un flop : Windows 64 bits (j'avais pas donné de nom parce que j'étais pas trop sûr, mais je viens de vérifier sur MSDN)

Les programmes GNU et pas mal d'autres sont incompatibles avec cette convention (ils supposent sizeof(long)>=sizeof(void*), certains supposent même l'égalité, qui est satisfaite pour les conventions courantes (LP32, ILP32, LP64)), donc je suppose que MinGW64 et CygWin64 utiliseront vraisemblablement la convention LP64 et pas le IL32P64 de M$VC 64 bits quand quelqu'un fera ces portages.

Godzil :
tiens j'ai trouvé un truc interessant dans la définition du C89 :

Les objets de type int tout cours prennent la taille naturelle des nombres pour l'architecture de la machine utilisée ; les autres tailles (NDG: les short int et long int) permettent de répondre à des besoins particulier. La taille mémoire des entiers longs est au moins égale à celle des entiers cours, mais c'est l'implémentation qui détermine si les entiers ordinaires (NDG: les int) sont long ou courts.

Ceci est faux. Un int n'est pas forcément short ou long, il peut être entre les deux, ce qui est le cas pour le LP64.

>Cette norme n'existe pas. ANSI C89 = ISO C90
Il me semblait que ces 2 normes existaient (ISO C89 et ISO C90).

>Le C99 le "possède" déjà, au même titre que les autres intnnn_t, qui sont tous facultatifs! Rien ne te garantit que int32_t existe, par exemple.
Mea culpa.

>Les programmes GNU et pas mal d'autres sont incompatibles avec cette convention (ils supposent sizeof(long)>=sizeof(void*), certains supposent même l'égalité, qui est satisfaite pour les conventions courantes (LP32, ILP32, LP64))
J'y ai pense hier soir. C'est sur, ca va casser pas mal de programmes cette ABI.

>Ceci est faux. Un int n'est pas forcément short ou long, il peut être entre les deux, ce qui est le cas pour le LP64.
Pour le C89 ou le C99 ?

-

PpHd
: Mon mal a la tete prend des proportions gigantesques.

>Mais si tu demandes que intmax_t >= 128 bits, tu enfreinds le standard. Donc autant prendre un int128_t, si ton système le propose... Aucun systeme ne le propose. Mais tu peux le verifier avec un configure.

Moui, c'est vrai que sous Unix on a les configure. Mais j'imagine aussi que si int128_t n'existe nulle part, intmax_t == 128 bits n'existe pas non plus ?

(surtout que encore une fois, qd tu vas passer à la génération suivante, ton code sera 2x plus lent)

>Oh, c'est une architecture pas très connue, et qui va certainement faire un flop : Windows 64 bits Quelle version ? Et est-ce quelle compile au moins en mode natif 64 bits ?

Je sais pas quelle version. Et oui, c'est du natif (si tu regardes les posts précédents, je parlais de 16/16/32/64 avec ptr 64 bits).

En tout cas, ca fait une raison de plus de ne pas prendre windows, puisqu'on peut pas faire de cross-multiplication 64x64 -> 128.

inline long long mul(long x, long x) {return (long long) x * y; }

Au lieu de ca tu dois faire 4 produits 32x32 -> 64. Vraiment puissant, alors que ca existe dans le proc.

N'importe quoi. inline __int128 mul(__int64 x,__int64 y) { ... }
(sauf que je pense pas que __int128 soit géré pour l'instant)

(Remarque je comprends pkoi ils ont choisi ca: pour continuer de faire tourner les programmes buggues.).

Oui, mais à une nuance près : là où les programmes buggés Win32 supposent long==32 bits, les programmes buggés Unix supposent long==size_t. D'accord c'est incompatible, mais je ne vois pas en quoi l'un est fondamentalement plus mauvais que l'autre. Et la première solution a l'avantage de ne pas perdre de la vitesse à chaque nouvelle génération de processeur...

>Donc pkoi ne pas s'en servir et pkoi "casser" les progs existants ? (entendre : les ralentir) Les progs existant utilisant stdint.h comme ils le doivent ne seront pas ralentis.

Ah ben oui, on est bien d'accord. Donc ça veut dire qu'on est d'accord sur le fait qu'utiliser long long est une infâmie sans nom, si ce n'est pour demander le strict minimum (i.e. 64 bits) ?

>(j'avais pas donné de nom parce que j'étais pas trop sûr, mais je viens de vérifier sur MSDN) Adresse ?

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/win64/win64/abstract_data_models.asp

In 64-bit Microsoft® Windows®, this assumption of parity in data type sizes is invalid. Making all data types 64 bits in length would waste space, because most applications do not need the increased size. However, applications do need pointers to 64-bit data, and they need the ability to have 64-bit data types in selected cases. These considerations led the team to select an abstract data model called LLP64 (or P64). In the LLP64 data model, only pointers expand to 64 bits; all other basic data types (integer and long) remain 32 bits in length.

>* parce que je présume que les Unix qui utilisent des int 32 bits sont antérieurs à ANSI Linux est sorti apres la norme ISO-C89 et suppose que les int == 32 bits.

Mais Linux est un Unix, et ne peut pas se permettre de casser la compatibilité pour ça...

>Mais je te parle des trucs existants qui utilisent des long long.
Donc le programmeur n'a pas demande un type de 64 bits mais un type d'au moins 64 bits. S'il voulait un intfast64_t, il l'aurait demande, non ?

Bah, qd j'ai un char, si je voulais un intfast8_t, je l'aurais demandé, seulement c rentré dans les moeurs d'appeler ça tout simplement "char". Pareil pour short, int, long, etc... Le standard fait en sorte que en pratique, c'est bien comme ça que ça se passe. (sauf pour int, où Unix impose des restrictions en plus) En plus comme dit Kevin toutes les plateformes n'ont pas ça.

Mais j'ai l'impression que tu confonds programmation portable == programmation portable pour les windows...

C'est quoi ce troll baveux ?

>Sauf qu'un compilo a en plus des impératifs comme compiler n'importe quel prog, pas que les tiens : et si il adopte long long=16, tous les progs existants utilisant intensivement des calculs 64 bits deviendront 2x plus lents et gourmands en RAM. S'ils utilisent des long long, c'est qu'ils voulaient faire des calculs en precisions d'au moins 64 bits. Et ils seront content d'avoir plus de precisions que 64 bits.

Ah c'est vrai que c utile dans une application prévue pour des long long de 64 bits d'en avoir de 128 bits

>Le modèle "5 types ISO surjectifs mappés en des alias" n'est clairement pas satisfaisant, donc je ne vois pas pkoi retarder d'une génération. Ca peut etre plus complexe. Utiliser des attributs de GCC pour augmenter la precision des long par exemples.

Ouééé super. Donc on en revient à ce que je disais au début : il faut des types internes au compilos non-standard (utiliser des attributs de GCC n'est qu'un détail d'implémentation, je peux très bien faire #define __intfast128__ int __attribute__((huge))...)

>Et ? Cette séparation est parfaitement arbitraire... Non, car ils ne doivent pas etre definis si on n'inclut pas stdint.h.

mhu?

>Bah non, puisque c'est "dans" les capacité du proc et pas "au-dessus" ... Nan, c'est juste au-dessus de ce qu'il peut faire.

erf, enfin bon ça veut rien dire. Pour moi la bonne sémantique de long long c intfast64_t...

>Je me place dans le cas (suggéré par tes posts) où c'est une application gourmande de calculs entiers (mais qui n'a besoin que de 64 bits) Une telle application utilise donc intfast64_t.

... non standard.

>Je te dis qu'un alignement plus grand (genre 128 bits) serait une catastrophe. On n'en ait pas encore la.

Je dis que justement on en arrivera pas là, si tu lis ce qu'il y autour de la phrase () et que donc il y a de fortes chances que intfast64_t coïncide avec int64_t.

>Alors que si les données à manipuler sont grosses et qu'on ne peut pas s'arranger pour faire tenir ça dans le cache, c'est la BP mémoire qui sera limitante. Et le code sera 2x plus lent. Je vais perdre mon calme. Pas si l'application utilise intfast64_t comme elle le fait si elle voulait utiliser des types de 64 bits!

Et où est l'intérêt d'utiliser des long long alors ? Qd tu fais une app, soit tu le fais pour une seule plateforme donnée, et alors tous ces types-là sont strictement synonymes donc le pb ne se pose pas, soit tu veux faire du cross-plateforme, et à ce moment-là tu veux le plus efficace pour une application donnée, ctou.

Mais je me demande pkoi je continue a discuter avec quelqu'un qui veut que long = 4 long long = 8, alors que ce n'est pas impose par le standard, et qu'aucune application ne doit supposer que long long est la maniere la plus rapide de faire du calcul 64 bits.

Aucune application ne doit non plus supposer qu'un long long fait strictement plus de 8 octets, donc ça nous avance bien

>Moui, c'est vrai que sous Unix on a les configure.


>Mais j'imagine aussi que si int128_t n'existe nulle part, intmax_t == 128 bits n'existe pas non plus ?
Oui.

>(surtout que encore une fois, qd tu vas passer à la génération suivante, ton code sera 2x plus lent)
NAN NANANANANANANA.
Cf mes posts precedents. Tu crois que TOUTES les donnees sont en long long, ou quoi ?

>N'importe quoi. inline __int128 mul(__int64 x,__int64 y) { ... } (sauf que je pense pas que __int128 soit géré pour l'instant)
Vachement portable.

>Oui, mais à une nuance près : là où les programmes buggés Win32 supposent long==32 bits, les programmes buggés Unix supposent long==size_t.
Sauf qu'ils exitent une part non nulle de programmes Win32 supposant long == size_t aussi...
Leur solution ne satisfera personne.
Et tu peux avoir aussi sizeof(size_t) < sizeof(void *).
Cf ABI originelle du 68000

>D'accord c'est incompatible, mais je ne vois pas en quoi l'un est fondamentalement plus mauvais que l'autre. Et la première solution a l'avantage de ne pas perdre de la vitesse à chaque nouvelle génération de processeur...
La ou tu vois "perte de vitesse", je vois gachis du processeur.

>mhu?
Relis le standard.

> Pour moi la bonne sémantique de long long c intfast64_t...
Pour moi c'est juste au dessus de ce que peut faire le processeur.
Et pour ta semantique, il existe intfast64_t, alors que pour ma semantique, il n'existe rien a part long long.

>... non standard.
C'est standard, mais c'est pas force d'exister. M'enfin si ca existe pas, long long non plus surement.

>il y a de fortes chances que intfast64_t coïncide avec int64_t.
Sans rire.

>Et où est l'intérêt d'utiliser des long long alors ? Qd tu fais une app, soit tu le fais pour une seule plateforme donnée, et alors tous ces types-là sont strictement synonymes donc le pb ne se pose pas, soit tu veux faire du cross-plateforme, et à ce moment-là tu veux le plus efficace pour une application donnée, ctou.
Soit je fais comme je fais un systeme dont les limites varient dynamiquement en fonction du systeme pour utiliser pleinement l'architecture du systeme.

>Aucune application ne doit non plus supposer qu'un long long fait strictement plus de 8 octets, donc ça nous avance bien
Oui. Et ?

PpHd :
>N'importe quoi. inline __int128 mul(__int64 x,__int64 y) { ... } (sauf que je pense pas que __int128 soit géré pour l'instant) Vachement portable.

Il y a quand-même les versions récentes de GCC (3.4 minimum si je me rappelle bien) qui comprennent et gèrent __int128 en mode 64 bits. (Mais pas __int64, il faut mettre long ou long long à la place.)

T'es sur ? Ce n'est documente nulle part, et ne marche pas.

Hmmm... Peut-être qu'il faudra attendre GCC 3.5, peut-être que ce n'est effectivement pas encore là du tout. (Ils ont mis __float128 en premier.) Mais je pense que c'est prévu, parce que les docs de la plateforme x86-64 (indépendantes du compilateur) en parlent.

Je confirme que j'ai vu des __float128, mais c'etait juste pour le moment l'alignement des long double.

Kevin Kofler
:

Godzil :
tiens j'ai trouvé un truc interessant dans la définition du C89 :

Les objets de type int tout cours prennent la taille naturelle des nombres pour l'architecture de la machine utilisée ; les autres tailles (NDG: les short int et long int) permettent de répondre à des besoins particulier. La taille mémoire des entiers longs est au moins égale à celle des entiers cours, mais c'est l'implémentation qui détermine si les entiers ordinaires (NDG: les int) sont long ou courts.

Ceci est faux. Un int n'est pas forcément short ou long, il peut être entre les deux, ce qui est le cas pour le LP64.

Mais tu est vraiment con alors...

C'est kernighan et ritchie qui ont ecrit ce texte !

alors va te pendre !

"Le language C norme ANSI"
de Brian W. Kernighan et Denis M.Ritchie

C'est kernighan et ritchie qui ont ecrit ce texte !

si Slashdot a dit le contraire, ils ne peuvent pas avoir raison

Ce n'est pas parce que K&R ont écrit quelque chose que c'est vrai. La norme ANSI/ISO est normative, leur livre ne l'est pas. Et peut-être que c'est aussi la traduction française qui est fausse.

En tout cas, le standard C99 (si tu trouves une copie du C89/C90, tu peux aller vérifier là-dedans, mais je pense que ça te dira à peu près la même chose) dit clairement:

       [#8] For any two integer types with the same signedness  and
       different  integer  conversion rank (see 6.3.1.1), the range
       of values of the type with smaller integer  conversion  rank
       is a subrange of the values of the other type.

         -- The rank of long long int shall  be  greater  than  the
            rank  of long int, which shall be greater than the rank
            of int, which shall be greater than the rank  of  short
            int,  which  shall  be  greater than the rank of signed
            char.

Et c'est tout. Nulle part n'est-il dit que sizeof(short) == sizeof(int) || sizeof(long) == sizeof(int). Et comme déjà dit, sur une architecture LP64, c'est faux! (sizeof(short) == 2, sizeof(int) == 4, sizeof(long) == 8.)