comment est construit l'auto_int_1?? - Page 3

Mais ca marche pas avec AMS 3

bon ! vous avez pas vraiment compris ce que je cherchais mas ce n'est pas grave,
j'ai trouvé que l'ams stocke l'adresse du handle correspondant au texte copié à l'adresse 0x8472 (si adresse=2byte si 3byte=0x8471)(sur une ti 89 ams 2.09)

mais le fait de ne modifier que cette valeur ne suffit pas a faire croire a la calcos qu'on a fait un copier ou un couper

personne n'a une idée pour savoir ce que fait d'autre la calculatrice lorsque on fait un copier ???

Flanker :
ralalalala

 moveq   #0,d0
 move.l  200,a0
 move.l  776(a0),a0;CB_fetchTEXT
 move.w  2(a0),d0
 move.l  d0,a0

a0 pointe vers une structure telle que
-4(a0) = "TEXT" s'il y a un bloc de sauvé
si c'est vérifié, alors (a0) contient la taille du bloc sauvée (sur 32 bits) et 4(a0) est le handle du blco sauvé
il me semble (mais pas sûr) qu'on peut avoir -4(a0) = "TEXT" et (a0).l = 0, ce qui signifie qu'il n'y a pas de bloc sauvé

ils sont jolis les nouveaux cite

ah d'accoooor j'avais pas remarqué le 'pointe vers'!!!
mais comment tu fais pour lire les 4 premier octets d'un registre ?

et alors comment ce fasse til qu'il y ait à l'adresse 0x8470 ladresse du handle copié??? c'est la que ce situe le registre a0??

ba t'as 0x8470 = a0.l + 4, tout simplement
d'où 0x846C = longueur du bloc
0x8458 = "TEXT"

après, je sais pas comment on fait vraiment en C, peut-être

{
  HANDLE handle;
  void * pointeur = 0x846C;
  longint longueur;

  *(pointeur-4) = "TEXT";
  *(pointeur+4) = handle;
  *pointeur = longueur; 
}

pour avoir un code valide sur les AMS 2.09-,

