Propreté du code - Page 1

Suite à ce message de Ximoon dans le topic d'arithmétique :

Malheureusement, le code d'affichage de message, de log, de timing, et tout, est mélangé au code de calcul, et ça, ce n'est pas bon.

Je me pose une quetion. Typiquement, en assembleur, je me tape des trucs comme ça :

		pea.l	StrDefaultConfig(pc)		; File used
		pea.l	StrDefaultConfigFile(pc)	; Disp that we use a default file
		bsr	Print2Stdout
		addq.l	#8,sp
		lea.l	StrDefaultConfigSymStr(pc),a0	; Default config file
		bra.s	\Next				; And search for it

Donc sur 6 lignes de code, il y en a 4 "efficaces", les 4 autres servant à gérer une sortie. En clair, ça fait dégueulasse à l'oeil (déjà j'aime pas, j'aime bien le code "beau"), puis c'est le bordel opur relire, maintenir, corriger etc...

La question : Qu'y a-t-il comme solution ?

J'ai pensé à utiliser un trap :

	moveq.l	#OUTPUT_012,d0
	trap	#14

Et en fonction de OUTPUT_xyz, on va pousser la chaine format qui va bien, la sous-chaine truc et l'entier bidule pour afficher ce qu'on veut.

Maintenant, j'aimerais asvoir comment on fait dans un vrai beau programme écrit par un bon codeur ? J'ai pratiquement aucune expérience de ce côté en fait

Une macro peut-être, pour gagner en lisiblité ? Parce que j'ai aussi pensé à une autre solution, basée sur l'int 1 et une pile FIFO :
PRINT Chaine1, chaine2, entier1
Avec PRINT une macro qui fout les données voulues dans un buffer servant à l'int 1, qui va dépiler et ajuster le pointeur de pile. PRINT met aussi un numéro dans un derigstre (au pif, d7), pour savoir qu'elle a du boulot, qu'elle doit reagrder sa pile et bosser. Puis elle refout d7 à 0 à la fin. (inconvénient : lors des romcalls ^^)

Change de language, l'ASM n'est que rarement fait pour etre lisible et "beau" ^^

Certes, mais avec des macros on peut arriver à avoir de l'ASM bien propre, et en plus ça raccourcit le code

Tu devrais chercher de ce côté-là, y'a des trucs bien sympas à faire (comme "créer" de nouvelles instructions, par exemple). Rien qu'une macro qui génère toute seule les bouts de code que tu utilises régulièrement, c'est un gros plus.

Rien ne vaux faire une VM pour faire de nouvelles instructions (ou la)

Godzil (./2) :
l'ASM n'est que rarement fait pour etre lisible et "beau"

Tu rigoles ? Bien écrit, je te l'encadres dans le salon

Sinon c'est mignon tes liens

En fait le sens de mon message, c'est que pour qu'un code soit plus compréhensible, maintenable, portable, etc, une bonne façon de faire est d'isoler les différentes parties du code en module.
Donc : c'est mieux d'avoir un groupe de fonction bien défini qui ne fait que des maths, un autre bien défini qui ne fait que du log, etc, ainsi il est plus facile à quelqu'un qui voudrait, disons, porter la partie maths du C vers le CUDA d'intervenir.
Après, s'il y a plus d'une ligne de commentaire par millier de ligne de C, c'est pas mal aussi.

Godzil (./2) :
Change de language, l'ASM n'est que rarement fait pour etre lisible et "beau" ^^

C'est clair.

Folco, en C, ton code ne ferait qu'une ou deux lignes. Il est déjà le plus compact possible, tout est déjà factorisé en des fonctions. Le problème est que l'assembleur rend même l'appel d'une fonction quelque chose d'apparemment très compliqué quand c'est tout bête.

Je suis nul en C ...

Problème principal : j'aimerais bien écrire en C en fait, mais ya pas de header kernel, ni pour PreOS ni pour PedroM. Et ces fichiers là utilisent des notations à la con et des symboles que je vais pas assez connaitre pour arriver à les ré-écrire moi-même...

