Suite aux excellentes nouvelles de PpHd sur l'effacement de variables en flash, je peux implémenter une sorte de swap pour asTI68k. Je dis bien une sorte, parce que je ne me contenterai de swapper que ce qui appartient au programme. J'aurais pu me payer le culot de swapper tous les fichiers en RAM, mais je sais pas trop si c'est safe, à cause de ce fichu changement de handle à l'archivage (PpHd, change ça stp !). Bref, on se penchera dessus quand j'aurai encore plus de temps à perdre qu'à coder un assembleur inutile qui ne servira jamais sur une machine que plus personne utilise, et encore moins sous PedroM. Mais ça reste en tête.

Tiens, on va poster le code. En fait, les fonctions de (ré)allocation sont réécrites, pour être traitées si elles échouent. Tout ça n'est pas testé (même pas encore relu ! je suis pourtant du genre à relire 10 fois mon code avant le moindre run), je vois pas comment je pourrais faire vu que rien se s'assemble aujourd'hui.

On aura au passage noté mon retour à A68k (objectif bootstrap oblige), ainsi que l'adoption du PpHd comment's style, pour ceux qui sont habitués à le lire.

Rah je me rends compte à l'instant... J'ai fini d'implémenter tout ça, le boot du programme est fini, j'attaque donc... l'assemblage !!!

C'est quand même incroyable que TI, qui ne sort plus d'OS pour 68k, qui ne corrige pas les bugs dont sont infectés ses OS, qui ne signe plus les FlashApps qu'on lui envoie, se permette de mettre des bâtons dans les roues à qui veut divulger les moyens d'avoir des OS à jour et sur lesquels on puisse bosser (sans le faire perdre le moindre centime, précisons, et on peut même penser bougrement le contraire).

