Work in Progress: Pyrix "Zero" - Page 3

Ca t'arrive d'imaginer qu'il peut y avoir des progs en assembleur de plus de 3 instructions ?

bah oui, la meilleur preuve est qu'il rajoute même des instructions inutiles dans ses programmes quand ils ne sont pas assez long

Hé Kevin, si ça t'embête tant que ça que A68k soit non libre, tu n'as qu'à écrire un autre assembleur, je pense pas que ça soit la chose la plus difficile au monde (chiant certes, mais moins que d'écrire un linker du style de celui de TIGCC)

Pollux
: Avoue que ce n'est pas la première fois qu'on te dit que c loin d'être la seule différence entre GAS et A68k...

Mais c'est celle dont tout le monde se plaint, le reste, ce sont des avantages!

Et les ":" après les labels ?

C'est fait exprès parce que c'est obligatoire pour avoir une syntaxe insensible à l'indentation.

Oui, et c'est tout l'intérêt d'avoir une syntaxe sensible à l'indentation Et justement, avec le patch que je t'ai proposé, tu peux avoir ta syntaxe insensible à l'indentation (en revanche, ce n'est pas insensible aux newline, mais c'est le cas aussi pour le préprocesseur C et tu ne t'en plains pas )

Quel patch? Le même que pour le maximum de lignes?

Et si tu codes proprement, même avec A68k, tu mets toujours les : après les labels! Si tu veux voir tes labels dans l'IDE, tu n'as pas le choix de toute façon.

Non, n'importe quoi, je vois pas pkoi c plus propre. Si votre IDE est mal faite, tant pis, mais moi personnellement je ne mets des ":" qu'après des labels globaux.

Si tes labels sont locaux, ne pas les avoir dans la liste des fonctions/labels de l'IDE est limite un avantage.

Et les labels locaux ?

0: bra.s 0b marche très bien ici.

Ca t'arrive d'imaginer qu'il peut y avoir des progs en assembleur de plus de 3 instructions ? D'ailleurs on voit bien ce qui se passe : pour les trucs en GAS un minimum long (routines de gris), tous les labels sont préfixés par un horrible truc avec des underscores de partout, alors qu'en A68k il suffit de mettre un '\'...

J'ai bien utilisé des 47: dans cbscanf, moi.

Et les commentaires avec moins de 4 caractères de délimiteurs (/**/) ?

Tu connais |?

OK. (et au passage ça empêche de se servir du OU logique dans les constantes...)

--bitwise-or. Mais faut choisir.

Tu peux patcher A68k pour qu'il fasse un s/^\s*(\w+/\1/ (s'il ne le fait pas déjà), tu ne vas pas me faire croire que tu n'en es pas capable.

Ce n'est pas ça qui résoudra le problème fondamental.

Qui est ?

Que la syntaxe est faite de partout pour être sensible à l'indentation. Par exemple: "The only values a label cannot take are the register names - A68k can distinguish between the same name used as a label, instruction name or directive, macro name, or section name."

Flanker
:

Ca t'arrive d'imaginer qu'il peut y avoir des progs en assembleur de plus de 3 instructions ?

bah oui, la meilleur preuve est qu'il rajoute même des instructions inutiles dans ses programmes quand ils ne sont pas assez long

GoldenCrystal
: Hé Kevin, si ça t'embête tant que ça que A68k soit non libre, tu n'as qu'à écrire un autre assembleur, je pense pas que ça soit la chose la plus difficile au monde (chiant certes, mais moins que d'écrire un linker du style de celui de TIGCC)

J'y ai déjà pensé... Mais l'assembleur GNU marche très bien, donc je ne vois pas trop l'intérêt.

Kevin Kofler
:

Pollux
: Avoue que ce n'est pas la première fois qu'on te dit que c loin d'être la seule différence entre GAS et A68k...

Mais c'est celle dont tout le monde se plaint, le reste, ce sont des avantages!

C'est un avantage de ne pas pouvoir utiliser des labels locaux dignes de ce nom ?

Et les ":" après les labels ?

C'est fait exprès parce que c'est obligatoire pour avoir une syntaxe insensible à l'indentation.