void set_CB(HANDLE handle, longint length) {
 void * pointeur; 
 asm(" 
   movem.l  %d0/%a0,-(%a7)  \n
   moveq   #0,%d0           \n
   move.l  200,%a0          \n
   move.l  776(%a0),%a0     \n
   move.w  2(%a0),%d0       \n
   move.l  %d0,pointeur     \n
   movem.l (%a7)+,%d0/%a0   \n
  ");
  if ((*(pointeur-4) = "TEXT") && ( *(pointeur+4) != 0)) HeapFree(*(pointeur+4));
 *(pointeur-4) = "TEXT";
 *(pointeur+4) = handle;
 *pointeur = longueur; 

}

Ce code est faux. (Tu ne peux pas écrire dans pointeur avec cette syntaxe, ce n'est pas une variable globale.) Et en plus c'est toujours incompatible AMS 3.

Code correct et compatible AMS 3:

asm("move.l 200,%%a0
     move.l 776(%%a0),%%a0
     tst.w 2(%%a0)
     bne.s 0f
     addq.l #2,%%a0
     0:
     movea.w 2(%%a0),%0"
    :"=a"(pointeur)::"d0","a0","cc");

ou plus simplement :

short *base=(void *)CB_fetchText;
base[1] ?: base[2];

C pawa ^^

Plutôt:

short *base=(void *)CB_fetchText; 
*(void**)(long)(base[1] ?: base[2]);

./69: Ca utilise une GNU extension.

Oui, et ?
Je n'ai entendu parler d'aucun compilo dont la lib std connaisse CB_fetchText et pas cette extension...

Donc fallait dire GNU-C pawa

Non, GNU C sux par rapport au C++ qui rend 99% des extensions inutiles

Nan, C++ sux par rapport a GNU-C qui rend 99% du langage C++ inutile

Là par contre tu dis n'importe quoi

Toi aussi

Euh, tu penses à quelle extension GNU qui ne peut pas être fait en C++ sans de grosses contorsions ?
Parce que moi j'en vois plein en C++ qui peuvent pas être fait en GNU C

Il y a déjà les VLAs C99. (Non, vector n'est pas une solution, l'overhead est énorme.) Même chose pour les complexes.

C vrai qu'on ne peut pas allouer sur la pile si le système ne fournit pas d'alloca, mais à la limite si on veut une portabilité maximale c tjs possible de faire un truc conditionnel soit alloca soit vector...

Pour les complexes, je ne vois pas quel est le pb du C++ Tu connais les templates ?

Les VLAs ne sont pas seulement une histoire d'allocation, mais aussi de passage de tableaux 2D en paramètre, par exemple.

Et les complexes en classe+template sont nettement moins efficaces que les complexes natifs du C99!

Kevin Kofler
: Les VLAs ne sont pas seulement une histoire d'allocation, mais aussi de passage de tableaux 2D en paramètre, par exemple.

Le C++ ne le permet pas nativement ?
Si effectivement ce n'est pas possible, il y a tjs la solution triviale du template intermédiaire (template<class T,int n> class array { T value[n]; }) avec les overload et constructeurs qui vont bien (et ça doit être typiquement le genre de truc qu'on doit trouver dans la lib boost)

Et les complexes en classe+template sont nettement moins efficaces que les complexes natifs du C99!

Ah ? Qu'est-ce qui te fait dire ça ?

Attention! Je parle des extensions GNU C compares au standard C++ (Pas a G++ evidemment!)

1. ({ })
2. Les labels locaux
3. Equivalence Label, Ptr
4. Les fonctions nested
5. Construire des appels de fonctions dynamiques.
6. LValue generalise
7. x ? : y
8. long long
9. Complexe natif
10. Floattant hexadecimaux
11. Structure avec dernier membre de taille 0.
12. Variable-length automatic arrays.
13. Structure vide en C = 0 octets
14. Macro avec nombre d'arguments variables
15. Non-Lvalue Arrays May Have Subscripts
16. Compound Literals
17. int a[6] = { [4] = 29, [2] = 15 };
18. Cast vers un type Union: union foo { int i; double d; }; int x; union foo u; u = (union foo) x ;
19. case low ... high
20. Les attributs!!!!!
21. Les builtin!!!!
22. $ acceptes dans les noms.
23. Assembleur inline
24. Donner un nom asm != nom C
25. Expliciter le passage des arguments par les registres.
26. Enum incomplet
27. __func__
28. Recuperer l'adresse de frame / de retour d'un niveau i
29. Les vector extensions !
30. Champ struct/union non nomme dans une struct (Oups. Je sais plus si c'est ISO C++ ca).
31. Variable unique a chaque thread

Quoiqu'apres reflexion j'ai des doutes sur certains trucs. Tu me corrigeras

Et plus important encore:
http://www.gnu.org/prep/standards_7.html#SEC7

Le c est le standard de la FSF

printf ("size = %lu\n", (unsigned long) sizeof array);
printf ("diff = %ld\n", (long) (pointer2 - pointer1));

1989 Standard C requires this to work, and we know of only one counterexample: 64-bit programs on Microsoft Windows 64.

Je parle uniquement des extensions GNU par rapport à C99 :

1. Fonctions inlines + templates
2. Ca t'a déjà servi ?
3. Ca t'a déjà servi ?
4. Classes
5. = ?
6. De toute façon c gore, mais ça doit même pouvoir se contourner avec des overloads (jamais essayé)
7. Accordé (mais bon c un détail)
8. C du C99, pas du GNU
9. C du C99, pas du GNU
10. Ca t'a déjà servi ?
11. C du C99, pas du GNU
12. C du C99, pas du GNU
13. C99 ?
14. printf sux, y a bien plus propre
15. operator[] si ça marche pas en natif
16. Accordé, mais c du C99, pas du GNU
17. C99 ?
18. Classe intermédiaire si ça marche pas en natif
19. Mouais...
20. Bah ça c compiler-specific, ça dépend de la plateforme, etc...
21. Tu penses à quoi ?
22. mdr
23. Bah ça c compiler-specific, ça dépend de la plateforme, etc...
24. Bah ça c compiler-specific, ça dépend de la plateforme, etc...
25. Bah ça c compiler-specific, ça dépend de la plateforme, etc...
26. Ca t'a déjà servi ? (même pas sûr de voir ce que c)
27. C du C99, pas du GNU
28. Bah ça c compiler-specific, ça dépend de la plateforme, etc...
29. grüt ?
30. Accordé, ça c vraiment chiant... (ce qui serait génial ce serait de pouvoir faire des Property comme en C# )
31. grüt ?

Donc bon, je vois que 7 et 30... 7 est vraiment du détail pas franchement utile (sauf dans une macro, si on a la flemme de faire un ({}) autour : mais de toute façon en C++, Macro Must Die), par contre le fait de pas pouvoir faire les get{}/set{} de C# est dommage Les foreach() aussi ça manque cruellement

Donc extension GNU C++ sux ^^ (par contre, une révision du standard C++ ne serait pas malvenue, même si dans 80% des cas ça ne sert pas à gd chose)

1. Totalement faux!!!! Une macro est plus flexible qu'une template+inline (dans son domaine) puisqu'elle accepte comme arguments n'importe quoi.
4: Si tu veux.
5. C'est assez complique et assez specifique. J'avoue ne pas avoir tres bien compris moi meme a quoi ca sert.
6. Nan c pas gore. c'est meme tres pratique: #define set(x,n) (assert(x),x).tab[n]
8,9,11,12,27: Et alors
10. Oui ca m'a servi!!!!!!
14. C'est pas limite a printf
16. Pas sur que ca soit du C99.
17. Chais plus. Je crois pas.
18. Accorde mais c'est pas immediat
20. Les attributs dependent pas trop de la plate-forme en regle generale
21. Va lire les 200 fonctions builtin de GCC
23,24,25: Peut etre mais c'est hyper-utile.
28. C'est une extension GNU...
29. typedef int v4 __attribute__((v4si)); v4 x,y,z; x=y+z*x; ==> Utilisation des instructions MMX/SS2E si elles existent.
31. Ben lorsque tu fais un thread, tes variables gloables sont pas propres a chaque thread ? Ben la tu peux avoir des variables
specifiques a chaque thread.

10. Flottants hexadécimaux
c'est carrément utile ! Sinon, tu es obligé de faire confiance au compilo pour transformere tes constantes flottantes en hexa, et je crois qu'il faut les donner avec beaucoup de chiffres pour être sûr que la transformation est correcte

1. Et ? Une fois que tu as préprocessé via une macro intermédiaire, tu passes tes trucs à une fonction inline, ça ne pose pas de pb...
5. Donc ça sert à rien...
6. #define set(x,n) (assert(x),x.tab[n]) -- et tu évalues ton truc 2 fois...
8,9,11,12,27. Bah ça sert à rien de faire des extensions propriétaires ©
10. Bah évidemment qu'on fait confiance au compilo, sinon c le compilo qui est buggé, c pas un défaut du langage... (et de toute façon tu es obligé de lui faire confiance pour plein d'autres choses : s'il fait de la propagation de constantes fausse, ben c DTC) Et sinon je veux bien croire que ça peut être un peu pénible de convertir ^^
14. La méthode utilisée en C++ qui fait qu'on n'a plus besoin de printf n'est pas limitée à printf non plus Et ça permet d'avoir un typage sûr, entre autres avantages...
16. Bien sûr que si !
17. Ah euh pour les tableaux non... En tout cas pour les structures oui.
18. boost no pawa ^^
20. __align__ ? __stkparm__ ? etc... Bon, OK pour noreturn, mais franchement on s'en passe très très bien... Au pire tu fais une macro qui fait (myfunc(params),exit(42))
21. 95% ne sert à rien en C++
23,24,25. Bah dans ce cas-là c pas une extension de langage
28. Bah non, c complètement spécifique à la plateforme, ça n'a aucun sens dans la perspective du std C
29. Doit y avoir ça aussi dans VC++...
31. Mouais, donc là c spécifique à l'environnement...