TIGCC: moi plus comprendre - Page 1

voilà je voulais compiler un ptit programme:

extern void	a(register short x asm("d0"),
							register short y asm("d1"),
							register void *plan asm("a0"),
							register void *ZFont asm("a1"));
 
void _main(void)
{
	a(0,0,LCD_MEM,tst);
}

avec:

	section ".data"
	xdef	a
	
a:
	move.w 	(a1),d0
	rts

et j'ai le droit a une belle adresse error
je suis peu etre fatigué mais je vois pas `d'où ca peut venir

a1 est impair ?

tu devrais mettre un .even devant ton 'tst'

je veux bien, mais le tst est defini en C

arg !

Timad > Utilise uin

move.b
lsr
move.b

t'as pas plus lent

d'ailleur toutes les routines de sprites sont de cette maniere donc toutes sont instables!

je pense que ça peut se trouver.
en copiant bit à bit, par exemple

g regardé dans la doc, apparamment y'a rien pour forcer l'alignement sur un word.


sinon, tu peux tjs faire un

__asm( .even ) ; // je connais pas la syntaxe, dsl
[definition de tst]


car il me semble que Kevin av dit que les données étaient mises dans l'ordre. Mais bon, c franchement dégueu..

Il me semble que si tes données sont déclarées comme 'short', gcc les aligne toujours sur une adresse paire

http://tigcc.ticalc.org/doc/gnuexts.html#SEC90

Inquiring on Alignment of Types or Variables
The keyword __alignof__ allows you to inquire about how an object is aligned, or the minimum alignment usually required by a type. Its syntax is just like sizeof.

In TIGCC, __alignof__ (anything) is always 2, except for char variables.

If the operand of __alignof__ is an lvalue rather than a type, its value is the required alignment for its type, taking into account any minimum alignment specified with GCC's aligned attribute. For example, after this declaration:

struct foo { int x; char y; } foo1;

the value of __alignof__ (foo1.y) is 1, even though its actual alignment is 2, the same as __alignof__ (int).
It is an error to ask for the alignment of an incomplete type.

EDIT : ah, nan, c en lecture, j'av pas bien lu

GoldenCrystal
: Il me semble que si tes données sont déclarées comme 'short', gcc les aligne toujours sur une adresse paire

j'espere, parce que sinon.. !


mais là ca doit etre des char.

JS : A mon avis, il manque un petit even devant a:

Kevin : au fait, est-ce que votre nouvel éditeur de liens supportera enfin __attribute__((constructor)) ?

thibaut : il assemble une instrruction asm sur une adresse impaire ??????

Il me semble qu'il peut.

Pen^2
: g regardé dans la doc, apparamment y'a rien pour forcer l'alignement sur un word.

short tst __attribute__ ((aligned(2)));

d char data4[17];

Déclaration en C:unsigned char data1;
unsigned char data2;
unsigned char data3;
unsigne

.space 18 .even

Assembleur produit:.globl data1
	.even
data1:
	.space 2
	.even
.globl data2
	.even
data2:
	.space 2
	.even
.globl data3
	.even
data3:
	.space 2
	.even
.globl data4
	.even
data4:

ça suffit à vous rassurer ?

Quoi !!!!?
TIGCC fout un .even devant les bytes ?!!!!!?
Et les responsables du projet prétendent qu'ils sont pro-optimisation-mémoire...

non

pq il reserve 2octet pour 1 char ????

je sais po si vous avez vu mais il prend 1 octet de plus a chaque fois

ba un coup sur 2 apparemment, oué
GCC (pas GGC, hein )

viva GTC (enfin j'en sais rien mais bon, dans le doute !)

ça suffit à vous rassurer ?

moi ça m'inquieterait plutot

ben euh, tu sais, si tu mets

dc.b 0
.even

C'est exactement la même chose

godzil :
non
pq il reserve 2octet pour 1 char ????

godzil :
je sais po si vous avez vu mais il prend 1 octet de plus a chaque fois

Heu t'as pas vu le post #16, toi


GTC ne fait pas ça. Je pense que c'est une des choses qui fait que le code produit par TIGCC est généralement plus gros que celui produit par GTC.
[prout]J'informe. Qu'on ne parte pas sur un débat encore ![/prout]

Ct un cross Thibaut :/

je preveint d'avance que le prochain qui sort une phrase entre gtc et tigcc non constructive (qui me parait non construcive) c'est ! kick

Pen^2 :
ba un coup sur 2 apparemment, oué

Nan a chaque fois !!! :

unsigned char data1;

un char, qu'il soit signé ou pas, ça fait 1 octet ok ?

GCC donne :

.globl data1
	.even
data1:
	.space 2

.space permet de reserver des octets dans le code généré ok ?
Donc pour GCC un char fait 2 octets

Pour data2 et data3 c'est pareil que data1

unsigned char data4[17];
Ici on allou un tableau de 17 char, cad 17 octets

GCC donne :

.globl data4
	.even
data4:
	.space 18
	.even

Et la GCC nous produit un espace de 18 octets

Bref, je repete se que je disait sur un autre topic ou je disait sa en rigolant, mais la un peu bcp mois :

GCC c'est de la merde :/

La mienne est constructive : elle a pour but d'informer d'un avantage de GTC sur TIGCC

Alors JS, un even devant le label a: a résolu ton problème ?

* Avez-vous essayé avec la version la plus récente?
* Avez-vous essayé de rajouter un __attribute__((packed)) un peu partout?

Et ma question sur le linker que tu es en train de programmer ?

C'est le linker que nous (Sebastian et moi) sommes en train de programmer.

Thibaut :
Kevin : au fait, est-ce que votre nouvel éditeur de liens supportera enfin __attribute__((constructor)) ?

Normalement oui, mais ce n'est pas encore testé.

Cool