Oui, et c'est tout l'intérêt d'avoir une syntaxe sensible à l'indentation Et justement, avec le patch que je t'ai proposé, tu peux avoir ta syntaxe insensible à l'indentation (en revanche, ce n'est pas insensible aux newline, mais c'est le cas aussi pour le préprocesseur C et tu ne t'en plains pas )

Quel patch? Le même que pour le maximum de lignes?

Non, celui de la suppression du whitespace avant les labels... (patch que je t'ai proposé de faire, pas d'appliquer, hein )

Et si tu codes proprement, même avec A68k, tu mets toujours les : après les labels! Si tu veux voir tes labels dans l'IDE, tu n'as pas le choix de toute façon.

Non, n'importe quoi, je vois pas pkoi c plus propre. Si votre IDE est mal faite, tant pis, mais moi personnellement je ne mets des ":" qu'après des labels globaux.

Si tes labels sont locaux, ne pas les avoir dans la liste des fonctions/labels de l'IDE est limite un avantage.

Ben oui, mais je vois pas ce qui en empêche la coloration syntaxique...

Et les labels locaux ?

0: bra.s 0b marche très bien ici.

Ca t'arrive d'imaginer qu'il peut y avoir des progs en assembleur de plus de 3 instructions ? D'ailleurs on voit bien ce qui se passe : pour les trucs en GAS un minimum long (routines de gris), tous les labels sont préfixés par un horrible truc avec des underscores de partout, alors qu'en A68k il suffit de mettre un '\'...

J'ai bien utilisé des 47: dans cbscanf, moi.

Et t'en es fier ?
Alors les *features* des labels locaux à la GAS, c'est :
- les numéros de label sont 100x plus parlants que des noms, c'est bien connu (d'ailleurs c'est pour ça que le Basic est mieux que le C)
- qd tu bouges du code, ça te fait hyper plaisir d'avoir à modifier les directions des sauts de tous tes labels (puisqu'avec les labels à la GAS, il faut spécifier les directions de chaque saut )

Et les commentaires avec moins de 4 caractères de délimiteurs (/**/) ?

Tu connais |?

OK. (et au passage ça empêche de se servir du OU logique dans les constantes...)

--bitwise-or. Mais faut choisir.

Hélas... Dans a68k il ne faut pas choisir.

Tu peux patcher A68k pour qu'il fasse un s/^\s*(\w+/\1/ (s'il ne le fait pas déjà), tu ne vas pas me faire croire que tu n'en es pas capable.

Ce n'est pas ça qui résoudra le problème fondamental.

Qui est ?

Que la syntaxe est faite de partout pour être sensible à l'indentation. Par exemple: "The only values a label cannot take are the register names - A68k can distinguish between the same name used as a label, instruction name or directive, macro name, or section name."

Ben non, si tu veux être insensible à l'indentation, tu peux très bien rajouter le ":" (qui n'est pas gênant dans GAS, mais qui dans A68k devient la mer à boire )
Perso je préfère être sensible à l'indentation et ne pas mettre de ":", en tout cas. Et tout le monde serait heureux avec la syntaxe A68k

Kevin Kofler
:

GoldenCrystal
: Hé Kevin, si ça t'embête tant que ça que A68k soit non libre, tu n'as qu'à écrire un autre assembleur, je pense pas que ça soit la chose la plus difficile au monde (chiant certes, mais moins que d'écrire un linker du style de celui de TIGCC)

J'y ai déjà pensé... Mais l'assembleur GNU marche très bien, donc je ne vois pas trop l'intérêt.

Il marche très bien, mais il a une syntaxe de merde...

Enfin bon, le fait demeure que GAS est deprecated car il utilise une syntaxe non standard ©

^^

C'est fini ce HS ?

Apparemment oui puisque Kevin préfère ne pas répondre à ./65

*1. Il y a d'autres plateformes 68k que les calculatrices TI! Plein d'autres! Et ils utilisent toutes ces syntaxes depuis des décennies.*

