Dev Développement Wonderswan (le retour) - Page 25

J'ai du mal a comprendre l'interet de mettre sur la pile (en variable locale) le pointeur vers la chaine pour ensuite le pousser pour appeler mmap


BC me genere cette chose:
FsILp get_il(FS filesystem) { //char far *pfsPath; FsILp ptrFsIl; ptrFsIl = filesystem->handler.il; if (FP_SEG(ptrFsIl) == 0) { const char path[] = "/kern/@pfs"; ptrFsIl = mmap(path); } return ptrFsIl; } _TEXT:0010 public _get_il _TEXT:0010 _get_il proc near _TEXT:0010 _TEXT:0010 var_10 = byte ptr -10h _TEXT:0010 var_4 = word ptr -4 _TEXT:0010 var_2 = word ptr -2 _TEXT:0010 arg_0 = dword ptr 4 _TEXT:0010 _TEXT:0010 push bp _TEXT:0011 mov bp, sp _TEXT:0013 sub sp, 10h _TEXT:0016 ; #line 11 _TEXT:0016 les bx, [bp+arg_0] _TEXT:0019 mov ax, es:[bx+3Ah] _TEXT:001D mov dx, es:[bx+38h] _TEXT:0021 mov [bp+var_2], ax _TEXT:0024 mov [bp+var_4], dx _TEXT:0027 ; #line 13 _TEXT:0027 cmp [bp+var_2], 0 _TEXT:002B jnz short loc_1005D _TEXT:002D ; #line 15 _TEXT:002D lea ax, [bp+var_10] _TEXT:0030 push ss _TEXT:0031 push ax _TEXT:0032 mov ax, offset aKern@pfs ; "/kern/@pfs" _TEXT:0035 push ds _TEXT:0036 push ax _TEXT:0037 mov cx, 0Bh _TEXT:003A call N_SCOPY@ _TEXT:003D ; #line 16 _TEXT:003D push ss _TEXT:003E lea ax, [bp+var_10] _TEXT:0041 push ax _TEXT:0042 call _mmap _TEXT:0045 pop cx _TEXT:0046 pop cx _TEXT:0047 mov [bp+var_2], dx _TEXT:004A mov [bp+var_4], ax _TEXT:004D ; #line 19 _TEXT:004D _TEXT:004D loc_1005D: ; CODE XREF: _get_il+1Bj _TEXT:004D mov dx, [bp+var_2] _TEXT:0050 mov ax, [bp+var_4] _TEXT:0053 jmp short $+2 _TEXT:0055 ; --------------------------------------------------------------------------- _TEXT:0055 ; #line 20 _TEXT:0055 _TEXT:0055 loc_10065: ; CODE XREF: _get_il+43j _TEXT:0055 mov sp, bp _TEXT:0057 pop bp _TEXT:0058 retn _TEXT:0058 _get_il endp
mais bon le code C est inspiré par le code asm

Ne jamais chercher à comprendre pourquoi un compilateur génère des horreurs, ça ne peut que t'être néfaste. Regarde ce qui arrive à Folco à chaque fois qu'il désassemble un truc compilé avec GCC

Es-tu sûr que le pointeur n'est pas utilisé après l'appel à mmap ?
Je ne connais pas ta plateforme, mais sur TI une fonction a le droit de détruire ses arguments sur la pile (je ne sais pas si c'est lié au standard C, par contre, où si c'est défini ainsi pour ce système).
Ca expliquerait alors la sauvegarde préliminaire du pointeur.

edit -> ok oublie, j'avais lu que le code asm, pas le C ^^

Le code C n'est pas d'origine bien entendu mais reecrit apres desassemblage

ok, mais ça ne change rien à mon hypothèse, qui est que les fonctions peuvent être autorisés à détruire leurs arguments sur la pile.

Ha oui c'est sur en effet!
Enfin a moins d'optimisation, le compilateur va chercher a garder les parameters.

Sinon chose amusante non lié, ici mmap, pour acceder a certains parametres peux faire appel a get_il..... Et comme get_il appel mmap si le segment du pointeur n'est pas définie....

tiens, rigolo
Après, ça peut être utilisé en toute connaissance de cause, mais quand même, c'est marrant

Oui oui bien sur ca ne rentre pas en boucle infinie !


A moins que...


WUT ?

Freya:0E2E mov di, [bp+fd] Freya:0E31 in al, WS_IO_BCD_SRAM_BANK Freya:0E33 mov [bp+saveCurrentSramBank], al Freya:0E36 or di, di Freya:0E38 jl short invalidFd Freya:0E3A cmp di, 16 ; Check if FD is higher than maximum of opened files Freya:0E3D jl short validFd Freya:0E3F Freya:0E3F invalidFd: ; CODE XREF: rfs_close+12j Freya:0E3F mov ax, E_FS_INVALID Freya:0E42 jmp exit Freya:0E45 ; --------------------------------------------------------------------------- Freya:0E45 Freya:0E45 validFd: ; CODE XREF: rfs_close+17j Freya:0E45 mov al, BANKS_RAM_3 Freya:0E47 out WS_IO_BCD_SRAM_BANK, al Freya:0E49 cmp di, 16 Freya:0E4C jl short fdIsValid Freya:0E4E jmp outOfBoundFd Freya:0E51 ; ------------------------------------
Regarder Freya:0E3A / Freya:0E3D et Freya:0E49 / Freya:0E4C, je crois avoir trouvé un autre bug.. , la fonction retourne 0xFFFF au lieu du E_FS_OUT_OF_BOUNDS attendu

J'en fait sur twitter

(ceci dit, même avec le code que t'as posté sur Twitter, je vois pas le bug ?)

Je suis peut etre fatigué mais



E2E - di est initialisé a la valeur de l'argument "fd" ( [bp+fp] )
E38 - On test si di est negatif, si oui c'est invalide -> on quite (EE9)
E3A - On compare di a 16
E3D - Si inferieur on va au code de la fonction (E45)
E3F - On met 0xFFFF (la valeur de E_FS_INVALID) dans ax
E42 - on saute a exit (EE9)
E45 - [Code pas utile pour le probleme courant]
E49 - On compare di a 16
E4C - Si inferieur le file descriptor est valide et on va au reste du code de la fonction (E51)
E4E - on saute a la sortie qui met ax a la valeur de "out of bounds" (EDF)
E51 - [Corps de la fonction]
ED8 - On saute proche de la fin (EE2)
EDF - On met E_FS_OUTOFBOUNDS dans si
EE2 - [Un peu de code inutile pour le probleme courant]
EE7 - On copie si dans ax
EE9 - On nettoie la pile
[...]
EEF - Bye bye!

Maintenant considère le trajet ou fd est supérieur a 16, on va recevoir (dans ax) la valeur 0xFFFF, alors qu'on attends la valeur pour Out of Bounds. Le code supprimé n'a pas d'impact sur le registre DI ou SI

A vrai dire si le code d'origine est bien en C il doit etre un peu alambiqué et masquer le fait que si fd est supérieur a 16, on ne retourne pas la bonne valeur, c'est meme peut etre une "optimisation" du code fait par notre amis le compilateur qui "ha tiens ce code pour retourner invalide la valeur ne peux pas dépasser 16, donc je teste contre 16"

(en gras le code executé reelement pour di > 16, en italique celui quon voudrais qui soit executé)

Ah oui, ça. Je l'avais vu, mais je pensais que c'était fait exprès pour une raison quelconque (genre les valeurs négatives auraient une signification différente).
Parce que dans le cas contraire, ce chemin de code n'a pas de raison d'exister : on peut le virer et remplacer jl par jb à Freya:0E3D.

les seules valeurs legales dans ce systeme sont 0 a 15.

Oui, il y a des bizzareries a l'utilisation de jl/jb dans une autre fonction, comme si le signe de la meme variable changeais en plein milieu de la fonction.

En fait je me demande si il n'y a pas eu utilisation de macros de type de check sans faire gaffe a ce que fait la macro et rajouter un valide test "if (fd > MAXOPENEDFILE) { return OUBOFBOUND }" la ou la macro retourne -1.
Vu la tronche du code il est quasi sur que c'est généré par un compilateur, meme un mauvais dev ASM ne ferrais pas des choses aussi alambiqué (et les parties vraiment en ASM ne sont pas aussi tordus)

Je pense que les compilateurs C pour x86 16bits n'était pas des foudre de guerre question optimisation.. Il faudrait que je regarde vraiment que que Digital Mars est capable de faire, sinon va falloir se tourner vers un nouveau compilatueur (probablement en ecrire un, ou au moins un backend pour un existant, reste le probleme du far/near qui n'existe que pour les compilo spécifiques x86... c'est une plaie la segmentation sur ce point... (ou alors il faut faire des fonciton speciales qui n'utilisent pas des pointeurs mais des structures mais c'est contraignant.

En fait je me demande si il n'y aurais pas moyen de faire un pre-processeur qui mange du far/near et pond du code C sans ce teintage de pointeur et qui peux etre mangé par un compilateur qui ne sais pas ce que sont les teintages de pointeurs..

peut etre un nouveau backend sdcc? Il gère déja bien le Z80 et tous ses copains.

À voir mais si il ne gère pas déjà les notions de segmentation et de pointeur teinté c'est probablement trop de boulot à porter

Une (bonne?) nouvelle Open Watcom dans sa preversion 2.0 semble compiler ici, peut etre bientot un compulatueur compatible 8086 et pas Windows/DOS Only?

DMC serait probablement mieux, mais il est Windows Only, a moins d'acheter les sources, mais la distribution demande une license speciale.. (enfin la license de OW n'est pas claire, mais au moins c'est source dispo)

C'est a peu pret ca!

un compulateur a glaburgeur automatique.

C'est important de glaburger!

Plop,
Je me permet de faire un UP.
YA t'il du nouveau ?

It works \ô>

— となりのManoël/ゴジル (@Gozilu) July 25, 2018

Bon, ça veut dire quoi ce tweet ?

ca:




la preview de mon site sur d'autres plateformes \ô>


Edit: merci zero je pense qu'on a trouvé un bug dans la balise code

Et moi qui croyais qu'il s'agissait d'une nouveauté sur la Madeleine... tu vas encore faire de la peine à Fei en lui donnant de faux espoirs !

XD

Et ça le fait rire en plus !
Espèce de monstre

Mouhahahahahahahahaha #evil#

Pendant ce temps là, y en a un qui s'est fait 3500 € en 2 heures (35 cartouches flash à 100$ l'unité parties à la vitesse de la lumière).