Discussion :

[Gluups]

Ça me paraît bien vrai. Je reste prudent parce que dans le domaine je ne suis pas trop à jour.

Dans l'objet du fil est apparu une difficulté supplémentaire, celle d'écrire un programme pour un système propriétaire (celui de Macrium), et du coup ne pas avoir à disposition les ressources qu'on croyait.

Ce fil me rappelle comme le temps passe vite, je n'ai pas creusé auprès de Macrium, et dans un avenir très proche j'espère bien avoir d'autres questions à creuser qui du coup me laisseront moins de disponibilité.

[Gluups]

D'autre part, le code est alignée sur des adresses mémoires multiples de 4 voire 16, ce qui fait perdre également de la place.

Ça va peut-être plus loin que ça pour le Turbo C. Je me rappelle que les programmes faisaient toujours la même taille (4064 si je me rappelle bien), que j'affiche Hello World ou que je réinvente le concept du traitement de textes. Si toutefois j'écris suffisamment de code pour que ça ne tienne pas dans les 4064 octets, alors la taille du programme sera double, même pour une ligne d'instruction de plus.

[Kannagi]

Ok alors bonjour les gens moi c'est nul de chez nul qui a pas une foutu base en quoi que ce soit qui touche a l'assembleur et qui se pose une question. Tu dis que ça ne sert a rien sur pc+os. Alors tu peux utiliser l'assembleur sur quoi ?? Sur un pc sans OS ? ( Là même moi jsuis sur que je dis une connerie mais bon xD chut)

Ben oui tu peux faire de l'asm sans OS (pas mal le font ici).
Sinon le faire sur d'autre machines (ancien ordi comme Atari ST ou Amiga , sur microcontrôleur ou d'anciennes consoles).
L’avantage entre autre de tout cela , c'est que tu as un accès direct au hardware

Pour l'optimisation le x86 est vraiment pas évident , le seul où tu serais sur d'avoir de bonne perf (par rapport à un compilo) serait les utilisations des instructions SIMD.

Pour le reste , et il y'avait une question ici justement qui ne comprenait pas pourquoi un code était plus rapide qu'un autre ,c'est que le x86 utilise des optimisations interne qui ne te permet pas de connaître précisément le taux de cycle utilisé.
Le proc actuelle Intel est capable d'exécuter 5 instructions en même temps , du coup dans un cas extrême on peut avoir deux code où :
-un ferait 10 instructions et 5 qui s’exécuterait en même temps (donc 2 cycles)
-et inversement avoir 8 instructions et 2 qui s’exécute en même temps (et donc 4 cycles)
Et ce qui est assez fou ,c'est que ce n'est pas en lisant le code que tu peux le deviner , ça reste un boite noire.
C'est un peu le souci des procs actuelle (enfin ceux qu'on nomme Out of Order), difficile à prédire au cycle près si on prend tout en compte.

[bifur]

je suis presque de ceux qui programme en asm pour pc sans OS, plus précisément je fait un OS en assembleur

pour ce qui est de la programmation sous Windows, j'en fait très peu (parce que c'est pas mon métier) mais lorsque j'ai besoin d'en faire j'utilise plutôt FASM

FASM a un inconvénient par rapport a d'autres compilateur, c'est qu'il faut déclarer tout les dll et les fonction présent dans les dll que tu veux utiliser.

si tu veux essayer fasm je pourrait te faire un petit hello world (mais la c'est l'heure pour moi d'aller manger, j'ai faim)

[chrtophe]

Ok alors bonjour les gens moi c'est nul de chez nul qui a pas une foutu base en quoi que ce soit qui touche a l'assembleur et qui se pose une question. Tu dis que ça ne sert a rien sur pc+os. Alors tu peux utiliser l'assembleur sur quoi ?? Sur un pc sans OS ? ( Là même moi jsuis sur que je dis une connerie mais bon xD chut)

Ben oui tu peux faire de l'asm sans OS (pas mal le font ici).

