Je me demandais quel 8-bit de la glorieuse époque
C64/Amstrad/MSX/Spectrum/etc. pourrais-je utiliser pour apprendre la
base de la programmation informatique ?
AMHA le BASIC est le pire pour apprendre à programmer (GOTO et Cie)
Essayons d'imaginer un processeur sans son GOTO (jmp)... Ca serait un vrai casse têtes de programmer avec ça !!
Heureusement l'assembleur n'embête pas trop les programmeurs. Quand on a les mots pour causer à la machine dans son langage propre, elle est prête à tout.
Guillaume.
Ouai, mais faut être une tête, ou une bête! Ca existe encore, des programmeurs en assembleur (je "parle" dans le domaine pro)?
Jean-Luc
Dans le message <4daac79c$0$32441$ba4acef3@reader.news.orange.fr>
Guillaume Tello <houten.van@orange.fr> vous écrivez:
AMHA le BASIC est le pire pour apprendre à programmer (GOTO et Cie)
Essayons d'imaginer un processeur sans son GOTO (jmp)...
Ca serait un vrai casse têtes de programmer avec ça !!
Heureusement l'assembleur n'embête pas trop les programmeurs.
Quand on a les mots pour causer à la machine dans son langage propre,
elle est prête à tout.
Guillaume.
Ouai, mais faut être une tête, ou une bête!
Ca existe encore, des programmeurs en assembleur (je "parle" dans le
domaine pro)?
AMHA le BASIC est le pire pour apprendre à programmer (GOTO et Cie)
Essayons d'imaginer un processeur sans son GOTO (jmp)... Ca serait un vrai casse têtes de programmer avec ça !!
Heureusement l'assembleur n'embête pas trop les programmeurs. Quand on a les mots pour causer à la machine dans son langage propre, elle est prête à tout.
Guillaume.
Ouai, mais faut être une tête, ou une bête! Ca existe encore, des programmeurs en assembleur (je "parle" dans le domaine pro)?
Jean-Luc
capfree
Le 16/04/2011 09:09, JLS a écrit :
J'ajoute que je DÉTESTE la complexité inutile, et mon sentiment est que cette dernière ne fait que régresser l'informatique actuelle, ou plus exactement, l'informatique actuelle, compte tenu des énormes progrès apportés au matériel, pourrait être très nettement plus avancée.
À mon niveau, je suis à mille lieues de la programmation, j'ai la même désagréable impression. L'informatique deviendrait un ésotérisme, pour des initiés?
-- capfree
Le 16/04/2011 09:09, JLS a écrit :
J'ajoute que je DÉTESTE la complexité inutile, et mon sentiment est
que cette dernière ne fait que régresser l'informatique actuelle, ou
plus exactement, l'informatique actuelle, compte tenu des énormes
progrès apportés au matériel, pourrait être très nettement plus
avancée.
À mon niveau, je suis à mille lieues de la programmation, j'ai la même
désagréable impression. L'informatique deviendrait un ésotérisme, pour
des initiés?
J'ajoute que je DÉTESTE la complexité inutile, et mon sentiment est que cette dernière ne fait que régresser l'informatique actuelle, ou plus exactement, l'informatique actuelle, compte tenu des énormes progrès apportés au matériel, pourrait être très nettement plus avancée.
À mon niveau, je suis à mille lieues de la programmation, j'ai la même désagréable impression. L'informatique deviendrait un ésotérisme, pour des initiés?
-- capfree
moi-meme
Le Sun, 17 Apr 2011 17:37:53 +0100, JLS a écrit :
Ouai, mais faut être une tête, ou une bête! Ca existe encore, des programmeurs en assembleur (je "parle" dans le domaine pro)?
ceux qui font des PICS.
En développant des macro on peut même faire quelque chose de clair, concis, puissant.
Mais il faut avoir bien décortiqué le problème avant.
"une chose bien réfléchie est à demi réalisée" (je ne sais pas de qui c'est mais c'est bien vrai).
Le Sun, 17 Apr 2011 17:37:53 +0100, JLS a écrit :
Ouai, mais faut être une tête, ou une bête! Ca existe encore, des
programmeurs en assembleur (je "parle" dans le domaine pro)?
ceux qui font des PICS.
En développant des macro on peut même faire quelque chose de clair,
concis, puissant.
Mais il faut avoir bien décortiqué le problème avant.
"une chose bien réfléchie est à demi réalisée"
(je ne sais pas de qui c'est mais c'est bien vrai).
Ouai, mais faut être une tête, ou une bête! Ca existe encore, des programmeurs en assembleur (je "parle" dans le domaine pro)?
ceux qui font des PICS.
En développant des macro on peut même faire quelque chose de clair, concis, puissant.
Mais il faut avoir bien décortiqué le problème avant.
"une chose bien réfléchie est à demi réalisée" (je ne sais pas de qui c'est mais c'est bien vrai).
JLS
Dans le message <4dab2d0d$0$4856$ capfree vous écrivez:
Le 16/04/2011 09:09, JLS a écrit :
J'ajoute que je DÉTESTE la complexité inutile, et mon sentiment est que cette dernière ne fait que régresser l'informatique actuelle, ou plus exactement, l'informatique actuelle, compte tenu des énormes progrès apportés au matériel, pourrait être très nettement plus avancée.
À mon niveau, je suis à mille lieues de la programmation, j'ai la même désagréable impression. L'informatique deviendrait un ésotérisme, pour des initiés?
Cela en prend le chemin selon moi. Un des aspects qui font que je m'éloigne de plus en plus de cette "discipline"...
Jean-Luc
Dans le message <4dab2d0d$0$4856$426a74cc@news.free.fr>
capfree <caprifermager@libre-invalid> vous écrivez:
Le 16/04/2011 09:09, JLS a écrit :
J'ajoute que je DÉTESTE la complexité inutile, et mon sentiment est
que cette dernière ne fait que régresser l'informatique actuelle, ou
plus exactement, l'informatique actuelle, compte tenu des énormes
progrès apportés au matériel, pourrait être très nettement plus
avancée.
À mon niveau, je suis à mille lieues de la programmation, j'ai la même
désagréable impression. L'informatique deviendrait un ésotérisme, pour
des initiés?
Cela en prend le chemin selon moi.
Un des aspects qui font que je m'éloigne de plus en plus de cette
"discipline"...
Dans le message <4dab2d0d$0$4856$ capfree vous écrivez:
Le 16/04/2011 09:09, JLS a écrit :
J'ajoute que je DÉTESTE la complexité inutile, et mon sentiment est que cette dernière ne fait que régresser l'informatique actuelle, ou plus exactement, l'informatique actuelle, compte tenu des énormes progrès apportés au matériel, pourrait être très nettement plus avancée.
À mon niveau, je suis à mille lieues de la programmation, j'ai la même désagréable impression. L'informatique deviendrait un ésotérisme, pour des initiés?
Cela en prend le chemin selon moi. Un des aspects qui font que je m'éloigne de plus en plus de cette "discipline"...
Jean-Luc
JLS
Dans le message <4dab1362$0$7700$ Guillaume Tello vous écrivez:
Le 17/04/2011 18:37, JLS a écrit :
Ouai, mais faut être une tête, ou une bête! Ca existe encore, des programmeurs en assembleur (je "parle" dans le domaine pro)?
Une bonne question... Je n'ai jamais été dans le domaine "pro" ! Donc voila... Mais dans la mesure ou des outils assembleur continuent d'être produits, ça doit bien exister: - ecriture des BIOS ? - drivers?
Guillaume.
Oui bien sûr, il doit rester des domaines bien cernés ou il est encore "rentable" pour un ingénieur ou une équipe de programmer en assembleur. Mais la course à celui qui sera le premier sue le marché à pondre un logiciel avent "les autres" font que maintenant il s'agit d'utiliser des RAD (Rapid Application Devlopment) ou en 3 clics de souris, on fait du soft. Aidé en cela par l'arrivée perpétuelles des machines de plus en plus puissantes toutes les 3 semines. Puissance "gaspillée" par justement ces monstres de logiciels.
Tenez, il y a dèjà un bon moment, un de mes collègues éloigné m'avait transmis un logicile "de son cru" (obtenu par le RAD Clarion) permettant la tenu des journaux de service de véhicules. Poids 1Mo. Je voulais faire la même application, mais plus simplement en BBC BASIC. Je ne l'ai pas faite, faute de temps (on est pas dans le cas de RAD n'est-ce pas,), et j'avais estimé la taille de ce qui aurrait été mon programme à environ 20ko...
Autre cas: un de mes collègues avait développé une application de gestion de mouvement de matériel sous SUPERBASE. Résultats, une énorme quantité de fichiers dont j'ai tout simplement oublié la taille et le nombre. De mon coté j'avais développé une application sensiblement identique pour des mouvements de matériels différents. résultat: un programme en BBC BASIC de seulement 8 ko... et surtout INCOMPARABLEMENT plus RAPIDE.
L'ordinausore avec lequel je vous écrit fonctionne sous RISC OS. Un truc dépassé (pas pour moi) écrit majoritairement en assembleur, et qui se trouve logé en ROM (EEPROM dans mon cas) de seulement 4Mo. Un OS quasi complêt en 4Mo, je pense qu'il n'y a qu'en assembleur qu'une taille/fonctionalités aussi poussées peuvent être réalisées.
Dernier exemple: j'avais été à un salon des radio-amateurs en allemagne. Un petit Français (de génie) présentait ses réalisations autour de PIC's. Parmi lesquelles une mire TV, avec évidement 3 fois rien comme matériel, et un programme de taille rikiki!
Jean-Luc
Jean-Luc
Dans le message <4dab1362$0$7700$ba4acef3@reader.news.orange.fr>
Guillaume Tello <houten.van@orange.fr> vous écrivez:
Le 17/04/2011 18:37, JLS a écrit :
Ouai, mais faut être une tête, ou une bête!
Ca existe encore, des programmeurs en assembleur (je "parle" dans le
domaine pro)?
Une bonne question...
Je n'ai jamais été dans le domaine "pro" ! Donc voila...
Mais dans la mesure ou des outils assembleur continuent d'être
produits, ça doit bien exister:
- ecriture des BIOS ?
- drivers?
Guillaume.
Oui bien sûr, il doit rester des domaines bien cernés ou il est encore
"rentable" pour un ingénieur ou une équipe de programmer en
assembleur. Mais la course à celui qui sera le premier sue le marché à
pondre un logiciel avent "les autres" font que maintenant il s'agit
d'utiliser des RAD (Rapid Application Devlopment) ou en 3 clics de
souris, on fait du soft. Aidé en cela par l'arrivée perpétuelles des
machines de plus en plus puissantes toutes les 3 semines. Puissance
"gaspillée" par justement ces monstres de logiciels.
Tenez, il y a dèjà un bon moment, un de mes collègues éloigné m'avait
transmis un logicile "de son cru" (obtenu par le RAD Clarion)
permettant la tenu des journaux de service de véhicules. Poids 1Mo. Je
voulais faire la même application, mais plus simplement en BBC BASIC.
Je ne l'ai pas faite, faute de temps (on est pas dans le cas de RAD
n'est-ce pas,), et j'avais estimé la taille de ce qui aurrait été mon
programme à environ 20ko...
Autre cas: un de mes collègues avait développé une application de
gestion de mouvement de matériel sous SUPERBASE. Résultats, une énorme
quantité de fichiers dont j'ai tout simplement oublié la taille et le
nombre. De mon coté j'avais développé une application sensiblement
identique pour des mouvements de matériels différents. résultat: un
programme en BBC BASIC de seulement 8 ko... et surtout
INCOMPARABLEMENT plus RAPIDE.
L'ordinausore avec lequel je vous écrit fonctionne sous RISC OS.
Un truc dépassé (pas pour moi) écrit majoritairement en assembleur, et
qui se trouve logé en ROM (EEPROM dans mon cas) de seulement 4Mo.
Un OS quasi complêt en 4Mo, je pense qu'il n'y a qu'en assembleur
qu'une taille/fonctionalités aussi poussées peuvent être réalisées.
Dernier exemple: j'avais été à un salon des radio-amateurs en
allemagne. Un petit Français (de génie) présentait ses réalisations
autour de PIC's. Parmi lesquelles une mire TV, avec évidement 3 fois
rien comme matériel, et un programme de taille rikiki!
Dans le message <4dab1362$0$7700$ Guillaume Tello vous écrivez:
Le 17/04/2011 18:37, JLS a écrit :
Ouai, mais faut être une tête, ou une bête! Ca existe encore, des programmeurs en assembleur (je "parle" dans le domaine pro)?
Une bonne question... Je n'ai jamais été dans le domaine "pro" ! Donc voila... Mais dans la mesure ou des outils assembleur continuent d'être produits, ça doit bien exister: - ecriture des BIOS ? - drivers?
Guillaume.
Oui bien sûr, il doit rester des domaines bien cernés ou il est encore "rentable" pour un ingénieur ou une équipe de programmer en assembleur. Mais la course à celui qui sera le premier sue le marché à pondre un logiciel avent "les autres" font que maintenant il s'agit d'utiliser des RAD (Rapid Application Devlopment) ou en 3 clics de souris, on fait du soft. Aidé en cela par l'arrivée perpétuelles des machines de plus en plus puissantes toutes les 3 semines. Puissance "gaspillée" par justement ces monstres de logiciels.
Tenez, il y a dèjà un bon moment, un de mes collègues éloigné m'avait transmis un logicile "de son cru" (obtenu par le RAD Clarion) permettant la tenu des journaux de service de véhicules. Poids 1Mo. Je voulais faire la même application, mais plus simplement en BBC BASIC. Je ne l'ai pas faite, faute de temps (on est pas dans le cas de RAD n'est-ce pas,), et j'avais estimé la taille de ce qui aurrait été mon programme à environ 20ko...
Autre cas: un de mes collègues avait développé une application de gestion de mouvement de matériel sous SUPERBASE. Résultats, une énorme quantité de fichiers dont j'ai tout simplement oublié la taille et le nombre. De mon coté j'avais développé une application sensiblement identique pour des mouvements de matériels différents. résultat: un programme en BBC BASIC de seulement 8 ko... et surtout INCOMPARABLEMENT plus RAPIDE.
L'ordinausore avec lequel je vous écrit fonctionne sous RISC OS. Un truc dépassé (pas pour moi) écrit majoritairement en assembleur, et qui se trouve logé en ROM (EEPROM dans mon cas) de seulement 4Mo. Un OS quasi complêt en 4Mo, je pense qu'il n'y a qu'en assembleur qu'une taille/fonctionalités aussi poussées peuvent être réalisées.
Dernier exemple: j'avais été à un salon des radio-amateurs en allemagne. Un petit Français (de génie) présentait ses réalisations autour de PIC's. Parmi lesquelles une mire TV, avec évidement 3 fois rien comme matériel, et un programme de taille rikiki!
Jean-Luc
Jean-Luc
Guillaume Tello
Le 18/04/2011 08:20, JLS a écrit :
souris, on fait du soft. Aidé en cela par l'arrivée perpétuelles des machines de plus en plus puissantes toutes les 3 semines. Puissance "gaspillée" par justement ces monstres de logiciels.
Tout à fait d'accord!
n'est-ce pas,), et j'avais estimé la taille de ce qui aurrait été mon programme à environ 20ko...
Même chose au collège il y a quelques années on nous proposait d'installer un logiciel pour la saisie des notes depuis chez nous. Imaginez la chose simple: - nos listes de classes (j'en avais 5) - gérer des colonnes de chiffres avec les moyennes et coefficients. Bref, rien de complexe...
L'installateur du programme: 70Mo !! Le tout fait en Delphi avec les gestion des bases de données dont il fallait bien sur installer tous les filtres d'import/export... Un peu plus tard, merveille: le nouveau logiciel tenait sur une disquette 1.44 (notes comprises!). Enfin !
L'ordinausore avec lequel je vous écrit fonctionne sous RISC OS. Un truc dépassé (pas pour moi) écrit majoritairement en assembleur, et qui se trouve logé en ROM (EEPROM dans mon cas) de seulement 4Mo. Un OS quasi complêt en 4Mo, je pense qu'il n'y a qu'en assembleur qu'une taille/fonctionalités aussi poussées peuvent être réalisées.
Ah... Pas toujours: sur les premiers MAC la partie ROM c'était du Pascal compilé. Et sur Atari du "C" compilé. Ce qui fait que désassembler les ROMs n'est pas toujours facile car il faut suivre la logique d'un compilateur qui produit parfois du code redondant.
Guillaume.
Le 18/04/2011 08:20, JLS a écrit :
souris, on fait du soft. Aidé en cela par l'arrivée perpétuelles des
machines de plus en plus puissantes toutes les 3 semines. Puissance
"gaspillée" par justement ces monstres de logiciels.
Tout à fait d'accord!
n'est-ce pas,), et j'avais estimé la taille de ce qui aurrait été mon
programme à environ 20ko...
Même chose au collège il y a quelques années on nous proposait
d'installer un logiciel pour la saisie des notes depuis chez nous.
Imaginez la chose simple:
- nos listes de classes (j'en avais 5)
- gérer des colonnes de chiffres avec les moyennes et coefficients.
Bref, rien de complexe...
L'installateur du programme: 70Mo !!
Le tout fait en Delphi avec les gestion des bases de données dont il
fallait bien sur installer tous les filtres d'import/export...
Un peu plus tard, merveille: le nouveau logiciel tenait sur une
disquette 1.44 (notes comprises!). Enfin !
L'ordinausore avec lequel je vous écrit fonctionne sous RISC OS.
Un truc dépassé (pas pour moi) écrit majoritairement en assembleur, et
qui se trouve logé en ROM (EEPROM dans mon cas) de seulement 4Mo.
Un OS quasi complêt en 4Mo, je pense qu'il n'y a qu'en assembleur
qu'une taille/fonctionalités aussi poussées peuvent être réalisées.
Ah... Pas toujours: sur les premiers MAC la partie ROM c'était du
Pascal compilé. Et sur Atari du "C" compilé. Ce qui fait que
désassembler les ROMs n'est pas toujours facile car il faut suivre la
logique d'un compilateur qui produit parfois du code redondant.
souris, on fait du soft. Aidé en cela par l'arrivée perpétuelles des machines de plus en plus puissantes toutes les 3 semines. Puissance "gaspillée" par justement ces monstres de logiciels.
Tout à fait d'accord!
n'est-ce pas,), et j'avais estimé la taille de ce qui aurrait été mon programme à environ 20ko...
Même chose au collège il y a quelques années on nous proposait d'installer un logiciel pour la saisie des notes depuis chez nous. Imaginez la chose simple: - nos listes de classes (j'en avais 5) - gérer des colonnes de chiffres avec les moyennes et coefficients. Bref, rien de complexe...
L'installateur du programme: 70Mo !! Le tout fait en Delphi avec les gestion des bases de données dont il fallait bien sur installer tous les filtres d'import/export... Un peu plus tard, merveille: le nouveau logiciel tenait sur une disquette 1.44 (notes comprises!). Enfin !
L'ordinausore avec lequel je vous écrit fonctionne sous RISC OS. Un truc dépassé (pas pour moi) écrit majoritairement en assembleur, et qui se trouve logé en ROM (EEPROM dans mon cas) de seulement 4Mo. Un OS quasi complêt en 4Mo, je pense qu'il n'y a qu'en assembleur qu'une taille/fonctionalités aussi poussées peuvent être réalisées.
Ah... Pas toujours: sur les premiers MAC la partie ROM c'était du Pascal compilé. Et sur Atari du "C" compilé. Ce qui fait que désassembler les ROMs n'est pas toujours facile car il faut suivre la logique d'un compilateur qui produit parfois du code redondant.
Guillaume.
Lucas Levrel
Le 17 avril 2011, moi-meme a écrit :
Le Fri, 15 Apr 2011 12:06:20 +0200, Lucas Levrel a écrit :
Pour les tout premiers pas, un langage interprété c'est mieux. En ce qui me concerne, j'ai débuté en GFA Basic sur Atari.
AMHA le BASIC est le pire pour apprendre à programmer (GOTO et Cie) Pour apprendre le Pascal est pas mal (turbo pascal entre autre), très lourd mais n'est plus à la mode.
Le GFA est proche du Pascal paraît-il (je ne connais pas le Pascal). Pas de numéros de ligne (ça complique le goto !), une seule instruction par ligne.
Le problème n'est pas de coder mais d'apprendre à faire l'algorithme avant (organiser les tests, les boucles, etc).
Exactement.
-- LL
Le 17 avril 2011, moi-meme a écrit :
Le Fri, 15 Apr 2011 12:06:20 +0200, Lucas Levrel a écrit :
Pour les tout premiers pas, un langage interprété c'est mieux. En ce qui
me concerne, j'ai débuté en GFA Basic sur Atari.
AMHA le BASIC est le pire pour apprendre à programmer (GOTO et Cie)
Pour apprendre le Pascal est pas mal (turbo pascal entre autre),
très lourd mais n'est plus à la mode.
Le GFA est proche du Pascal paraît-il (je ne connais pas le Pascal).
Pas de numéros de ligne (ça complique le goto !), une seule instruction
par ligne.
Le problème n'est pas de coder mais d'apprendre à faire l'algorithme
avant (organiser les tests, les boucles, etc).
Le Fri, 15 Apr 2011 12:06:20 +0200, Lucas Levrel a écrit :
Pour les tout premiers pas, un langage interprété c'est mieux. En ce qui me concerne, j'ai débuté en GFA Basic sur Atari.
AMHA le BASIC est le pire pour apprendre à programmer (GOTO et Cie) Pour apprendre le Pascal est pas mal (turbo pascal entre autre), très lourd mais n'est plus à la mode.
Le GFA est proche du Pascal paraît-il (je ne connais pas le Pascal). Pas de numéros de ligne (ça complique le goto !), une seule instruction par ligne.
Le problème n'est pas de coder mais d'apprendre à faire l'algorithme avant (organiser les tests, les boucles, etc).
Exactement.
-- LL
Lucas Levrel
Le 18 avril 2011, Guillaume Tello a écrit :
L'installateur du programme: 70Mo !! Le tout fait en Delphi avec les gestion des bases de données dont il fallait bien sur installer tous les filtres d'import/export... Un peu plus tard, merveille: le nouveau logiciel tenait sur une disquette 1.44 (notes comprises!). Enfin !
Voilà, il ne faut pas confondre taille du source et taille de l'exécutable.
Il faut voir aussi qu'actuellement on peut dire à un compilateur d'optimiser plutôt la taille de l'exécutable ou plutôt la vitesse d'exécution, choses généralement contradictoires.
Il me paraît par ailleurs impensable d'écrire un programme tout en assembleur qui soit plus performant (en vitesse) que le code généré par un compilateur, sur un processeur moderne. Il y a plein d'instructions siouxes (cf SSEx sur Intel), plusieurs niveaux de cache, et même du pipelining. Sans parler du parallélisme...
-- LL
Le 18 avril 2011, Guillaume Tello a écrit :
L'installateur du programme: 70Mo !!
Le tout fait en Delphi avec les gestion des bases de données dont il
fallait bien sur installer tous les filtres d'import/export...
Un peu plus tard, merveille: le nouveau logiciel tenait sur une
disquette 1.44 (notes comprises!). Enfin !
Voilà, il ne faut pas confondre taille du source et taille de
l'exécutable.
Il faut voir aussi qu'actuellement on peut dire à un compilateur
d'optimiser plutôt la taille de l'exécutable ou plutôt la vitesse
d'exécution, choses généralement contradictoires.
Il me paraît par ailleurs impensable d'écrire un programme tout en
assembleur qui soit plus performant (en vitesse) que le code généré par un
compilateur, sur un processeur moderne. Il y a plein d'instructions
siouxes (cf SSEx sur Intel), plusieurs niveaux de cache, et même du
pipelining. Sans parler du parallélisme...
L'installateur du programme: 70Mo !! Le tout fait en Delphi avec les gestion des bases de données dont il fallait bien sur installer tous les filtres d'import/export... Un peu plus tard, merveille: le nouveau logiciel tenait sur une disquette 1.44 (notes comprises!). Enfin !
Voilà, il ne faut pas confondre taille du source et taille de l'exécutable.
Il faut voir aussi qu'actuellement on peut dire à un compilateur d'optimiser plutôt la taille de l'exécutable ou plutôt la vitesse d'exécution, choses généralement contradictoires.
Il me paraît par ailleurs impensable d'écrire un programme tout en assembleur qui soit plus performant (en vitesse) que le code généré par un compilateur, sur un processeur moderne. Il y a plein d'instructions siouxes (cf SSEx sur Intel), plusieurs niveaux de cache, et même du pipelining. Sans parler du parallélisme...
-- LL
JKB
Le Mon, 18 Apr 2011 10:44:41 +0200, Lucas Levrel écrivait :
Le 18 avril 2011, Guillaume Tello a écrit :
L'installateur du programme: 70Mo !! Le tout fait en Delphi avec les gestion des bases de données dont il fallait bien sur installer tous les filtres d'import/export... Un peu plus tard, merveille: le nouveau logiciel tenait sur une disquette 1.44 (notes comprises!). Enfin !
Voilà, il ne faut pas confondre taille du source et taille de l'exécutable.
Il faut voir aussi qu'actuellement on peut dire à un compilateur d'optimiser plutôt la taille de l'exécutable ou plutôt la vitesse d'exécution, choses généralement contradictoires.
Il me paraît par ailleurs impensable d'écrire un programme tout en assembleur qui soit plus performant (en vitesse) que le code généré par un compilateur, sur un processeur moderne. Il y a plein d'instructions siouxes (cf SSEx sur Intel), plusieurs niveaux de cache, et même du pipelining. Sans parler du parallélisme...
Franchement ? Ça m'étonnerait beaucoup. Lorsque je vous le code généré par un compilo sur une architecture RISC donc assez facile à optimiser, je me dis qu'il y a de la marge et même une grosse marge. Sur un CISC moisi comme le x86, je ne dis pas, sur des architectures de type VLIW comme les DSP TI ou les IA64, c'est même certain, mais dans le cas général, c'est faux.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le Mon, 18 Apr 2011 10:44:41 +0200,
Lucas Levrel <lucas.levrel@u-pec.fr> écrivait :
Le 18 avril 2011, Guillaume Tello a écrit :
L'installateur du programme: 70Mo !!
Le tout fait en Delphi avec les gestion des bases de données dont il
fallait bien sur installer tous les filtres d'import/export...
Un peu plus tard, merveille: le nouveau logiciel tenait sur une
disquette 1.44 (notes comprises!). Enfin !
Voilà, il ne faut pas confondre taille du source et taille de
l'exécutable.
Il faut voir aussi qu'actuellement on peut dire à un compilateur
d'optimiser plutôt la taille de l'exécutable ou plutôt la vitesse
d'exécution, choses généralement contradictoires.
Il me paraît par ailleurs impensable d'écrire un programme tout en
assembleur qui soit plus performant (en vitesse) que le code généré par un
compilateur, sur un processeur moderne. Il y a plein d'instructions
siouxes (cf SSEx sur Intel), plusieurs niveaux de cache, et même du
pipelining. Sans parler du parallélisme...
Franchement ? Ça m'étonnerait beaucoup. Lorsque je vous le code
généré par un compilo sur une architecture RISC donc assez facile à
optimiser, je me dis qu'il y a de la marge et même une grosse marge.
Sur un CISC moisi comme le x86, je ne dis pas, sur des architectures
de type VLIW comme les DSP TI ou les IA64, c'est même certain, mais
dans le cas général, c'est faux.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le Mon, 18 Apr 2011 10:44:41 +0200, Lucas Levrel écrivait :
Le 18 avril 2011, Guillaume Tello a écrit :
L'installateur du programme: 70Mo !! Le tout fait en Delphi avec les gestion des bases de données dont il fallait bien sur installer tous les filtres d'import/export... Un peu plus tard, merveille: le nouveau logiciel tenait sur une disquette 1.44 (notes comprises!). Enfin !
Voilà, il ne faut pas confondre taille du source et taille de l'exécutable.
Il faut voir aussi qu'actuellement on peut dire à un compilateur d'optimiser plutôt la taille de l'exécutable ou plutôt la vitesse d'exécution, choses généralement contradictoires.
Il me paraît par ailleurs impensable d'écrire un programme tout en assembleur qui soit plus performant (en vitesse) que le code généré par un compilateur, sur un processeur moderne. Il y a plein d'instructions siouxes (cf SSEx sur Intel), plusieurs niveaux de cache, et même du pipelining. Sans parler du parallélisme...
Franchement ? Ça m'étonnerait beaucoup. Lorsque je vous le code généré par un compilo sur une architecture RISC donc assez facile à optimiser, je me dis qu'il y a de la marge et même une grosse marge. Sur un CISC moisi comme le x86, je ne dis pas, sur des architectures de type VLIW comme les DSP TI ou les IA64, c'est même certain, mais dans le cas général, c'est faux.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Erwan David
Lucas Levrel écrivait :
Il me paraît par ailleurs impensable d'écrire un programme tout en assembleur qui soit plus performant (en vitesse) que le code généré par un compilateur, sur un processeur moderne. Il y a plein d'instructions siouxes (cf SSEx sur Intel), plusieurs niveaux de cache, et même du pipelining. Sans parler du parallélisme...
Par contre on descent à l'assembleur quand on a besoin d'être très près de la plateforme. La dernière fois que je l'ai fait c'était pour porter le context-switching d'un OS embarqué sur un nouveau processeur. C'était d'ailleurs la seule partie en assembleur, tout le reste était en C.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Lucas Levrel <lucas.levrel@u-pec.fr> écrivait :
Il me paraît par ailleurs impensable d'écrire un programme tout en
assembleur qui soit plus performant (en vitesse) que le code généré
par un compilateur, sur un processeur moderne. Il y a plein
d'instructions siouxes (cf SSEx sur Intel), plusieurs niveaux de
cache, et même du pipelining. Sans parler du parallélisme...
Par contre on descent à l'assembleur quand on a besoin d'être très près
de la plateforme. La dernière fois que je l'ai fait c'était pour porter
le context-switching d'un OS embarqué sur un nouveau processeur. C'était
d'ailleurs la seule partie en assembleur, tout le reste était en C.
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
Il me paraît par ailleurs impensable d'écrire un programme tout en assembleur qui soit plus performant (en vitesse) que le code généré par un compilateur, sur un processeur moderne. Il y a plein d'instructions siouxes (cf SSEx sur Intel), plusieurs niveaux de cache, et même du pipelining. Sans parler du parallélisme...
Par contre on descent à l'assembleur quand on a besoin d'être très près de la plateforme. La dernière fois que je l'ai fait c'était pour porter le context-switching d'un OS embarqué sur un nouveau processeur. C'était d'ailleurs la seule partie en assembleur, tout le reste était en C.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
