Compilation avec GNU as - Page 1

Martial Demolins (./1) :
- as compile un bcc.s même si le label est trop loin (on a donc un offset incorrect, mais pas de message d'erreur) (ok, il faut pas écrire .s, mais est-ce un comportement normal?)

Normalement, il devrait y avoir une erreur soit au niveau de l'assembleur, soit au niveau du linker. C'est avec ou sans --cut-ranges (-> mode all-relocs de l'assembleur), ça? Et le bcc.s est-il vers la même section ou vers une autre?

- as compile même si on fait un .xdef sur un label inexistant

Normal ça, et important pour les .xdef des options linker (A68k est lourd sur ce point.)

- est-ce que tigcc linke avec /usr/local/tigcc/include/s/os.h quand on utilise GNU as même en kernel (il me semble bien que oui, mais...)? si oui, peut-on le désactiver?

os.h n'est pas inclus implicitement, si tu ne mets pas de .include explicit, il n'est pas utilisé.

Martial Demolins (./3) :
Et que veut dire le -I/usr/local/etc... ? Ca doit être juste un répertoire de recherche alors?

Exact.

Il y a un switch -q (quiet).

Martial Demolins (./9) :
Purée, GNU as compile un brs (bsr mal écrit) en bra, c'est dangereux ce truc

Les points sont optionnels en GNU as, donc brs = br.s, qui est accepté pour bra.s pour la compatibilité avec d'autres assembleurs.

Martial Demolins (./10) :
Doit-on partir du principe qu'AMS ou PedroM détruisent les arguments sur la pile lors des ROM calls?

Normalement oui. En pratique, la plupart des fonctions ne le font pas, mais certaines, notamment sprintf, le font. Donc il vaut mieux toujours s'attendre au pire, parce que sinon le programme peut casser avec une mise à jour de AMS ou PedroM.

Martial Demolins (./12) :
Autre question Est-ce qu'un handle dont on réduit la taille avec un HeapRealloc peut bouger?

Oui, si et seulement s'il n'est pas verrouillé (locké).

Et eut-on réduire sa taille en le laissant locké?

Oui.

Parce que ça peut réorganiser toute la RAM.

à éviter la fragmentation des blocs de RAM pour éviter d'y avoir des petits trous qu'on peut allouer à personne après

je trouve ça génial moi

oui, c'est sur.

Mais pour une utilisation normale de calculatrice, ils doivent préférer faire des GC de temps en temps plutot qu'à chaque alloc, car l'algo doit être assez coûteux

(si t'as un trou au début et que l'algo est con, il va devoir déplacer toute la ram au début ) (et même, si tu te sers des gros trous au début pour y caser des petits bouts de la fin, t'es quand même obligé de déplacer des blocs, et t'augmentes la complexité si les adresses de débuts de blocs ne sont pas classées par ordre croissant selon les handles)

bref: chais pas comment ils ont codé ça , en fait.

Pitêtre parce que le numéro du handle n'est pas lié a son emplacement en mémoire ?

(Je m'applique a faire des posts constructifs hein alors si je dis une betise plus grosse que moi...n'hesitez pas a me le dire )

Les handles ne sont absolument pas classés en l'ordre croissant en mémoire.

le maître a parlé

merci

donc vala, pas de compression de heap à chaque allocation car l'algo est un peu lourd

./25: de mémoire (mais vérifie en lisant le code de HeapUnlock, il n'est vraiment pas compliqué ^^):
* HeapUnlock(H_NULL) fait Address Error sur AMS, puisque H_NULL pointe vers 0xFFFFFFF, et que HeapUnlock fait un accès word.
* sauf s'il y a une protection juste après le HeapDeref macro contenu dans HeapUnlock, sur AMS, HeapUnlock(un handle invalide pointant vers NULL) va tenter d'accéder à 0xFFFFFE. Je ne suis pas sûr de ce que ça va faire, jette un coup d'oeil sur la doc de Johann Eilert.