Qui plus est, TI attaque de manière déloyale, comme peut se le permettre un "ayant-droit" friqué face à des jeunes passionnés dépourvus de moyen. Les infos techniques qu'ils donnent sur les tenants et aboutissants des clés qu'on leur a cassées sont tout simplement fausses (cryptage de l'OS etc...).
Ou ils sont encore plus incompétents qu'on le pensait, à ne plus savoir ce qu'ils ont écrit comme softs, ou encore ils nous prennent pour des ignards. Dans les deux cas, ils sont à la ramasse.

Mais bon, que pourront-ils face au net ? Perdront-ils des mois à envoyer des DMCA un peu partout dans le monde ? On verra bien. En attendant, la diffusion assurant leur perte, allons-y :
RabbitSign, de Benjamin Moody, et Resign68k de Brandon Wilson vous permettront de signer ce que vous voulez.

Merci à eux et à tous les participants de ce projet !

PS : Lien vers le site de l'EFF qui invalide les actions de Texas.

Puisque je programme pour ne surtout pas finir mes programmes, encore moins pour releaser et surtout pas pour faire quelque chose d'utile, je vois les choses en très grand pour mon assembleur qui prend enfin un véritable goût d'arlésienne.
Puis tant qu'à faire dans le v4p0r, autant faire un magnifique nuage, pas un petit étron qui passera inaperçu. Il serait en effet dommage de ne pas être à l'honneur en 2042 quand même.

Alors on y va, asTI68k ce ne sera pas ça :
- assembleur multi-sources + linker
- compatibilité avec la plupart des directives de A68k
- compatibilité avec la syntaxe A68k et GNU as (au run-time, fichier par fichier)
- sortie : exécutables, binaires (pour incbin), archives (pour la gloire, vu que c'est déjà pas très utile, alors sur calc on en parle pas), hexa (pour trouver une raison existentielle à EExec).
- utilisation de la flash comme swap au cas où la RAM commence à fumer
- kerstub et nonel
- relogements divers et variés, mais pas compressés. BSS et toute cette mouise
- maquereaux
- exécution en flache comme d'habitude

Voilà. J'ai codé 3 kilos de ce futur non-monstre. Evidemment, j'ai commencé par le plus inutile, c'est à dire surtout pas par le moteur d'assemblage : j'ai parlé du parsing de la ligne de commande et de l'ouverture des sources.

J'utilise un header nommé config.h pour... la configuration des options qui détermineront le comportement par défaut du programme (switches d'assemblage, de linking, d'utilisation de la mémoire et autres imports de symboles).
Là c'est simple, il suffit de remplir les lignes de 0 et de 1 pour configurer ce qu'on veut. Facile.

Là où ça commence à être drôle, c'est que asTI68k se reconfigure au boot avec un fichier de configuration. Par défaut, il lira sa config dans system\asti68k (un fichier texte supportant tous les switches, suivis d'un petit 1 ou 0 suivant l'état qu'on veut leur donner). A noter que ce fichier accepte les commentaires sur toute la ligne ou en fin de ligne. Inutile donc indispensable, comme d'habitude. De même que le support des tabulations et d'autant d'espaces qu'on veut où on veut. Il fallait donc bien que je le fasse.

Comme ça suffit pas, on peut modifier dans config.h la manière dont ce fichier de conf est déterminé au run-time ! Ca peut être un fichier dans le répertoire courant, si on a défini un chemin nul (ce qui permet d'avoir un fichier de conf par projet), ou un fichier donné dans un répertoite donné si on a défini les deux. Complètement ridicule, mais asTI68k en est capable.

Pour être sûr qu'on puisse configurer le soft au cas où ces deux moyens ne suffiraient pas, on peut passer, entre le nom de l'assembleur et le premier source, des options globales qui seront alors appliquées à l'ensemble des fichiers. C'est pas beau ça ? Ca permet de rétablir ce qu'on avait configuré dans config.h, mais détruit à coup de fichier de conf, des fois que le remord nous envahisse.

Enfin, après chaque source, les options qui suivront avant le source suivant seront appliquées au dit-source. Ben oui, des fois que pris de regret, on se dise que finalement, la ligne de configuration écrite dans le fichier de conf pour overrider config.h était trop bien pour être écrasée dans les options globales ! Ca peut être important ça, non ? Non ? Et bien tant pis, c'est fait. Na.

Donc voilà, ça c'est fait comme dirait l'aut', l'ouverture des fichiers aussi, il y a tout ce qu'il faut pour pondre tout un babillage ennuyeux sur stdout et stderr, des éléments du parseur ont été écrits (et voilà, j'ai trouvé une utilité au fichier de conf !), j'ai même une chouette fonction qui trouve et détermine la position d'un mot dans une table en fonction des séparateurs pouvant suivre ce mot dans un source ! Ca c'est épatant, le parsing me faisant hautement braire, ça fait une bonne chose de faite.

Voilà voilà, le temps pas passé sur Steam me permet, en plus que d'avancer 27.32 fois plus vite que d'habitude (première estimation à la louche, à préciser par la suite), de poster un billet. C'est pas chouette ça ? Aller, j'y retourne.

719958345686847736367204386511604722971278844
802065351568433078413780508897143327301197055
213896058379936821537358230859192898504505926
1105298431035818727
=
223112452563762944318196304529739487547051016
7130210300957267082210173784611
*
322688553424014741501824839741010128636276112
8614350056368675111071170873486957

Juste comme ça, parce que j'aime les maths.

Voici donc la version finale de Extended Exec.

Ce programme permet donc d'éxécuter un binaire représenté par une chaine hexadécimale. Le binaire peut être ajouté à la VAT avant exécution, archivé, et même effacé si besoin est. Eexec supporte aussi le "dry-run", qui consiste à simuler l'appel sans exécuter le binaire argument.
La source hexadécimale peut être passée manuellement en ligne de commande, ou peut être contenu dans un fichier texte ou string.

Contrairement aux versions précédentes, le programme est un simple programme kernel, sans loader, sans self-modifying code, ce qui lui permet d'être exécuté archivé sans consommer un octet de mémoire. Il est également réentrant. Merci à PpHd pour l'extension RAM_THROW sur le handler de f-line, sans ça ça n'aurait pas été possible.

Il n'y a pas de page de man de fournie dans ce pack, on verra ça quand le-dit programme sera codé. En attendant, c'est sous GPL, donc il y a les sources de fournies, un script pour compiler sous Linux et un pour Windows, et le tout est à télécharger ici !

Ya pas à dire, parser une ligne de commande est toujours un régal !
Après avoir fait plusieurs types de parsings pour d'autres programmes, je trouve que celui-ci est très réussi, et du premier coup. C'est rare que je soit content d'un premier jet. Le code est clair, léger, évidemment rapide (asm oblige), et très maintenable. Ca serait facile de rajouter une option ou d'en virer une.

La validité de tout ce qui est entré est vérifié, les switches nécessitant un argument comme un fichier ou une valeur sont vérifiés dans la foulée, la cohérence entre les switches (ceux qui s'excluent ou ceux qui en nécessitent un autre) également.

Le corps du programme maintenant.

|================================================================== 
|	IV. Assembly !!! 
|================================================================== 
	clr.w	%d3					|# file to assemble : #0 
MakeObject:	 
	bsr	Src2Obj 
DontMakeObject: 
	addq.w	#1,%d3					|update # file to assemble 
	movea.l	SOURCE_TABLE_PTR(%fp),%a0		|&table 
	cmp.w	(%a0)+,%d3				|read number of files 
	bhi.s	EndOfObject				|ok, go to link 
		move.w	%d3,%d0				|# current file 
		mulu.w	#SOURCE.ENTRY_SIZE,%d0		|offset of data of the file to assemble in the table 
		adda.l	%d0,%a0				|&file to assemble 
		move.l	SOURCE.Flags(%a0),%d0		|read flag 
		btst.l	#OBJECT_DONE,%d0		|file already assembled ? 
		beq.s	MakeObject			|no, do it 
			bra.s	DontMakeObject		|else loop, but not ass

On passe à la phase d'assemblage ! Après cinq refontes, il était temps d'y arriver. Mais je suis perfectionniste, et quand j'ai une meilleure idée sur un truc déjà écrit, j'ai la manie de recomencer. Là, j'ai mis en place la structure des fichiers object et archive, la gestion des inclusions de headers et de sources (finalement c'est la même chose), des macros et des équivalences. C'est ambitieux, mais j'aime faire en grand (peut-être aussi pour ça que ça prend tant de temps). Mais autant faire en grand, c'est plus marrant.

Ca avance, le parsing de la ligne de commande est fini, et toutes les structures de données et variables sont prêtes pour commencer l'assemblage. Avant d'attaquer cette phase, il me reste à finir la table des opcodes pour chaque instruction. Je m'en tire avec 6 octets par instruction, ce que je trouve pas mal.

J'ai des kilos de doc rédigée qui attendent la mise en code. Une chose à la fois, je compte finaliser la première partie, ce qui me permet d'attaquer la suite avec sérénité.

Quelques screens, sachant que pour un soft en console, il n'y a rien de particulièrement excitant... pour certains ^^ Chez moi, l'excitation est limite physique

Et cette fois ça rox, plusieurs nouveautés :
- les appels vers graphlib ont été supprimés (je l'ai utilisée juste pour développer plus vite).
- L'exécution du programme se fait pratiquement entièrement en flash, et le programme de 4 ko ne consomme que ~270 octets au run-time !!!
- la taille du binaire a un peu baissé suite à quelques optimisations, mais c'est pas fini et je m'en fous un peu pour le moment.
- pas de nouvelles features à part ça.

Pour continuer à me donner du feedback (#jycrois# ), c'est ici : Téléchargement !

Bon, suite au congé paternité, l'arrêt maladie, donc ça code sec en ce moment. Nouvelle bêta ici : Téléchargement !

Cédant à mes démons habituels, le seul code non-PIC se trouve dans un loader de 250 octets . Malheureusement TIGCC ne sait pas gérer le flag read-only, donc je vais devoir hacker dans les binaires pour le mettre. Flemme de l'avoir pas encore fait, mais ya juste la doc kernelformat à lire.

Dernière chose, j'utilise graphlib__box/bigbox, je vais donc réécrire ces fonctions très simples pour exploser l'optimisation en mémoire . Et comme PedroM a un task switcher, ça sera très facile de vérifier ce qui est consommé.

Demain, je devrais en être rendu là.

Bon, vu que j'ai pas mal avancé sur le soft, je release une bêta, déjà sous GPL donc sources comprises. Téléchargement

Les graphismes ont été un peu retouchés par rapport à la news d'avant (en fait j'utilise plus DlgMessage )

Ce qu'on peut faire :
- régler les 4 flags
- paramétrer l'APD
- définir les répertoires TEMP et HOME
- définir un script éxécuté au boot

Ce qu'on ne peut pas encore faire :
- déterminer un path (PpHd : l'ordre des répertoires de la liste compte pour le path ?)
- définir les "Fast Keys" (F1-F8)
- définir des arguments locaux pour un script (PpHd, explique-moi, là je comprends vraiment pas quel est le but et comment ça marche ).

C'est pas sûr que je rajoute les deux derniers, étant donné que vu qu'il faut de toute façon se taper les commandes à la main, l'interface graphique n'est pas d'une grand utilité ici. Qu'en pensez-vous ?

Au passage, merci à PpHd de bien vouloir modifier PedroM pour que certains rom calls pas très clairement documentés aient un comportement plus AMS-like, ça m'évitera de faire des workarounds pour la suite.

J'ai besoin de feed-back, que ce soit au niveau fonctionnalité, graphisme, intuitivité, etc... N'hésitez pas à tester !

Je pense rajouter (puisque le format de menu le permet) une gestion dynamique des process de PedroM à base de ps/go/kill.
Qu'en pensez-vous ?