Par exemple, je fait comment pour faire un pedrom:rintf ? En assembleur, c'est facile... Puis en C, je sais pas gérer la mémoire, le lieu d'exécution et différentes contraintes...[nosmile]

c'est quoi pedrom:rintf ? un rom call? tu l'appelles comment?

PedroM contient une une dll appelée "pedrom". Son appel relogé produit un relogement kernel habituel. Voir ici pour voir tout ce qu'il y a dans cette lib : topics/123645-headers-for-pedrom#11

ah desole je connais pas grand chose au kernel
je vais apprendre en meme temps que toi

Ben pour faire vite, au niveau développeur, le kernel apporte juste un ensemble de fonctions ou de variables (les ramcalls) qu'on appelle comme des romcalls. Ca va pas chercher plus loin.
(Après, c'est la surpuissance de ces fonctions qui en font un truc génial ^^)

Je pense avoir trouvé la solution :

Une macro du genre : THROW_STDOUT/STDERR

THROW_STDOUT	macro
 	trap #14			; Il est libre ce con je crois
	dc.w \1			; Un numéro de message
endm

Avec \1, on calcule un offset dans une table de sauts, puis on saute vers la routine kivabien pousser cekilfo sur la pile, dépiler etc...

Ca vous parait bien ?

Tiens, comment faire ce truc ?
TRUC equ Print2Stdout-Print2Stderr
J'aimerais définir des pseudo-constantes dans un header, en fait un offset fait de différences d'adresses, pour utiliser ça dans d'autres fichiers. Ya un moyen ?

ok

l'appel de routines C dont on connait l'adresse peut se faire avec des operations atroces sur des casts de pointeurs, je te renvoie vers la definition de ROM_CALL dans les headers de gcc4ti

Voilà, ça fait tout de suite mieux :

		pea.l	StrDefaultConfig(pc)		; File used 
		pea.l	StrDefaultConfigFile(pc)	; Disp that we use a default file 
		bsr	Print2Stdout 
		addq.l	#8,sp 
		lea.l	StrDefaultConfigSymStr(pc),a0	; Default config file 
		bra.s	\Next				; And search for it

=>

		THROW_STDOUT	0
		lea.l	StrDefaultConfigSymStr(pc),a0	; Default config file
		bra.s	\Next				; And search for it

Folco (./9) :
Problème principal : j'aimerais bien écrire en C en fait, mais ya pas de header kernel, ni pour PreOS ni pour PedroM.

Il me semble que PpHd a écrit des headers correspondant à la librairie standard du C.
Regarde les exemples dans le répertoire pedrom/example.

Bien vu. J'aavis essayé avec, ça ne marchait pas, PpHd m'en a renvoyé une version modifiée, j'arrivais pas à faire ce que je voulais. Je plaide coupable, je ne lui ai pas fait suivre mes tests... Et sinon, PreOS fournit un header C également.

Il faut aussi savoir que TIGCC propose une implémentation portable (compatible AMS et PedroM) des fonctions comme printf, donc l'intérêt de gérer les versions de PedroM est assez limité.

Si ça economise de l'espace memoire/flash

Kevin Kofler (./20) :
Il faut aussi savoir que TIGCC propose une implémentation portable (compatible AMS et PedroM) des fonctions comme printf, donc l'intérêt de gérer les versions de PedroM est assez limité.

A partir du moment où l'on programme uniquement pour PedroM, il serait con d'importer une fonction built-in.

Mais il n'y a que toi à vouloir programmer uniquement pour PedroM.

Peut-être, mais je ne vais pas être con sous prétexte que je suis le seul à coder uniquement pour PedroM (coder pour AMS fait perdre un paquet terrible de fonctionnalités...)

Enfin c'est pas non plus un signe flagrant d'intelligence de passer un temps fou à programmer tout seul sur une plate-forme que personne n'utilise . Ceci dit, c'est un avis très perso...

Toi mon bonhomme, tu vas te faire voir