A mon tour de questionner ;) - Page 1

Je me fait un petit topic où je poserai des questions quand j'en aurai.

Première :
Pourquoi quelquefois mon prog plante lorsque j'adresse une variable globale en PC relatif ??

Ah oui, deuxième question.

Je voudrais faire une macro de code ASM (je me demande pourquoi je prog en C, la moitié de mon code est en ASM ) qui retourne une valeur, comme les fonctions. La valeur à retourner doit être placée dans d0, ça ok. Mais comment faire pour le compilateur sache que ma macro ASM retourne une valeur, afin d'appeler ma macro dans un if par exemple ???

>Pourquoi quelquefois mon prog plante lorsque j'adresse une variable globale en PC relatif ??

Aucune idée. Cela ne devrait pas se produire. À moins que ton programme ne fasse plus de 32 KO et que tu veuilles référencer une adresse trop éloignée, mais là, l'assembleur ou le compilateur devrait te dire quelque chose au lieu de produire du code invalide.

<< Je voudrais faire une macro de code ASM (je me demande pourquoi je prog en C, la moitié de mon code est en ASM ) qui retourne une valeur, comme les fonctions. La valeur à retourner doit être placée dans d0, ça ok. Mais comment faire pour le compilateur sache que ma macro ASM retourne une valeur, afin d'appeler ma macro dans un if par exemple ??? >>

Lis attentivement cela: http://tigcc.ticalc.org/doc/gnuexts.html#SEC94.
En gros, il faut déclarer une variable output, et faire par exemple (j'espère qu'il n'y ait pas d'erreurs là-dedans):
#define milledeuxcenttrentequatre ({unsigned long tempvar;asm("move.l #1234,%0":"=g" (tempvar)::);tempvar})
if (milledeuxcenttrentequatre==1234) printf("Évidemment, 1234=1234")
[edit]Edité par Kevin Kofler le 01-09-2001 à 19:55:54[/edit]

est ce ke ca marche avec d'autre valeur que 1234 ?

Y en à qui cartonne, ce soir

y a des jours comme ca

1) J'arrive pas à te suivre
Suite...

erf pourtant g pas bouge !

Je sais pas quoi dire

C ton dernier mot ?

Non, je vais bientôt déconnecter, malheureuseument

moi je suis decérébré la ... c pareil :]

a koi le vois-tu ?

Merci beaucoup de votre pollution les gars.

Et sans ironie, merci Kevin, l'Azur sera rapide grâce à toi
Pour l'histoire du PC relatif avec les variables globales, j'ai lu dans un tuto (je ne sais plus où) qu'il ne faut pas le faire. D'ailleurs le code produit par TIGCC n'en contient pas.

Ah une autre question qui m'interroge :

Dans mon prog je fais des réallocations. Il est donc certain qu'à un moment il va arriver un garbage collection de la RAM.
Les fichiers ouverts à ce moment là sont-ils mis à jour (*fpos & *base) ?

Ça dépend: Pour les fonctions de vat.h non, il faut soit locker le handle, soit mettre à jour la fonction elle-même. Pour les fonctions de stdio.h, je pense qu'elles lockent automatiquement les handles des fichiers, mais tu peux vérifier dans les sources de TIGCC. (Le répertoire archive contient les sources de tigcc.a de TIGCCLIB.) Pour filelib, aucune idée, mais je ne pense pas qu'elle locke quoi que ce soit.

J'ai parlé de filelib

Si je force un GC avant d'ouvrir mes fichiers, les prochains GC ne déplaceront pas les fichiers, si entre temps je ne supprime aucun handle qui existait avant le premier GC ?

>J'ai parlé de filelib

Non, mais j'ai parlé de toutes les fonctions de manipulations de fichiers qu'on peut utiliser.

Au fait, utilises-tu stdio.h ou vat.h?

>Si je force un GC avant d'ouvrir mes fichiers, les prochains GC ne déplaceront pas les fichiers, si entre temps je ne supprime aucun handle qui existait avant le premier GC ?

C'est probable, mais mieux vaut ne pas se tenir à ce genre de choses (par exemple, AMS pourrait avoir effacé un handle système) et locker les handles des fichiers.

