C'est fun - Page 1

	.xdef	_ti92plus
	.xdef	_main
	
	.include	"kernel.h"
	
_main:	movea.l	(%sp),%a0
	jmp	(%a0)

Ca plante pas, niveau optimisation c'est génial. Merci PpHd

(je sais pas comment tu fais pour supporter la syntaxe ignoble de cet assembleur, perso )

(l'habitude en fait, au début j'utilisais le --register-prefix-optional, mais maintenant je m'en fous, je tape les registres avec le % naturellement ^^)

J'espère juste que tu n'apprendras pas ça comme ça à tes gamins

Et quel est l'intérêt par rapport un rts, à part montrer que PreOs est robuste face à 1. la restauration incorrecte de la pile et 2. les registres détruits (mais bon, s'il ne supportait pas %a0, un registre call-clobbered, étant détruit, ça craindrait)?

Ximoon -> Trop tard, trop tard ... ^^


Kevin, pour ça :

_main:	jsr	pexeclib__0000			|exec main part, pushing &data
	.long	pedrom__printf,kernel__Exec	|system calls

pexeclib__0000:
	movea.l	(%sp)+,%a0				|&Data
	movea.l	(%sp)+,%a1				|return adress of pexec
	move.w	(%sp)+,%d3				|get ARGC
	movea.l	(%sp),%a2				|get ARGV
	lea.l	-STACK_FRAME_SIZE(%sp),%sp		|create stack frame
	movea.l	%sp,%fp					|set frame pointer

Plus la peine d'aller chercher à x(%sp) les arguments, donc c'est plus court comme ça. La pile est recouverte par le stack frame dans tout le programme, mais c'est pas grave.
D'autant plus que je leak une taille variable et indéterminée (mais limitée) de pile dans le programme, mais je m'en fous, PreOS fait bien son boulot.

A ne pas utiliser sur une autre plate-forme (mais ça, tu en étais déjà parfaitement conscient)

Ni sur AMS

Je ne comprends toujours pas ce que tu nous ponds. Tu nous places l'adresse de retour dans %a0 et tu y sautes, quel rapport avec le snippet du ./6?

Le code du ./1 n'est qu'un exemple, un test case.

Dans le programme global, je lis les arguments dont j'ai besoin sur la pile, dont l'adresse de retour que je stocke dans mon stack frame. A la fin, je lis cette adresse et j'y fais un jmp. Je gagne pour aller lire les arguments sur la pile : pas de offset(an), mais des (an) directement, -2 octets à chaque fois.

(Merci Zerosquare : )

Petit trick du moment :

	movem.l	d3-d5/a2-a3,-(sp)
...
	;-----------------------------------------------------------------------
	;	20 bytes have been pushed on the stack
	;	- 8 bytes are popped with addq
	;	- 12 bytes are popped by trashing d0-d2
	;-----------------------------------------------------------------------
	addq.l	#8,sp
	movem.l	(sp)+,d0-d5/a2-a3
	rts

Et voilà comment popper plus de 8 octets de pile en deux octets.

Et tu as économisé 2 octets en rendant ton code illisible.

Arrête, c'est admirablement commenté dans un anglais on ne peut plus académique

2 octets de moins, mais combien de cycles en plus ?

Folco (./11) :
Petit trick du moment :

	movem.l	d3-d5/a2-a3,-(sp)
...
	;-----------------------------------------------------------------------
	;	20 bytes have been pushed on the stack
	;	- 8 bytes are popped with addq
	;	- 12 bytes are popped by trashing d0-d2
	;-----------------------------------------------------------------------
	addq.l	#8,sp
	movem.l	(sp)+,d0-d5/a2-a3
	rts

Et voilà comment popper plus de 8 octets de pile en deux octets.

Je propose:
movem.l d3-d5/a2-a3,-(sp) ... ;----------------------------------------------------------------------- ; 20 bytes have been pushed on the stack ; - 8 bytes are popped with addq ; - 12 bytes are popped by trashing d0-d2 ;----------------------------------------------------------------------- movem.l d0-d2,-(sp) movem.l (sp)+,d0-d5/a2-a3 rts

Zerosquare -> sûr, mais on a pas toujours besoin de vitesse

(je n'ai fait aucun calcul ceci dit mon code est probablement incorrect, j'ai juste eu envie de consommer encore plus de cycles )

en ARM on fait:

func:
push lr
(bidouille)
pop pc

mignon aussi

Tiens c'est rigolo, je ne vois pas de spécification de longueur dans tes instructions
Et sinon, il veut dire quoi le "pc" du pop ? "sp" j'aurais compris, mais "pc" ça fait plus "program counter".

C'est le PC oui en effet, et pas de spécification de longuer parceque un ARM ne lit et ecrit que des mots de 32bit en mode ARM, et 16bit en mode thumb.

Ok, mais alors "pop pc", ça veut dire quoi ? Ca pop ce qu'il y a sur la pile dans pc, ça ferait donc un rts ?

Oui, le rts n'existe pas.

Ok, marrant

(Et au passage, LR c'est link register, je viens de vérifier vu que c'est un peu loin dans mes souvenirs — http://www.keil.com/support/man/docs/armasm/armasm_dom1359731145503.htm)

Un équivalent de link/unlk du 68k donc, merci bien.

ça me rappelle qu'il faudrait que je commence à apprendre l'ARMv7, je m'étais offert la doc au début d'un vap0rware d'émulateur GBA, j'aimais bien la simplicité

en fait en ARM quand tu fais un call ca fait

pc actuel -> lr (LINK register)
puis
destpc -> pc

si t'as pas d'appels supplémentaires tu peux juste faire mov pc,lr pour retourner a la fin
mais en général une routine generee va pusher le PC de retour (LR) puis popper PC

L'arm fait beaucoup de raccourcis dans ses codages

et SURTOUT c'est une archi load/store, donc ses instructions habituelles ne causent QUE avec des registres. impossible d'ajouter ou mov entre méḿoire et registre, juste des registres.

add rdest,rsrc1,rsrc2

les load et store se font avec des instructions dédiées
ldr/str pour des mots de 32 bits
ldrw/strw pour des mots de 16 bits
ldrb/strb pour des mots de 8 bits
et ldm/stm (avec des options incrémentations d'index) pour les load/store multiples, pas seulement a destination de sp d'ailleurs.

en mode ARM chaque instruction a une taille de 32 bits, peu efficace, mais chaque instruction peut être rendue indépendamment conditionnelle.

en mode THUMB chaque instruction a une taille de 16 bits et ne peut utiliser que la moitié des registres
Thumb contient donc des instructions de chargement des registres inaccessibles normalement
Il y a aussi le Thumb 2 qui a des instructions de 16 ou 32 bits pour faciliter le codage
un bit du SR donne le mode actuel
En mode ARM, le PC est aligné sur 2 (finit par zéro), et sauter a un PC impair switche en mode thumb (pour lequel le PC est toujours aligné sur 2, mais le LSB est à 1 pour indiquer le mode thumb.

Et dans tous les modes charger des constantes était chiant avant le thumb2 qui a movw et movt pour charger 32 bits en 2 instructions.

Ca a l'air mignon tout ça.

vi!

Franchement faire de l'ARM c'est sympa