, et c'est bien suffisant pour moi.
Mon code risque d'être lu par des codeurs connaissant Linux/m68k ou NetBSD/m68k.
Et rien que pour cela je mets A68k à la poubelle. (Mais y'a pas que ça... Kevin a tout dit.)

C'est comme Linux sur PC.
J'utilise as pour la même raison que sur le noyau Linux on utilise as et non MASM.

Quoiqu'il en soit je ne veut pas davantage de polémique ici. Si j'en reprends un à troller un des 2 assembleurs
ou à faire un post gratte-ciel ---> kick.

Le projet rencontre de sacrées difficultés (au niveau du boot surtout, et un peu pour le système de fichiers).

Mais y'a quand même des bonnes nouvelles. J'ai trouvé l'équivalent d'un TSS pour 68000,
ce qui complète les descripteurs de tâches ----> Le scheduler est terminé.

Billy Charvet :
Quoiqu'il en soit je ne veut pas davantage de polémique ici. Si j'en reprends un à troller un des 2 assembleurs ou à faire un post gratte-ciel ---> kick.

Tu ne peux pas, le kick par les auteurs a été supprimé.

, yAro a fumé du crack ????

Bon, une petite question pour le système de fichiers:

J'envisage d'utiliser une méthode proche de
l'allocation par liste chaînée indexée, c'est-à-dire comme la FAT.

J'ai prévu de réserver le premier bloc de 64 Ko de Flash de base2
pour le système de fichiers (table des inodes).

Dans l'état actuel des choses, avec un support de fichiers de 64 Ko max,
un inode prendrait 8 octets, et demanderait ensuite un nombre
variable de structures d'indirection (autant que le nombre de parties
constituant le fichier), tenant chacune 6 octets (adresse du début
de la prochaine partie du fichier, plus taille de cette partie)

Je suggère donc que le premier bloc soit réservé entièrement pour
les infos du système de fichiers (ça permet à peu près pareil
que l'AMS, 2000 fichiers, mais occuppant plus de 1.6 Mo)

Bon la question qui se pose c'est que je pense utiliser le dernier bloc
de Flash de base2 comme endroit de stockage temporaire pour les
opérations (comme pour... la défragmentation ),
et les avant-derniers pour les exécutables. (1 bloc de 64 Ko chaque)

Ainsi si on a qu'une tâche en cours (sauf les taches systèmes, hein)
l'avant-dernier bloc de Flash est réservé pour la section .text du programme.
(Les sections .data et .bss sont quant à elles relogées en RAM).

Si on passe à davantage de tâches:
- Certaines n'ont pas besoin de ça, les tâches systèmes devraient
être en RAM (le scheduler surtout)
- Enfin les programmes sous Pyrix ne se dupliqueront pas par fork()
mais par vfork(), et donc gardent le même espace que le père,
libre à eux de le modifier.
- Enfin, en multi-tâches on ne devrait pas dépasser 4 tâches...

Donc en comptant en plus les librairies, ça peut faire plus de 360 Ko
réservés à la fin de la Flash... Moué c'est lourd, mais il restera
toujours 1.5 Mo à l'utilisateur...
De plus je compte journaliser le système de fichiers.
J'aimerais savoir ce que vous pensez de tout ça.

J'aimerais savoir ce que vous pensez de tout ça.

Et la durée de vie de la mémoire flash ?

C'est de la NAND ?
Dans ce cas, 100 000 à 1 000 000 de cycles
d'effacement je crois que ça va quand même non ?
Sinon ben exécution en RAM...

1 bloc de 64ko par exécutable ?

Kitsune :
C'est de la NAND ?
Dans ce cas, 100 000 à 1 000 000 de cycles
d'effacement je crois que ça va quand même non ? Sinon ben exécution en RAM...

C'est plus 100 000 que 1 million.. et ceci est le nombre d'effacement.

Faire un systeme de fichier en flash est tres bien, mais il faut qu'il soit fait pour (tel l'archive d'ams) moins on efface, mieux on ce porte (d'ou le GC qui ne se fait que en dernier recours)

bref un format type VFS/FAT pour la flash est tres mal adapté...

Bon, ben quoi... un remix de la VAT capable d'avoir des (vrais) répertoires (pitoyable ) ?

Il faut que tu fasses un systeme qui minimise le nombre d'effacement.

Oué, ça j'ai compris, mais c'est pas ce qui m'arrange....
Bon, je vais réfléchir...
Bon... soit j'utilise la VAT pendant un temps,
soit je me tourne vers JFFS2. Ca vous va comme ça ?

Pyrix avance...
Il fonctionnerait déjà de manière autonome d'ailleurs... si j'avais moins la flemme.

Pyrix repose sur une architecture micronoyau profitant des avantages de la TI pour
ressembler à un exonoyau. Le scheduling se fait hors du noyau, en fait toutes les
tâches se font en userland, on est donc plus proche de L4 que de Mach.

(Mais comme c'est pas du C++, que c'est optimisé sur TI et que la prog sur
TI s'avère bien plus simple que sur un PC, les micronoyaux sont vraiment ultra-légers
et performants.)

Il y aura 2 (voir 3) micronoyaux, qui se lancent puis appellent des serveurs en userland
pour la gestion des appels systèmes, l'allocation de mémoire etc...

