Auteur Sujet: Programmation : Le GOTO c'est le maaaaaaal  (Lu 50962 fois)

0 Membres et 1 Invité sur ce sujet

corrector

  • Invité
syscall interruptus
« Réponse #60 le: 07 mars 2015 à 00:21:48 »
Mon man 2 syscall me dit que mon cas particulier est massivement général :

Dans tout les cas, il y a utilisation d'une instruction assembleur dédié (mais cette liste n'est pas exhaustive vas-tu répondre, certes)
Ben oui, il y a une instruction qui permet un appel système. Ce qui n'a absolument aucun rapport avec le concept d'interruption dont il était question. Une interruption c'est quand un périphérique veut interrompre le CPU, donc c'est asynchrone. L'instruction int n'interrompt rien, elle est synchrone.

corrector

  • Invité
L'empire du sens
« Réponse #61 le: 07 mars 2015 à 00:25:41 »
Hey, t'as raison, les deux mots clefs ne sont pas rigoureusement identiques !
Comme c'est toi, je vais faire un peu de mauvaise foi pour la route : ça reste un goto, au sens sémantique du terme  8)
Vas-y, donne moi le sens sémantique!

corrector

  • Invité
syscall != int
« Réponse #62 le: 07 mars 2015 à 00:29:07 »
Mon man 2 syscall me dit que mon cas particulier est massivement général :
Il ne dit rien de tel. Il ne parle même pas d'interruption!

Erreur : dans tout les cas, il y a entrée dans le contexte noyau, execution de code en kernelspace, retour en espace utilisateur : context switch;
Dans quels tous les cas?

Ce que tu essayes de rajouter, c'est qu'il existe des switchs plus "conservateur" que d'autres,
Ah bon, tu peux donner un exemple?

corrector

  • Invité
C n'est pas de bas niveau
« Réponse #63 le: 07 mars 2015 à 00:33:33 »
Exemple ?
Par exemple l'ordre en mémoire des membres d'une structure est imposé, le compilateur ne peut pas réorganiser pour gagner de la place, sauf à démontrer que ça n'a aucun impact, par analyse globale (passablement difficile, il faudrait suivre tous les pointeurs, je pense qu'aucun compilateur au monde ne s'amuse à ça).

Le C ne permet pas de dire : là je veux la représentation précisèment comme ça, là je m'en fou. (Ada le permet, mais l'autre taré va encore dire que je m'éloigne du sujet.)

Par exemple si une fonction reçoit deux pointeurs a et b, alors a[p] et b[q] peuvent désigner la même chose, même si a!=b. (En Java ce n'est pas le cas puisqu'il n'y a pas de pointeurs d'éléments mais des "références" (ce qui est façon politiquement correcte et hypocrite(*) de dire : des pointeurs) sur des tableaux.)

Fortran considère que a et b ne peuvent pas désigner la même chose, ce qui est une clé de la performance.

(*) Java est à la base un langage de bouffons hypocrites neuneu

Par exemple si le compilateur optimise les opérations portant sur des int en utilisant les lois de l'arithmétique (comme a*x/a est remplacé par x), il peut casser du code qui utilise le comportement habituel des int qui est le comportement modulaire fournis par le CPU - donc le C n'est pas du tout un langage de bas niveau puisqu'il ne permet pas d'utiliser les opérations arithmétiques du CPU (bon, on peut jouer sur volatile mais ça casse la performance vu qu'un compilateur ne veut pas en général mettre un volatile en registre même si rien ne s'y oppose).