Oui mais avec le peu de mémoire que l'on a, en lockant les fichiers ouvert je risque de ne pas pouvoir allouer toute la RAM que je veux. J'ai pas envie que mon compilo renvoie aux utilisateurs "mémoire saturée par la table des symboles" (c'est le plus gourmand en mémoire avec le fichier ASM de sortie) alors qu'il reste plein d'espace

Thibaut je profite de ton topic privé pour te poser une question:
c'est quoi en résumé le bootstrapping ?
(j'ai pas envie de chercher )

C'est compiler le code source d'un compilateur avec... lui même !

Question importante : J'alloue un bloc avec HeapAllocHigh, puis j'augmente sa taille (HeapRealloc). Ca ne marche pas, même s'il me reste plein de mémoire (pourtant je ne lock pas mon bloc) !
????

Pour ta question Kevin, j'utilise les fonctions fopen, fprintf, etc de stdio.h pour mes fichiers.

HeapAllocHigh locke le bloc automatiquement. Si tu veux le réallouer tout en gardant l'effet de HeapAllocHigh, il te faudra appeler dans l'ordre HeapUnlock, HeapRealloc, HeapMoveHigh et HeapLock.

Normalement, fopen devrait automatiquement verrouiller le handle du fichier. (Je n'ai pas vérifié dans les sources.)

Haaaaa

Tu mérites tous les remerciements du monde !
Ils auraient pu l'écrire dans la doc de TIGCC. Encore merci

Sinon, les fichiers ouverts n'ont pas l'air de "souffrir" des GCs de la RAM, on dirait que les fonctions de lecture et écriture vérifient que le bloc n'a pas bougé avant tout accès ou alors ils sont lockés, et là ça serait embêtant quand on a besoin de faire des grosses réallocations...

>alors ils sont lockés, et là ça serait embêtant quand on a besoin de faire des grosses réallocations...

C'est le cas je crois bien, et ça m'embete un peu pour Small... quand je lance SC à partir de SIDE il y a tellement de blocs lockés que j'ai "error memory" alors que j'ai théoriquement 100Ko de libre, c'est la fin du monde
Enfin bon, ça c'est avec la version que tout le monde a, depuis ça c'est un peu amélioré

As-tu des TSRs installés? (Dans tout ce paragraphe, le terme TSR inclut également les kernels.) Si oui, désinstalle-les (si possible). L'organisation de la mémoire d'AMS 2 est suffisamment mal faite (peut-être exprès pour "éviter l'installation en RAM de FlashApps piratées") pour que l'installation de TSRs entraîne une légère désorganisation de la mémoire. En effet, les programmes en assembleur sont mis à la fin de la mémoire avec HeapMoveHigh, donc le prochain HeapAllocHigh ne peut pas être tout à la fin, et quand le programme est déplacé après exécution, le TSR reste locké en plein milieu de la mémoire. Ceci est valable pour tout TSR utilisant HeapAllocHigh, y compris les miens. Mais si on utilise HeapAlloc et HeapLock, c'est encore pire. (Le bloc pourrait se trouver encore plus en plein milieu, puisqu'aucune réorganisation de la RAM n'est effectuée.)
[edit]Edité par Kevin Kofler le 04-09-2001 à 01:36:27[/edit]

Thibaut, tu inclueras un mode _nostub dans ton Azur ?
(c'est pas pour relancer le débat)

Tu as la même question que Kevin, d'ailleurs c'est la première question qu'il m'a posé, ça m'étonne pas
Réponse : oui et non...
En fait je pense que ça sera comme avec TIGCC : l'utilisateur aura le choix entre les deux.
A terme il est même probable que seul le mode _nostub soit supporté. Pourquoi ? Parceque je vais devoir réécrire un assembleur on-calc (AS92 est beaucoup trop lent ), et que j'ai pas envie de me faire chier avec le segment de réallocations. La structure d'un prog _nostub est tellement plus simple

Le compilateur lui-même ne nécessite (remarquez bien que c'est du présent ) pas de kernel, de façon à toucher le plus large publique.
[edit]Edité par Thibaut le 04-09-2001 à 15:12:09[/edit]

Kevin : moi je n'en ai pas quand j'essaie (la flemmme de réinstaller UniOS sur VTI après un plantage).

Pour l'histoire des bloquages de handle, c'est quoi qui est locké ?
Car il y a deux handles associés à chaque fichier, ne l'oublions pas : la structure FILE et le contenu du fichier. Les deux ? Merde

Je parle du handle du contenu qui est locké.

Pour la structure FILE, je pense qu'elle est alloué avec malloc = HeapAllocPtr, qui locke le handle automatiquement (comme HeapAllocHigh), donc effectivement, les 2 seront lockés.

Sinon, pour les TSRs, je parlais surtout à Nitro qui a eu des ennuis avec les handles lockés.

D'ailleurs:
>la flemmme de réinstaller UniOS sur VTI après un plantage
Encore une raison de programmer en _nostub.
[edit]Edité par Kevin Kofler le 04-09-2001 à 22:45:18[/edit]