Le premier est Nox, et fonctionne sous l'AMS.
Sa tâche est simple: on lance un programme, le bootloader Pandora, avec comme arguments
un noyau (Nox) et un ramdrive,
qui sera passé au noyau comme argument.
(mais j'ai pas encore développé une interface
pratique pour les paramètres du noyau...)

Pour l'instant, Pyrix se contente de cohabiter avec l'AMS, et utilise la VAT.
Le format d'exécutables de Pyrix est le PXF, un format que j'ai mis au point
en simplifiant le COFF, mais qui permet bien plus que le format AMS. (Notamment,
de vrais noms de sections).

Les ramdrives sont les ramdisks de Pyrix. Ils ont un format simple permettant une
arborescence avec des dossiers etc, sur peu de place.

Nox est un exécutable. Une fois lancé il prend le ramdrive qu'on lui a fourni et
lance tous les exécutables contenus à l'intérieur.
Le ramdrive en question contient Ouranos, l'ensemble des serveurs,
et se trouve sur toutes les versions de Pyrix (en stand-alone, ce sera le même).

L'avancement du projet:

Ma première étape consiste à implémenter un système mono-utilisateur permettant
la compilation de sources C/POSIX. Par des macros, je remplace les appels inutiles
(ex: getuid, getgid etc) car on est toujours l'utilisateur root, et du groupe wheel.
Je vise dans un premier temps à parvenir à implémenter/remplacer par des macros
(selon le cas) tous les appels systèmes de UNIX Time Sharing System version 6.

Ensuite je prendrai le parcours de Linux (sans en utiliser la source)

Les sources sont sous licence BSD, surtout écrites from scratch, mais je n'hésiterai
pas à prendre du code 4.4BSD Lite 2, ou de ses descendants (ex: FreeBSD) si
besoin est. Toutes les bases du système s'orientent vers la philosophie BSD.
Je ferai donc un shell avec une syntaxe C-shell, et ainsi de suite.

Les logiciels prévus autour de ça sont:
- un shell, peut-être inspiré de msh, mais avec une syntaxe C-shell.
- saphir, un langage de script que je fais moi-même.
J'en ai déjà terminé une préversion, Mona, un langage applicatif monadique.
(en gros, des
with a
+ 5
* b
cos a
- 20
etc..)

Mais pour l'heure:
Y'a que Pyrix, le format PXF marche pas, (pas encore mis l'export dans ld-tigcc)
donc le ramdrive non plus, comme je vais en présenter une démo à Alchimie 4,
ce sera Pyrix Zero, il utilisera donc le format AMS et sera d'un seul bloc, monolithique.
(Mais à l'intérieur, c'est programmé de façon à marcher différement bien sûr)

C'est donc une démo avant tout, ensuite je commencerai une alpha *sérieuse*

Tiens ya ce topic qui est encore ouvert

Mon cher ami Billy Charvet Ne démarrons pas a troller sur un pseudo

Peu tu nous expliquer CLAIREMENT (Non elle ment c'est sur) ce qu'est pour toi un EXOKERNEL stp ?
et quelle sont les 3 fonctionnalité d'un exokernel ?

Et qu'est-ce qui le différencie FONDAMENTALEMENT d'un MicroKernel ou d'un simple kernel monolithique

merci (et pas de copier coller ou de traduction d'une doc )

Mais nan Godzil, faut faire ça par mail, il s'est cassé de yN

heu... quelqu'un peu m'expliquer l'utilité d'un tel remontage ?

Tiens ya ce topic qui est encore ouvert

Plus maintenant.

Mon cher ami Billy Charvet

On est pas amis.

Ne démarrons pas a troller sur un pseudo

(Vaut mieux pas)

Peu tu nous expliquer CLAIREMENT (Non elle ment c'est sur) ce qu'est pour toi un EXOKERNEL stp ?

Commence par apprendre à écrire, et cherche toi-même puisque tu ne semble pas le savoir.

et quelle sont les 3 fonctionnalité d'un exokernel ?

Le Père, le Fils, et le Saint Esprit.

Et qu'est-ce qui le différencie FONDAMENTALEMENT d'un MicroKernel ou d'un simple kernel monolithique

T'as la mémoire courte, je n'aime pas me répéter.

merci (et pas de copier coller ou de traduction d'une doc)

De rien. Et pour la doc je te laisse regarder.


squale92 > Peut-être Godzil ?