Le problème si tu veux faire de l’assembleur sans OS est qu'il te faut développer ton propre pilote disque dur, pilote USB, etc. Sans pilote correct, tu n'auras accès qu'à des fonctions limitées de la carte vidéo (pas de 3D), tu ne pourras pas utiliser une clé USB pour lire écrire des données sans développer une gestion de l'USB (clavier et souris fonctionneront en émulation PS/2 fournie par le BIOS). Il te faudra aussi un pilote pour la carte réseau et créer une pile TCP/IP si tu veux du réseau (et donc Internet). C’est un travail de titan.

[bifur]

voici un hello world pour Windows et compilable par FASM

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
format	PE console
 
stack 1000h    ;taille de la pile souhaité??
 
section '.text' code readable executable
 
start:
push	dword 0FFFFFFF5h
call	[GetStdHandle]              ;récupère handle de la sortie console dans EAX
 
push	0                           ;null 
push	dword temporaire            ;pointeur obligatoire ou seront écrit la quantité d'octet écrit
push	dword finmessage-message    ;nb d'octet du message
push	dword message               ;adresse des données du message      
push	eax                         ;handle du fichier ou ecrire 
call	[WriteFile]
 
call	[ExitProcess]
 
 
 
 
;***********************************************************
;données du programme
 
section '.data' data readable writeable
 
 
temporaire:
dd 0
 
message:
db "Hello World!"
finmessage:
 
 
 
 
 
;**************************************************************************
;données de relocation des appels de sous fonctions
 
section '.idata' import data readable writeable
 
  dd 0,0,0,rva kernel32_name,rva kernel32_table ;ici tu déclare la liste des DLL dont tu as besoin (pointeur vers les données)
  dd 0,0,0,0,0 ;terminé par une entrée vide
 
 
kernel32_name db 'KERNEL32.DLL',0      ;ici tu déclare le nom de la DLL dont tu as besoin sous forme d'une chaine de caractère terminé par un octet à zéro
 
kernel32_table:                     
    ExitProcess dd rva _ExitProcess    ;ici tu déclare a liste des pointeurs vers les nom de fonction a utiliser
    WriteFile dd rva _WriteFile        ;cette table sera remplacé par un pointeur vers les fonctions elle même lors du chargement par le système d'exploitation
    GetStdHandle dd rva _GetStdHandle
    dd 0 ;terminé par une entrée vide
 
 
    _ExitProcess dw 0                  ;nom des fonction a utiliser sous forme d'une chaine de caractère terminé par un octet à zéro
    db 'ExitProcess',0
    _WriteFile dw 0
    db 'WriteFile',0
    _GetStdHandle dw 0
    db 'GetStdHandle',0

je crois que la plupart des compilateurs ne nécessitent pas de déclarer avec autant de détail les fonctions utilisé (et il doit y avoir une méthode plus efficace de le faire avec fasm) mais l'avantage c'est de pouvoir ajouter n'importe quel DLL dont on auras trouvé la documentation (même la documentation pour les dev en C)

[chrtophe]

Tu peux aussi utiliser WtiteConsole.

Tu peux te baser sur le code précédemment donné par Bifur.

[viper1094]

Ben oui tu peux faire de l'asm sans OS (pas mal le font ici).
Sinon le faire sur d'autre machines (ancien ordi comme Atari ST ou Amiga , sur microcontrôleur ou d'anciennes consoles).
L’avantage entre autre de tout cela , c'est que tu as un accès direct au hardware

Pour l'optimisation le x86 est vraiment pas évident , le seul où tu serais sur d'avoir de bonne perf (par rapport à un compilo) serait les utilisations des instructions SIMD.

Pour le reste , et il y'avait une question ici justement qui ne comprenait pas pourquoi un code était plus rapide qu'un autre ,c'est que le x86 utilise des optimisations interne qui ne te permet pas de connaître précisément le taux de cycle utilisé.
Le proc actuelle Intel est capable d'exécuter 5 instructions en même temps , du coup dans un cas extrême on peut avoir deux code où :
-un ferait 10 instructions et 5 qui s’exécuterait en même temps (donc 2 cycles)
-et inversement avoir 8 instructions et 2 qui s’exécute en même temps (et donc 4 cycles)
Et ce qui est assez fou ,c'est que ce n'est pas en lisant le code que tu peux le deviner , ça reste un boite noire.
C'est un peu le souci des procs actuelle (enfin ceux qu'on nomme Out of Order), difficile à prédire au cycle près si on prend tout en compte.

