AS, il en est où ? - Page 9

J'ai jamais compris comment il faisait pour avoir autant de download. C'est dingue, non ?

Les newbies ne savent pas ce qu'est UniversalOS, alors que DoorsOS traîne de partout (les programmes qui circulent de machine à machine dans une école sont souvent très vieux) et que c'est le kernel pour lequel la plupart des programmes pour kernel ont été écrits à l'origine (et qui a donné le nom du format - cf. les répertoires doorsos sur ticalc.org).

Mais ca explique pas reellement le nombre absolument afferant de download !
Ou alors etre newbies est quelque chose hors de ma portee conceptuelle.
[edit]Edité par PpHd le 30-01-2002 à 17:11:41[/edit]

Nitro : Bravo Mais ça ne vaut pas GTC... En attendant c'est déjà pas mal !

partout, c'est écrit Utilsez DoorsOS (dans la majeure partie des readme), ou DoorsOS-compatible...
=> personne ne tente UniversalOS (sauf les passionnés, qui s'y connaissent vraiment !)

squale92 : Tu as avancé la doc ?
Je t'envoie la nouvelle version corrigée de la lib ?

je veux bien la version corrigée de la lib.
la doc... hélas non mais je respecterai mon délai du début des vacances : ça sera finit avant la fin de la première semaine. (j'ai un gros truc d'éco à rendre av les vacances => je pourrai pas ce WE)

>Mais ça ne vaut pas GTC

Ouais mais "bizarrement" plus de monde utilise CC à l'heure actuelle que GTC...

Ok je vais t'envoyer ça, format on-calc et PC

Pour le délai : c'est toi qui l'as fixé, moi j'ai pas vraiment besoin de l'avoir si tôt

héhé...
j'aime beaucoup le "bizarement" (lol)
put1, j'ai hate que le WE arrive !!!!!!!

Nitro : c'est p

Nouvelle version de CC, avec gestion de #include, et gestion d'erreurs amélioré...
http://darkclem.free.fr/cc.zip

Cool. Au fait, j'ai redige une doc sur le format kernel. Elle sera distribue avec le prochain Preos des que j'aurais corrige qqs bugs (si j'y arrive )

si quelqu'un écrit un petit programme avec CC, même un truc de test se serait sympa qu'il foute les sources sur le forum
merci

Un petit programme simple (de test) :
Pour bien voir l'indentation, mettre la skin par défaut

csrc :

main()
{
ooooochar *test="test";
ooooochar buffer[20];
oooooint a = 1;
oooooa<<=1;
oooooFontSetSys(a);
ooooofor(a=0;a<=5;a++)
ooooo{
oooooooooosprintf(buffer,"Iteration : %d",a);
ooooooooooDrawStr(0,0,buffer,4);
ooooooooooST_helpMsg(buffer);
oooooooooongetchx();
ooooo}
}

Et ceci après quelques modifications dans ams_c :
nolist
old_ams
_ST_helpMsg = -230
_ngetchx = -81
_clrscr = -414
_sprintf = -83
_DrawStr = -425
_FontSetSys = -399
; etc ...
list
[edit]Edité par ZdRUbAl le 31-01-2002 à 13:54:08[/edit]

ExtendeD:

>move.l #FinRoutine-DebRoutine,d0 renvoie dans d0 une valeur fausse
>si on utilise plus de 1 label local dans une source, les autres labels locaux génèrent une erreur

Je n'arrive a reproduire aucun des deux bugs... tu peux m'envoyer un exemple ?

>si on utilise plus de 1 label local dans une source, les autres labels locaux génèrent une erreur:
Mmm, peut-être que je n'ai pas tout compris aux labels locaux, mais y'a quand même des trucs bizarres:

Label:
 dbra d0,Label

>ca passe sous as, mais pas sous tigcc. Pourquoi pas sous tigcc?

Label1:
 dbra d0,Label1
Label2:
 dbra d0,Label2

>ca plante à la fois sous tigcc et as. (?)

Label1:
 bra Label1
Label2:
 dbra d0,Label2

>ca passe sous tigcc, et ca ne passe pas sous as. Pourquoi maintenant tigcc accepte ca?

Si quelqu'un pouvait donner une petite explication sur les labels locaux, ca serait bien.


>move.l #FinRoutine-DebRoutine,d0 renvoie dans d0 une valeur fausse
Compile ça:

move.l #End-Start,d0
rts
Start:
nop
End

et regarde ce que ca donne avec db92. On devrait avoir 2 dans d0.

[edit]Edité par ExtendeD le 31-01-2002 à 21:42:56[/edit]

Les labels locaux ne passent pas, même entre "pre". Tous les exemples avec "Label1" et "Label2" doivent normalement être précédés d'antislash.

Ok, j'ai trouvé d'où viennent les deux problèmes, et ça va etre vraiment tres compliqué à corriger
En attendant, évitez d'utiliser les labels locaux, et les calculs sur labels relogeables.

Sous TIGCC? Tu veux dire sous A68k? (Il y a aussi GNU as dans TIGCC.)
Je vais voir ça.

J'ai corrigé le problème avec les labels locaux... mais pour l'autre probleme c'est un peu moins evident, et à la veille d'un partiel de physique je v pas trop passer des heures sous VTI
AS

Pour l'autre problème c'est pas trop gênant, on sépare l'operation en 2 instructions, et c'est bon. Le truc c'est que quand ça m'est arrivé, je mis du temps à comprendre d'où venait le bug.


Kevin : euh oui, a68k.

En effet, ça bogue dans A68k. Il va falloir que je repasse ça sous le débogueur (Insight) pour comprendre ce qui se passe. Bref, encore une session de débogage.

Vous etes sur que ca plante sous a68k ? J'ai deja tape es codes similaires qui s'assembalit parfaitement. Par contre une autre, j'ai eu un add.l d0,d0 qui s'est transforme an add.b d2,-(a2) (C'est pas ta version KK).

> Kevin (cf. post 2^8)
Pourquoi int test(x) int x; ?
Je ne connais pas trop le C K & R, mais là ta fonction ne renvoie rien ...

>PpHd:
>Vous etes sur que ca plante sous a68k ? J'ai deja tape es codes similaires qui s'assembalit parfaitement.

C'est peut-être parce qu'il n'a pas mis de label global avant. Je vais regarder ça en détail.

>ZdRUbAl:
>Pourquoi int test(x) int x; ?
>Je ne connais pas trop le C K & R, mais là ta fonction ne renvoie rien ...

Tu as raison, j'aurais probablement pu mettre void.
[edit]Edité par Kevin Kofler le 01-02-2002 à 18:08:08[/edit]

Bon, pour A68k:
- Je ne sais pas encore de manière certaine d'où vient le problème, mais je pense que c'est parce que le dernier label global devant le label local se trouve dans un fichier include (OS.h, doorsos.h ou tios.h) qui est sauté lors du pass 2.
- L'erreur est un "Pass 1 / Pass 2 phase error.", qui est généré lors d'une vérification que j'avais heureusement rajoutée dans la version 2.71.F3a. Si je ne l'avais pas mise, il y aurait une erreur de segmentation (segmentation fault), donc un plantage, à la place.
- Je vais voir ce que je peux faire pour éviter le "Pass 1 / Pass 2 phase error."

C'est bien ce que j'ai pensé. J'ai corrigé le problème. Je vais envoyer ça à Sebastian tout de suite, j'espère que ça ne soit pas trop tard pour la mise à jour officielle sur ticalc.org. Sinon, ça sera dans la prochaine mise à jour inofficielle.

OK, pour ceux qui ne veulent pas attendre:
A68k 2.71.F3i