Linus n'est donc pas content que le compilateur se mette à optimiser les opérations arithmétiques, et il n'est pas le seul. Les gens se sentent floués parce qu'ils pensaient que le C était proche du CPU, ce qui n'était pas le cas (enfin personne n'a promis ça).

Bon, je vais passer sur des subtilités dont j'ai parlé dans un autre topic sur les connards de chez GNU C et le libre de merde, topic qui est parti en vrille à cause d'un taré. Sauf si ça intéresse quelqu'un...

Bref C est un outil de merde.

corrector

  • Invité
PEEK POKE
« Réponse #64 le: 07 mars 2015 à 00:39:51 »

corrector

  • Invité
L'appel système n'est pas un changement de contexte
« Réponse #65 le: 07 mars 2015 à 00:47:25 »
Erreur : dans tout les cas, il y a entrée dans le contexte noyau, execution de code en kernelspace, retour en espace utilisateur : context switch;
Ah, je vois que j'ai oublié de relever cette autre absurdité :

Un appel système ne provoque certainement pas un changement de contexte. (Sauf bien sûr quand l'appel est bloquant et donc donne la main à un autre thread.)

C'est bien moins coûteux qu'un changement de contexte parce que l'adressage ne change pas : une même adresse correspond toujours à une même donnée. Donc le cache n'est pas invalidé.

On est à un niveau de confusion conceptuelle vraiment important, là.

corrector

  • Invité
Programmation : Le GOTO c'est le maaaaaaal
« Réponse #66 le: 07 mars 2015 à 00:50:32 »
char* n'est pas une chaine, c'est un tableau de caractère.
char* n'est pas non plus un tableau de caractère.

Déjà si on veut être précis char* est un type, pas une valeur. Un type pointeur.

Une valeur de type char* peut pointer sur un ou plusieurs objets de type char, ou pas.

Un objet de type char* peut contenir une valeur de type char*, ou pas.

corrector

  • Invité
Programmation : Le GOTO c'est le maaaaaaal
« Réponse #67 le: 07 mars 2015 à 00:59:49 »
Et quoi qu'il en soit, à moins de programmer au niveau même du noyau j'imagine, il y aura toujours un problème de performances vu qu'il s'agit d'interruptions système.
Qu'est-ce que vous appelez "interruptions système"?

jack

  • Professionnel des télécoms
  • *
  • Messages: 1 676
  • La Madeleine (59)
Lalala, je suis un petit poney lalala
« Réponse #68 le: 07 mars 2015 à 01:04:00 »
Pouah, tu me déçois ..

Tu ne me donnes pas de code !
Tu me dit que, pour faire de l'accès mémoire en JS, il faut coder un accès mémoire en C !
Bientôt, tu vas me dire que tu fais un programme en JS, il te suffit de le faire en C et d'utiliser exec ..
Trop facile, trop facile..

EDIT: haaa, ben si, voici un super exemple (http://stackoverflow.com/questions/15347985/raw-memory-access-java-python).
L'idée est d'utiliser la mémoire du processus courant via procfs.
Je te propose donc d'utiliser directement /proc/kcore : tant qu'à utiliser un truc pratique et à ne surtout pas être de mauvaise fois, autant y aller jusqu'au bout !

Citation de: corrector
Ben oui, il y a une instruction qui permet un appel système. Ce qui n'a absolument aucun rapport avec le concept d'interruption dont il était question. Une interruption c'est quand un périphérique veut interrompre le CPU, donc c'est asynchrone. L'instruction int n'interrompt rien, elle est synchrone.
Rhoo !

Et elle fait quoi, l'instruction ?
Je te laisse chercher ?

Indice: chercher la différence entre interruption synchrone et asynchrone.

Citation de: corrector
Vas-y, donne moi le sens sémantique!
Qui porte du sens;

On peut donc dire que tout est sémantique : pour tout groupe d'élèment aléatoire, tu peux trouver une suite logique donnant un sens à l'ensemble.
En revanche, dire que cela n'a pas de sens ne met qu'en lumière ton incapacité (ou ta non-volonté ?) à le trouver :)

Citation de: corrector
Il ne dit rien de tel. Il ne parle même pas d'interruption!
Mais si, mais si, c'est la deuxième colonne du tableau que j'ai copié : l'instruction à utiliser.

Citation de: corrector
Dans quels tous les cas?
Dans tout les cas qui sont répertoriés dans mon manuel.
Mais bon, même en restant théorique : comment peut-on faire pour qu'un programme se coupe volontairement afin d'obtenir des choses du noyau ?
Hormis les syscall à base d'instruction spécifique et d'interruption, comment un processus peut-il "ne rien faire" ? Il a un temps processeur alloué.
La seule solution qui me vient à l'esprit consisterai à mettre à disposition les infos pour le syscall, et à perdre du temps en instruction inutile.
Débile comme solution, non ?

Citation de: corrector
Ah bon, tu peux donner un exemple?
Tu l'as très bien fait tout seul !
En fonction de ce que tu as besoin, tu peux utiliser l'un des deux types de switch: soft ou hard, et donc ne sauvegarder qu'une partie des trucs à sauvegarder (c'est à dire, pas la totalité).
Et dans ce cas, on peut donc dire que le switch est plus "conservateur" (= économe, si tu préfères)

Par exemple l'ordre en mémoire des membres d'une structure est imposé, le compilateur ne peut pas réorganiser pour gagner de la place, sauf à démontrer que ça n'a aucun impact, par analyse globale (passablement difficile, il faudrait suivre tous les pointeurs, je pense qu'aucun compilateur au monde ne s'amuse à ça).

Le C ne permet pas de dire : là je veux la représentation précisèment comme ça, là je m'en fou. (Ada le permet, mais l'autre taré va encore dire que je m'éloigne du sujet.)

Par exemple si une fonction reçoit deux pointeurs a et b, alors a[p] et b[q] peuvent désigner la même chose, même si a!=b. (En Java ce n'est pas le cas puisqu'il n'y a pas de pointeurs d'éléments mais des "références" (ce qui est façon politiquement correcte et hypocrite(*) de dire : des pointeurs) sur des tableaux.)

Fortran considère que a et b ne peuvent pas désigner la même chose, ce qui est une clé de la performance.

(*) Java est à la base un langage de bouffons hypocrites neuneu

Par exemple si le compilateur optimise les opérations portant sur des int en utilisant les lois de l'arithmétique (comme a*x/a est remplacé par x), il peut casser du code qui utilise le comportement habituel des int qui est le comportement modulaire fournis par le CPU - donc le C n'est pas du tout un langage de bas niveau puisqu'il ne permet pas d'utiliser les opérations arithmétiques du CPU (bon, on peut jouer sur volatile mais ça casse la performance vu qu'un compilateur ne veut pas en général mettre un volatile en registre même si rien ne s'y oppose).

Linus n'est donc pas content que le compilateur se mette à optimiser les opérations arithmétiques, et il n'est pas le seul. Les gens se sentent floués parce qu'ils pensaient que le C était proche du CPU, ce qui n'était pas le cas (enfin personne n'a promis ça).

Bon, je vais passer sur des subtilités dont j'ai parlé dans un autre topic sur les connards de chez GNU C et le libre de merde, topic qui est parti en vrille à cause d'un taré. Sauf si ça intéresse quelqu'un...

Bref C est un outil de merde.

Hum hum;
En gros, tu critiques le concept de tableau : un tableau contient un autre tableau.

Citation de: corrector
char* n'est pas non plus un tableau de caractère.

Déjà si on veut être précis char* est un type, pas une valeur. Un type pointeur.

Une valeur de type char* peut pointer sur un ou plusieurs objets de type char, ou pas.

Un objet de type char* peut contenir une valeur de type char*, ou pas.
Tu peux aussi dire : char* est un entier.

Citation de: corrector
Qu'est-ce que vous appelez "interruptions système"?
Si tu parles d'une interruption, c'est un message beep;

corrector

  • Invité
Lalala, je suis un petit poney lalala
« Réponse #69 le: 07 mars 2015 à 01:13:33 »
Rhoo !

Et elle fait quoi, l'instruction ?
Elle fait un appel système. Elle contribue donc à la progression du thread en cours d'exécution.

Mais si, mais si, c'est la deuxième colonne du tableau que j'ai copié : l'instruction à utiliser.
Et? Qu'est-ce que ça fait de savoir ça?

Mais bon, même en restant théorique : comment peut-on faire pour qu'un programme se coupe volontairement afin d'obtenir des choses du noyau ?
Un appel système évidemment. Je n'ai aucune idée de ce que tu essayes de dire.

Tu l'as très bien fait tout seul !
En fonction de ce que tu as besoin, tu peux utiliser l'un des deux types de switch: soft ou hard, et donc ne sauvegarder qu'une partie des trucs à sauvegarder (c'est à dire, pas la totalité).
Et dans ce cas, on peut donc dire que le switch est plus "conservateur" (= économe, si tu préfères)
On dit surtout "mode switch".

corrector

  • Invité
Lalala, je suis un petit poney lalala
« Réponse #70 le: 07 mars 2015 à 01:15:14 »
En gros, tu critiques le concept de tableau
Non

: un tableau contient un autre tableau.
Pardon?

Tu peux aussi dire : char* est un entier.
Non

corrector

  • Invité
Programmation : Le GOTO c'est le maaaaaaal
« Réponse #71 le: 07 mars 2015 à 01:21:05 »
Résumons :

- une interruption est une interruption
- un appel système est un appel système
- changement de contexte est un changement de contexte
- changement de mode est un changement de mode
- un appel système sert à demander au noyau de commencer à faire quelque chose ou bien à récupérer une information (qui peut être vide) ou bien les deux
- une interruption sert à signaler au CPU un changement d'état qui pourrait mériter son attention
- un appel système provoque un changement de mode
- un changement de mode ne change pas le sens des adresses mémoires manipulées par le code

Quand on me dit "interruption" je comprends interruption, pas appel système.

Ayant éclairci ces points préliminaires, je pense qu'on peut reprendre la discussion à partir de là.