Alors j'ai à peu près compris, mais serait tu capable de m'expliquer pourquoi ces différences de cycles, qui semble aléatoire ? (Jme doute bien que ça ne l'est pas y a surement une raison. Peut etre ressource nécessaire a l'éxécution des instructions ?)

[viper1094]

Le problème si tu veux faire de l’assembleur sans OS est qu'il te faut développer ton propre pilote disque dur, pilote USB, etc. Sans pilote correct, tu n'auras accès qu'à des fonctions limitées de la carte vidéo (pas de 3D), tu ne pourras pas utiliser une clé USB pour lire écrire des données sans développer une gestion de l'USB (clavier et souris fonctionneront en émulation PS/2 fournie par le BIOS). Il te faudra aussi un pilote pour la carte réseau et créer une pile TCP/IP si tu veux du réseau (et donc Internet). C’est un travail de titan.

Alors oui ça me semble être un travail de titan effectivement xD. Merci pr toutes ces réponses au fait, ça me fera un peu de culture ( et un p'tit bagage pr commencer mon cours sur les architectures intel une fois que j'aurais compris cette histoire de binaire flottant (d'ailleurs hésiter pas à me répondre sur ma discussion que j'ai ouvert y a une quinzaine de minute x))

[chrtophe]

C'est par exemple l’exécution spéculative, qui a fait parler d'elle récemment avec la faille de sécurité Spectre.

le CPU exécute le code en spéculant un résultat, si il a raison, gain de temps, sinon perte de temps, par exemple quand tu as des sauts conditionnels. Si le cpu s'est planté dans sa spéculation, le code spéculé est annulé et il a perdu son temps. Mais globalement cette fonctionnalité fait gagner de la vitesse.

Les compilateurs comme le C génèrent du code de façon à optimiser l'usage de ce type de fonctionnalité, ils vont aussi utiliser des instructions différentes pour faire la même chose selon la situation. (exemple faire un xor eax,eax sera plus rapide que faire mov eax,0 pour le même résultat).
Un compilateur fera très bien ce type d'optimisation, un humain non.

[viper1094]

C'est par exemple l’exécution spéculative, qui a fait parler d'elle récemment avec la faille de sécurité Spectre.

Ah oui ! J'en avais entendu parler j'avais lu un truc dessus. Du coup je comprend mieux, merci pr ces petites explications. Mais question toute conne, est il possible de gérer manuellement ces exécutions spéculatives ? Du style les désactivé pr un code donnée, ou ce genre de choses ?

[Kannagi]

Alors je vais expliquer plus en profondeur ce qu'a dit chrtophe

Si on fait l'historique des processeurs , les processeurs avant les années 1995 (donc avant le Pentium et le MIPS) était des processeurs assez simple qui avait un taux de cycle fixe pour chaque instructions (par exemple l'addition fait 4 cycles).
Ce qu'on appelle les processeurs moderne possède une pipeline , en gros les instructions s’exécute en parallèle , concrètement quand tu fera une addition ça prendra un cycle les 3 autres se ferons en parallèle.
Mais ça c'est dans le meilleur des mondes , enfaite il peut y'avoir plein de raison qui feront que la pipeline est occupé ,si elle se bloque ,on appellera ça un pipeline stall.
Le cas le plus courant est si on réutilise souvent les mêmes registres , si toute les instructions utilise se registre le CPU se bloque est fini d'exécuter une instruction avant de passer à la suivante. (d'ou ce qu'on appelle le renommage de registres : https://fr.wikipedia.org/wiki/Renommage_de_registres ).
Bon et pourquoi on ne peut pas prédire les cycles ?

Ben il existe deux voie qui a était choisi ce qu'on appelle In Order et Out of Order.
Les processeurs In Order ne cache pas le fonctionnement interne du processeur et c'est au programmeur de faire un renommage de registre , de gérer les branchements conditionnel correctement , et le plus complexe , d’exécuter un peu dans le désordre , pour éviter toute pipeline stall (techniquement si tu fais une division , tu vas pas attendre 10 cycles comme un débile , tu vas tenté d’exécuter d'autre calcul pendant ces 10 cycles) , c'est le cas des processeurs ARM , du processeur CELL (de la PS3) et de quelque autre proc.

