Structures sur a68k - Page 1

Je voulais juste savoir si a68k supporte des structures genre C comme le font certains assembleurs de x86 (tasm, par exemple).

Non. Ce que tu peux faire est de définir des equates pour les offsets.

C'est bien ce que je fais actuellement. Donc pas de chance.

Le fait est qu'à présent j'ai un truc de ce genre:

data
var1	dc.l	0
var2	dc.b	0
;	...

.
que je réference avec varn-data(ax) (où ax est l'addresse effective de data(PC)), et je veux le mettre en RAM, dans une zone allouée dynamiquement.

Donc il n'y a pas de solution plus propre que de faire:

var1	equ	0
var2	equ	4
;	...

.
et réferencer avec varn(ax)

(Le segment bss ne m'est pas utile)

En tout cas, ce serait une belle feature pour a68k.

boogerman a écrit :
Donc il n'y a pas de solution plus propre que de faire:

var1	equ	0
var2	equ	4
;	...

.
et réferencer avec varn(ax)

Non. La solution ci-dessus est la bonne solution. Je ne vois pas en quoi elle ne serait pas propre.

En tout cas, ce serait une belle feature pour a68k.

Non, ça n'apporterait vraiment rien à mon avis.

Et d'ailleurs l'état de développement actuel de A68k est: si tu veux une nouvelle fonctionnalité, maile-moi un patch. Je suis le seul mainteneur de A68k, et je n'ai pas le temps de m'occuper de A68k autrement que pour la correction de bogues, ni d'ailleurs l'envie, vu que parmi les idées de fonctionnalités dans TODO.txt, aucune n'est vraiment indispensable. Et je suis désolé, mais la tienne m'a l'air tellement peu utile par rapport à la complexité d'implémentation que je ne la mettrai même pas dans TODO.txt.

Je suis d'accord: ça paye pas le boulot que ça prend pour l'implémenter.

En tout cas, j'ai écrit un prog en C auquel je file un fichier avec la syntaxe:

foo
foo.bar 2
foo.foo 1

et il genère:

foo equ 0
foo.bar equ 0
foo.foo equ 2

Ce qui me simplifie pas mal les choses :^)

> Je ne vois pas en quoi elle ne serait pas propre.
Si on veut insérer ou supprimer une variable, il faut corriger tous les offsets. La première n'a pas cet inconvénient.

Mais ça n'a aucun rapport avec la propreté. Et ce n'est pas un vrai problème. On ne change pas la structure en permanence normalement.

Ta dernière remarque me paraît ridicule. Je suis d'accord avec les deux premières.

En quoi ma dernière remarque serait-elle ridicule??? Et c'est l'argument qui justifie la deuxième!

Comment t'es fier (pour que ça t'énerve autant)

Tu n'as toujours pas expliqué ce qui est "ridicule" dans mon propos.

Je te crois assez intelligent pour comprendre en te relisant

Ben désolé, je ne comprends pas du tout. On ne change pas la structure en permanence normalement, donc il n'y a pas de problème à devoir changer les offsets un par un les rares fois où on a besoin de changer la structure. Il y a quoi de ridicule là-dedans???

On ne change pas la structure en permanence, mais on la change quand même de tps à autre. Et comme à chaque changement il faut régler tous les offsets... aïe aïe aïe... voilà pourquoi elle n'est pas propre.

Une solution semi-propre est celle que j'ai faite (un "language" de description de structure et un prog qui genère les offsets).

La solution propre, est bien sur, que ce soit supporté par l'assembleur (attention: ne me malinterprète pas: je ne suis pas en train de te demander de le faire, je dis juste que ce serait le plus propre).

boogerman
a écrit : On ne change pas la structure en permanence, mais on la change quand même de tps à autre. Et comme à chaque changement il faut régler tous les offsets... aïe aïe aïe... voilà pourquoi elle n'est pas propre.

Je ne vois pas en quoi ce ne serait pas "propre". Ça fait juste un peu de travail en plus (pas beaucoup), mais c'est normal qu'on ait du travail en plus en assembleur qu'en C.

qu'on ait

Eh ben, cela depend de la définition que l'on donne au mot "propre" :-P.

Je disserte:

En ce qui concerne la programmation, je pense qu'on pourrait lier la proprété au style de programmation. Mais qu'est-ce-qu'on a à foutre du style? Ben, (normalement) un bon style implique du code facilement modifiable, corrigeable et agrandissable. Donc, si on étend la definition de proprété aux propriétés mentionées, on peut bel et bien appeler impropre une solution qui va contre ces propriétés.

