salut,
  "Voila un petit script sous linux en asmx86 ..."
Y-a plus qu'à faire un "chmod +x" du source asm ... haaa si la vie était si simple :)

Perso je ne vois pas non plus l'interêt du code ...
Faire un "call" d'un objet compilé, je n'appelle pas ça une innovation !

++dune

Pour conclure : (je ne veux pas non plus que la source devienne un lieu de débat)
On est donc d'accord que c'est une habitude de codage ;)
Mais je ne pense pas qu'on puisse parler d'optimisation à ce stade ;)

Je trouve tout de même que la multiplication des types de variables n'est pas une solution qui va vers une simplification ...

Quelle est la différence entre "int" et "long" sous windows alors ?? Pourquoi avoir 2 types identiques ?

Si c'est pour avoir une pérénnité du code, je l'assure en utilisant tout simplement "int" pour des variables à taille immuable et "long" lorsque je souhaite avoir une variable de taille adapté à l'archi (essentiellement dans le cadre de calculs sur des pointeurs).

++dune2

Oui mais au moins j'ai le choix :
- utiliser un "int" pour rester en 32bits.
- utiliser un "long" pour utiliser une pleine échelle de registres.

De plus, le "long" permet de faire des conversions entre pointeurs et variables, car les pointeurs sont en 64bits. Comment faire un calcul de pointeur si tu n'as pas de type correspondant à sa taille ?

Personnellement, je prefère avoir le choix, et c'est sous la responsabilité du codeur de faire le bon choix ;)

++dune2 (l'échange d'experience forme la connaissance ;) )

BruNews : "Pour conclure (sur PC Windows) int et long toujours à 4 octets sur 64 bits et restera même si on arrive aux 128 bits."

Mouhahahaaaa ! vive les optimisations de windows (dixi BruNews : "Si on mettait le 'unt' à 2 octets ce ne serait pas une optimisation mais une nuisance surtout en terme de perfs.
Ce code est pour Window qui a fort heureusement et définitivement (comme les autres acteurs majeurs) exclu C99 de ses compilos, int et long resteront à 4 octets.").

Moi je ne sais pas pour windows, mais sous unix :
===========================================
#include <stdio.h>

main() {
  printf("sizeof(int)  : %d\n",sizeof(int));
  printf("sizeof(long) : %d\n",sizeof(long));
  return;
}
===========================================

- compilation et execution sur une machine 32bits :

cku@encelade:~/test$ uname -m
i686
cku@encelade:~/test$ ./toto
sizeof(int)  : 4
sizeof(long) : 4

- compilation et execution sur une machine 64bits :

cku@ambre:~/test$ uname -m
x86_64
cku@ambre:~/test$ ./toto
sizeof(int)  : 4
sizeof(long) : 8

... J'attend impatiemment l'arrivée des 128bits sous unix (et tous systèmes POSIX) ;) pas vous ?

++dune2 (sans rancune ;) )

salut,



je suis assez d'accord avec patatalo, surtout quand on ne voit aucun commentaire avec des opcodes comme suit :
# db 66h
# xor ax,ax
-> 66h - operand size override prefix as it was in 32 bit x86
d'habitude quand je code, je préfère écrire "xor eax,eax" ... c'est un peu plus lisible !!

Salut,



primo, comme le dit Renfield, pourquoi un ZIP dans le zip ?? Perso, je suis membre pour pouvoir zieuter les sources en direct sans avoir à télécharger le ZIP ... si tout le monde se met à mettre des ZIPs, ça perd tout son interêt ! (et je ne suis pas le seul membre sur ce forum).
Secundo, pourriez-vous, s'il vous plait, indiquer dans le commentaire pour quel OS (il n'y-a pas que des utilisateurs de Windows dans la vie), ainsi que les contraintes de compilo si il y a (includes de headers propres à Masm par exemple) et la syntaxe (Intel, AT&T ?).

C'est juste pour éviter de télécharger des codes à tester avec des includes de windows/* (ça ne marche pas sous linux ... ni sous Solaris) ainsi que des macros à la Masm (ça ne marche pas avec gcc ... ni avec Nasm) ... enfin bref, pour dire à qui s'adresse ce source tout simplement.

Salut,
  Merci de préciser clairement dans le commentaire pour quel OS le source se destine, ainsi que le compilateur à utiliser, de manière à ne pas être obligé de dépacker le zip pour apercevoir dans les .ASM :

include \masm32\include\windows.inc
include \masm32\include\masm32.inc
include \masm32\include\gdi32.inc
include \masm32\include\user32.inc
include \masm32\include\kernel32.inc
[..]

Ce qui réduit fortement les chances de voir cette application se compiler sur mon linux ...

Merci de ta compréhension.

re,



OK, je comprends mieux ta réaction :)

Pour l'utilisation sur un micro-OS, je voulais parler uniquement de la partie _pci_read_byte, _pci_read_word, _pci_read_dword, qui permet d'acceder à l'espace de configuration d'un périphérique PCI en utilisant le N° de bus, device et fonction. L'énumération des cartes PCI n'est en fait qu'un exemple concret montrant son utilisation (j'ai donc rajouté l'affichage des device_id et vendor_id aussi à titre d'exemple). Je suis tout à fait d'accord que celà n'apporte strictement rien à un micro-OS. Mais cette énumération peut servir de base pour rechercher un périphérique précis (ou une classe de périphérique) en réutilisant cette énumération et en comparant le vendor_id et device_id des cartes trouvés. Ensuite, l'accés aux autres informations de la carte, et en particulier des différentes zones d'adresses remappable de la carte (BAR0-BAR5), se fera aussi par ces fonctions de bases (sauf le remapping des zones bien entendu, qui nécéssitera une petite conversation avec l'IOMMU de manière à avoir son remapping virtuel du bus physique coté soft ;) ).

Tu as tout à fait raison pour ce qui est de la structure PCIHEADER, je vais la rajouter pour remplacer les indexes de lecture par des constantes ce qui eclaircira la lecture pour ceux qui ne connaissent pas forcément l'organisation d'un espace de configuration PCI (header commun d'ailleur au PCI, PCI-X, PCI-Express et AGP puisque tous ces bus sont énumérés au même titre et peuvent être utilisés par le même moyen).

Et merci pour la précision sur les IOs 0x0CF8 et 0x0CFC, je pensais qu'ils représentaient une sorte d'interface avec le Bios (Ecriture commande @0x0CF8 et Lecture resultat @0x0CFC).

dune2.

re,



Oui, tient, d'ailleur ... je viens de réaliser que 1024 correspond à 0x0400 ... or 0x0CF8 et 0x0CFC sont au-delà de 0x0400. Et pourtant, aprés plusieurs tests, il s'avère que l'appel à "ioperm" est nécéssaire pour acceder à 0x0CF8 (j'ai eu un doute suite au post de Patalo). Sinon, c'est le segfault assuré (réaction normal pour un accés à un espace d'adressage interdit).

C'est bizarre cette différence de comportement par rapport au "man" de ioperm :
[...]
DESCRIPTION
       Ioperm  positionne  les  bits  de permission d'accès du processus aux ports commençant à l'adresse from étalés sur num octets à la valeur turn_on.  L'utilisation de ioperm nécessite les privilèges de Super-User.

       Seuls les 0x3ff premiers ports d'entrée/sortie peuvent être indiques de cette manière. Pour d'autres ports, il  faut  utiliser  la fonction iopl.
[...]

Mais il est bien évident que l'appel à ioperm n'est nécéssaire qu'au bon fonctionnement sur un système linux.

dune2.