Le processeur Out of Order , lui fonctionne pareil , mais il fait l'optimisation de tout ceci en interne , donc le programmeur peut ne pas se soucier du fonctionnement interne et programmer comme en 1980 son code , ça marchera et ça optimisera la pipeline en interne (Algorithme de Tomasulo : https://fr.wikipedia.org/wiki/Algorithme_de_Tomasulo ).
Le x86 fonctionne comme ça.

Tu trouvera souvent le mot superscalaire , c'est assez simple , c'est un façon "barbare" de dire qu'on peut exécuter plusieurs instruction à la fois , cela rend la prog des procs In order encore plus ardu vu que tu devra de soucier d'éxécuters 2 ou plus instructions en même temps (et ils sont pas tous compatible entre elle).
Sur le Out of order ,ceci est encore invisible pour le programmeur.

Pour cela que je dis que les processeur Out of Order sont difficile à prédire au cycles près parce que tu ne sait pas exactement la pipeline , et les exécutions qui seront exécuter en même temps (même si tu peux avoir une petite idée).
Intel ne fournit pas forcément beaucoup d'information dessus.

Je rajouterai qu'il y'a aussi la mémoire cache , qui ne permet pas de savoir précisément si l'adresse en question est en mémoire cache ou pas (c'est possible vu que les failles meltdown et spectre exploite le temps d’accès des mémoires caches) , et si tu lis une adresse qui n'est pas en mémoire cache , tu vas avoir un sacrée temps d'attente.
d'ailleurs il n'ya eu que deux processeur qui ont voulu résoudre ce souci de mémoire cache le Processeur CELL et Emotion Engine (bref des proc de Sony) , ces proc avait la particularité que la mémoire cache était manuelle (via des transfert DMA) , et que tu pouvait exécuter du code tout en chargeant la mémoire cache , bon la complexité a fait que ce type de processeur a était abandonné.
(l'autre étant que c'était des procs VLIW , en gros une version très manuelle du superscalaire ).

ça me fera un peu de culture ( et un p'tit bagage pr commencer mon cours sur les architectures intel

Je peux d'assurer que l'explication que je t'ai donné , ne sera pas dans ton cours , ou alors ça sera tellement théorique que personne ne saura de quoi ça parle exactement

Ah oui ! J'en avais entendu parler j'avais lu un truc dessus. Du coup je comprend mieux, merci pr ces petites explications. Mais question toute conne, est il possible de gérer manuellement ces exécutions spéculatives ? Du style les désactivé pr un code donnée, ou ce genre de choses ?

Pour faire simple non
Pour cela qu'on appelle ça Spectre parce que cette faille nous hantera pendant très longtemps (et on a trouvé encore des variantes de meltdwon et spectre).

Et pour revenir en arrière les procs dit In order ne possède pas ce genre de faille (et si tu te pose encore la question pourquoi , ben comme je l'ai dit , c'est un proc qui se base sur le programmeur ou compilateur) donc pas d’exécution spéculative , c'est d’ailleurs le gros souci de ce type architecture , il faudra un compilateur pour chaque variante d'un proc donné , c'est sûrement une des raison pourquoi Intel n'a pas choisi de continué ce type proc (la premier Pentium était In order , c'est a partir du Pentium pro/2 qu'ils ont choisi de faire un proc Out of Order).
Néanmoins Intel a tenté de faire un proc In order moderne (le Itanium) , mais il était improgrammable , limite tu dois définir le micro code a chaque instruction , en tout cas il n'a jamais existé un bon compilateur pour ce proc.
Mais il était truffé de bonne idée , il permettais théoriquement d'éxecuter 12 instructions/cycles !

[viper1094]

Je peux d'assurer que l'explication que je t'ai donné , ne sera pas dans ton cours , ou alors ça sera tellement théorique que personne ne saura de quoi ça parle exactement

Alors d'abord merci pr ces explications dont j'ai pr être honnête pas tout compris, mais presque x). Et c'est fortement possible que je n'en entende pas parler, mais étant un jeune féru d'informatiques (on dirait ma tante qui parle de moi ), toutes informations dans ce domaine m'intéresse et me servira peut-être x). Oh et merci pr la rapidité des réponses également.