C Taille d'un membre de structure - Page 3

Pen^2 (./55) :
bsr push empile son adresse de retour et branche sur push, qui appelle printf qui utilise l'adresse qu'il trouve sur la pile déposée par bsr push (qui se trouve être l'adresse de la chaîne) et au retour il restaure la pile avec le addq.
Comme c'est joli !

Ha ouais juste. Perdu l'habitude de ces proços qui prennent leur temps en sauvant l'adresse de retour sur la pile

Le code de Folco est un joli hack, pas très propre, mais qui économise effectivement 2 octets. Cela dit, ce genre de hacks rendent le débogage moins pratique.

Pourquoi pas propre ? bsr n'est pas un outil pour brancher et revenir, c'est un outil qui empile PC et saute à une adresse, ce n'est pas pareil. C'est comme ça qu'il faut penser quand on code en assembleur. Sinon autant faire du C.

Sur 68k, ça va. Sur d'autres archis...

Pen^2 (./55) :

bsr push empile son adresse de retour et branche sur push, qui appelle printf qui utilise l'adresse qu'il trouve sur la pile déposée par bsr push (qui se trouve être l'adresse de la chaîne) et au retour il restaure la pile avec le addq. Comme c'est joli !

Tribute to Pollux. C'est lui qui m'a donné le trick.

Pen^2 (./63) :
Pourquoi pas propre ? bsr n'est pas un outil pour brancher et revenir, c'est un outil qui empile PC et saute à une adresse, ce n'est pas pareil. C'est comme ça qu'il faut penser quand on code en assembleur. Sinon autant faire du C.

C'est comme ça qu'il faut penser pour sortir de sentiers battus et pas coder "comme les autres", par simple habitude de ce qu'on lit dans leur code.

Brunni (./54) :
Je ne suis pas sûr non plus de voir ce que veut faire Folco (où il empile son pointeur).

Je suis super étonné, j'étais persuadé que tu touchais fort en 68k

(bon Pen², lui je savais, Flash Savior rulez )

Je connais depuis longtemps l'astuce du bsr pour empiler une constante. Je ne l'ai pas utilisée ici parce que les chaînes de caractères n'ont rien à faire au plein milieu d'une fonction. Normalement, elles sont censées être dans des sections mergeables, pour pouvoir unifier les chaînes de caractères identiques si elles apparaissent plusieurs fois dans le programme; je ne l'ai pas fait dans mon exemple par souci de simplicité (mais GCC fait ça très bien).

PS: Regarde le code source de TitaniK pour voir que je suis tout à fait capable d'écrire du code assembleur tordu quand c'est nécessaire. (Dans TitaniK, c'est nécessaire surtout pour respecter les contraintes de ne détruire strictement rien, l'optimisation n'est que secondaire.) Le problème, c'est que ce genre de code est illisible. Tu remarqueras d'ailleurs que j'ai mis des commentaires toutes les quelques lignes des stubs de TitaniK pour rappeler le contenu de la pile à cet endroit. Sans ça, j'étais totalement perdu dans mon propre code.

Folco (./65) :

Brunni (./54) :
Je ne suis pas sûr non plus de voir ce que veut faire Folco (où il empile son pointeur).

Je suis super étonné, j'étais persuadé que tu touchais fort en 68k

Hé non ^^ Bon là j'admets que j'ai pas trop cherché, parce qu'à une époque j'aurais su, j'ai plus pensé parce que sur à peu près tous les processeurs "récents", style 90's et plus, brancher à une sous routine n'empile pas le pc (ça te permet de sauter à une sous-routine et retourner sans accès mémoire, donc en ~2 cycles ).

surtout l'arm en fait

MIPS, et basiquement tout ce qui est RISC. Mais c'est vrai qu'ils ont gardé ça pour le x86_64 (ce qui est bizarre parce que les paramètres et le retour sont passés par registre).

Enfin pas d'excuse, j'aurais dû le savoir surtout que j'ai codé sur z80 y a pas longtemps

Et sinon, l'astuce de Folco a 50% de chances (ça dépend de la chaîne de caractères en question) de n'économiser qu'un octet plutôt que 2, parce que le code ne peut pas continuer à une adresse impaire.

Kevin Kofler (./66) :
Normalement, elles sont censées être dans des sections mergeables, pour pouvoir unifier les chaînes de caractères identiques si elles apparaissent plusieurs fois dans le programme; je ne l'ai pas fait dans mon exemple par souci de simplicité (mais GCC fait ça très bien).

Ca, c'est pour les C-istes, pas les assembleuristes. On ne développe pas en asm pour développer vite, on mets ses strings à part, toutes dans le même fichier pour éviter les paddings inutiles etc...
A noter que le trick donné est tout à fait réthorique, car les chaines dans le code vont très vite produire plus références longues que courtes (ça prend de la place une chaine, quand la limite pour les sautes est de +-128 octets), qu'une fois sur deux comme tu dis, ça ne gagneras pas deux octets, que ça rend le code pas maintenable etc... Voilà voilà...

Kevin Kofler (./67) :
je suis tout à fait capable d'écrire du code assembleur tordu quand c'est nécessaire

Je sais; t'inquiète

Folco (./72) :
Ca, c'est pour les C-istes, pas les assembleuristes. On ne développe pas en asm pour développer vite, on mets ses strings à part, toutes dans le même fichier pour éviter les paddings inutiles etc...

Il n'y a pas de padding entre 2 sections marquées "unaligned". J'ai pensé même à ça dans ld-tigcc (et j'ai aussi rajouté le flag "unaligned" à GNU as et à GCC, au même temps que le flag "mergeable").

.section .data.mystring,"dmu"
.xdef mystring
mystring: .asciz "ld-tigcc rulez!"

d = data
m = mergeable
u = unaligned

Je ne parlais pas non plus de section. Je ne les utiliserais que si l'algo de ld-tigcc était optimal, ce qui n'est pas le cas. J'ai déjà écrit des macros pour optimiser l'usage des sections cependant.


tu penses quoi des codes postés à la page précédente ?

Folco (./74) :
Je ne les utiliserais que si l'algo de ld-tigcc était optimal, ce qui n'est pas le cas.

Je veux te voir utiliser un linker à complexité exponentielle.

Folco (./74) :
Je ne parlais pas non plus de section. Je ne les utiliserais que si l'algo de ld-tigcc était optimal, ce qui n'est pas le cas. J'ai déjà écrit des macros pour optimiser l'usage des sections cependant.

!call GT Turbo
--- Call : GT Turbo appelé(e) sur ce topic ...
tu penses quoi des codes postés à la page précédente ?

A part te tiré mon chapeau bas, perfect !! J'aurais juste peur a cause des alignements (Chaine de caractères qui pourraient être de nombre impairs) mais cette utilisation du BSR, j'en ai vu des milliers de lignes de code 68000, mais première fois de ma vie que je vois cette utilisation l'a, donc juste PERFECT !!!

Le jour ou un compilo me déballe le genre de code a 'la Folco', je me mettrais peut etre au C mais pour l'instant ASM powered !!

GT Folco

Faut mettre un .even après la chaîne effectivement, pour éviter de mauvaises surprises.

GT Turbo (./76) :
A part te tiré mon chapeau bas, perfect !!

Folco (./65) :
Tribute to Pollux. C'est lui qui m'a donné le trick.

Tiens sinon, où pourrais-je lire du code à toi ?

Kevin Kofler (./77) :
Faut mettre un .even après la chaîne effectivement, pour éviter de mauvaises surprises.

Exactement.

Kevin Kofler (./77) :
Faut mettre un .even après la chaîne effectivement, pour éviter de mauvaises surprises.

C'est qu'un détail technique, cela fait un moment que mon subconscient 'even' toutes chaines de caractères.

Folco, du code a moi ?


GT

GT Turbo (./79) :
Folco, du code a moi ?

Yep, j'aimerais lire des programmes que t'as pu écrire.

C'est beau, une idylle naissante !

Folco > boaf, je n'ai jamais été spécialement fort en 68k, tu sais ! Mais c'est rigolo d'entendre parler de flash savior après tout ce temps ; merci

Pen^2 (./81) :
C'est beau, une idylle naissante !

C'est un peu comme se déshabiller pour la première fois, lire un source xD

(Folco a un joli tatouage en "Courrier New" taille 8 sur le bas des hanches, le tout est est en asm 68k roar)

bande de cons, je vous aime tous