Si on recherche ces propriétés-là, il faut programmer en un langage de haut niveau, pas en assembleur.

Mouais, je suis pas très convaincu. Je vois pas en quoi la prog en assembleur exclut la prog structurée. On peut bien vouloir écrire du code rapide, mais structuré quand même.

Qu'est ce vous avez tous à critiquer le style de programmation de chacun. Le mot 'propre' n'as aucun sens, on peut programmer des trucs rapide et puissant avec de l'assembleur en le structurant. L'assemebleur certe est un peu barbare comme langage mais il est posible de le structuré comme un autre langage.

Kevin, je te trouve de mauvaise fois (pour changer)
Remercie au moins boogerman de t'avoir éclairé

Regarde mes codes sources (Cf ou sma). Tu verras comment faire des structures propres comme tu veux avec a68k.

boogerman
a écrit : Mouais, je suis pas très convaincu. Je vois pas en quoi la prog en assembleur exclut la prog structurée. On peut bien vouloir écrire du code rapide, mais structuré quand même.

Ben, dans ce cas, justement, on a tord de programmer en assembleur. En assembleur, si on veut du code rapide, il ne faut surtout pas le structurer! Sinon, on a un code bien structuré, bien gros et bien lent.

geogeo
a écrit : Qu'est ce vous avez tous à critiquer le style de programmation de chacun. Le mot 'propre' n'as aucun sens, on peut programmer des trucs rapide et puissant avec de l'assembleur en le structurant. L'assemebleur certe est un peu barbare comme langage mais il est posible de le structuré comme un autre langage.

... et le code résultant sera très loin d'être optimal! En assembleur, il faut optimiser, pas structurer!

Thibaut a écrit :
Kevin, je te trouve de mauvaise fois (pour changer)

J'en ai marre de toi! Arrête de parler sans rien comprendre! Et puis apprends à écrire "mauvaise foi" correctement! Reviens quand tu auras compris de quoi je parle, ainsi que les règles de l'orthographe française!

Kevin Kofler
a écrit : Ben, dans ce cas, justement, on a tord de programmer en assembleur. En assembleur, si on veut du code rapide, il ne faut surtout pas le structurer! Sinon, on a un code bien structuré, bien gros et bien lent.

Tiens, tu t'intéresses à la vitesse maintenant ?

J'en ai marre de toi! Arrête de parler sans rien comprendre! Et puis apprends à écrire "mauvaise foi" correctement! Reviens quand tu auras compris de quoi je parle, ainsi que les règles de l'orthographe française!

Je suis d'accord avec toi (enfin, surtout pour le début).

jackiechan
a écrit : Tiens, tu t'intéresses à la vitesse maintenant ?

Évidemment que je préfère du code petit et rapide à du code gros et lent, et même du code gros et rapide à du code gros et lent. Mais je préfère du code petit et lent à du code gros et rapide.

Kevin Kofler
a écrit : Ben, dans ce cas, justement, on a tord de programmer en assembleur. En assembleur, si on veut du code rapide, il ne faut surtout pas le structurer! Sinon, on a un code bien structuré, bien gros et bien lent.

Mais tu fais pourtant partie de l'équipe de tigcc si je ne me trompe?! Tu dois bien savoir que les structures n'ajoutent AUCUN overhead lors de l'éxecutrion!

Kevin Kofler
a écrit : Évidemment que je préfère du code petit et rapide à du code gros et lent, et même du code gros et rapide à du code gros et lent. Mais je préfère du code petit et lent à du code gros et rapide.

Bon en bref tu vas arrêter de nous soûler quand on réécrit des fonctions déjà présentes dans ton AMS chéri?

> Arrête de parler sans rien comprendre !

Mais bien sûr ! pour toi, ceux qui ne sont pas d'accord avec tes idées ne comprennent rien !
Alors demande-toi pourquoi tu en as marre que je fasse des remarques. Je te donne la réponse : j'en fais parceque moi aussi j'ai marre de quelque chose.
En l'occurence, de ta mentalité de merde qui te fait croire que tu as quelque chose de supérieur aux autres, et à cause de ça tu passes ton temps à donner des ordres et à faire passer tes opinions pour des vérités, surtout au près des newbies (le plus grave c'est que tu ne sembles pas te rendre compte de la différence entre une opinion et une vérité)

Dites, si on arretait un peu de se faire la gueule?

Surtout que j'ai repondu a la question