Il y a quelques semaines que je lurke ce groupe. Bonne ambiance,
niveau technique plus que correct, bonne intégration du Ptilou,
présence féminine forte, tossa...
Voici mon problème: dans ma jeunesse, j'ai fait beaucoup d'assembleur
sur des procs variés: 6502, z80, 68k, et j'aimerais bien m'y remettre.
Après mures (et myrtilles) réflexions, le PowerPC me semble être un
truc assez 'space' pour ça.
Je vais donc avoir envie d'acheter un Mac. Mais j'aimerais une machine
qui soit à la fois capable de:
- couter pas cher
- tourner un mox récent
- tourner OpenBSD
Je ne recherche pas la performance CPU ultime, mais une machine
sans souci. Disposer d'une entrée/sortie audio, par contre,
serait un plus...
Merci de votre attention, à vous Cognac-Jay.
--
>>Who restarts those when they fail?
> uggc://ra.jvxvcrqvn.bet/jvxv/Ovbybtvpny_ercebqhpgvba
But that's how we get all the lusers!
--{ from alt.sysadmin.recovery }--
On Wed, 12 Sep 2007 16:35:05 +0200, Paul Gaborit wrote:
En fait, on ne programme quasiment plus rien en assembleur. On développe dans un langage évolué et on n'utilise l'assembleur que sur les fonctions les plus critiques.
Je pense que l'OP parlait d'assembleur plus dans un esprit "loisir" que "productivité". :-)
Même en tant que "loisir", il est utopique de croire qu'on peut faire de l'assembleur avec les processeurs récents comme on pouvait en faire avec les processeurs d'antan (je parle d'expérience tant en "loisir" qu'en "productivité").
Et même en supposant acquise la compétence nécessaire à la programmation en assembleur d'un processeur récent, il faut bien que le programme interagisse avec quelque chose (un fichier, le clavier, l'écran...) et là le passage par le système est impératif. Essayer de faire cela propremement en assembleur me semble complètement idiot. Il vaut mieux écrire son programme avec un langage évolué et réserver l'assembleur pour quelques fonctions bien précises (même pour le fun)... Pour les performances, je pense que les compilateurs actuels génèrent du code machine beaucoup plus efficace que 99% des éventuels programmeurs en assembleur dans 99% des cas !
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
On Wed, 12 Sep 2007 16:35:05 +0200, Paul Gaborit
<Paul.Gaborit@invalid.invalid> wrote:
En fait, on ne programme quasiment plus rien en assembleur. On
développe dans un langage évolué et on n'utilise l'assembleur que sur
les fonctions les plus critiques.
Je pense que l'OP parlait d'assembleur plus dans un esprit "loisir"
que "productivité".
:-)
Même en tant que "loisir", il est utopique de croire qu'on peut faire
de l'assembleur avec les processeurs récents comme on pouvait en faire
avec les processeurs d'antan (je parle d'expérience tant en "loisir"
qu'en "productivité").
Et même en supposant acquise la compétence nécessaire à la
programmation en assembleur d'un processeur récent, il faut bien que
le programme interagisse avec quelque chose (un fichier, le clavier,
l'écran...) et là le passage par le système est impératif. Essayer de
faire cela propremement en assembleur me semble complètement idiot. Il
vaut mieux écrire son programme avec un langage évolué et réserver
l'assembleur pour quelques fonctions bien précises (même pour le
fun)... Pour les performances, je pense que les compilateurs actuels
génèrent du code machine beaucoup plus efficace que 99% des éventuels
programmeurs en assembleur dans 99% des cas !
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
On Wed, 12 Sep 2007 16:35:05 +0200, Paul Gaborit wrote:
En fait, on ne programme quasiment plus rien en assembleur. On développe dans un langage évolué et on n'utilise l'assembleur que sur les fonctions les plus critiques.
Je pense que l'OP parlait d'assembleur plus dans un esprit "loisir" que "productivité". :-)
Même en tant que "loisir", il est utopique de croire qu'on peut faire de l'assembleur avec les processeurs récents comme on pouvait en faire avec les processeurs d'antan (je parle d'expérience tant en "loisir" qu'en "productivité").
Et même en supposant acquise la compétence nécessaire à la programmation en assembleur d'un processeur récent, il faut bien que le programme interagisse avec quelque chose (un fichier, le clavier, l'écran...) et là le passage par le système est impératif. Essayer de faire cela propremement en assembleur me semble complètement idiot. Il vaut mieux écrire son programme avec un langage évolué et réserver l'assembleur pour quelques fonctions bien précises (même pour le fun)... Pour les performances, je pense que les compilateurs actuels génèrent du code machine beaucoup plus efficace que 99% des éventuels programmeurs en assembleur dans 99% des cas !
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
laurent.pertois
Luc Heinrich wrote:
Laurent Pertois wrote:
Ah ben voilà, il me semblait bien avoir déjà entendu ce genre de remarques. Maintenant, CW ayant disparu il faut tout ou partie faire à la main, non ?
Je ne suis pas sur de bien comprendre la question... :)
Bah, il n'y a plus CW, il y a XCode qui ne fait pas l'unanimité mais semble intégrer pas mal de fonctionnalités, que faire si on souhaite se passer de ce dernier ? pour taper le code, je pense qu'un TextMate ou autre doit bien passer, maintenant, reste la suite, si on se passe de XCode, il faut le faire à la main non ? (là où XCode est supposé aider, enfin, je le soupçonne d'essayer de le faire croire en tous cas)
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Ah ben voilà, il me semblait bien avoir déjà entendu ce genre de
remarques. Maintenant, CW ayant disparu il faut tout ou partie faire à
la main, non ?
Je ne suis pas sur de bien comprendre la question... :)
Bah, il n'y a plus CW, il y a XCode qui ne fait pas l'unanimité mais
semble intégrer pas mal de fonctionnalités, que faire si on souhaite se
passer de ce dernier ? pour taper le code, je pense qu'un TextMate ou
autre doit bien passer, maintenant, reste la suite, si on se passe de
XCode, il faut le faire à la main non ? (là où XCode est supposé aider,
enfin, je le soupçonne d'essayer de le faire croire en tous cas)
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Ah ben voilà, il me semblait bien avoir déjà entendu ce genre de remarques. Maintenant, CW ayant disparu il faut tout ou partie faire à la main, non ?
Je ne suis pas sur de bien comprendre la question... :)
Bah, il n'y a plus CW, il y a XCode qui ne fait pas l'unanimité mais semble intégrer pas mal de fonctionnalités, que faire si on souhaite se passer de ce dernier ? pour taper le code, je pense qu'un TextMate ou autre doit bien passer, maintenant, reste la suite, si on se passe de XCode, il faut le faire à la main non ? (là où XCode est supposé aider, enfin, je le soupçonne d'essayer de le faire croire en tous cas)
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
luc
Jean-Yves Bernier wrote:
Reste sans doute que les routines de traitement du signal qui sont intéressantes à optimiser (image, son). Mais là, c'est le domaine de l'unité vectorielle ou "multimedia". C'est pour ça que je mentionnais l'Altivec. On peut en attendre des gains de performance considérables.
Même pour l'Altivec il n'y a que rarement besoin de passer par l'assembleur, il existe des API de plus haut niveau qui en plus permettent de ne pas être dépendant du hardware et donc de supporter en même temps Altivec et SSE.
Reste sans doute que les routines de traitement du signal qui
sont intéressantes à optimiser (image, son). Mais là, c'est le domaine
de l'unité vectorielle ou "multimedia". C'est pour ça que je mentionnais
l'Altivec. On peut en attendre des gains de performance considérables.
Même pour l'Altivec il n'y a que rarement besoin de passer par
l'assembleur, il existe des API de plus haut niveau qui en plus
permettent de ne pas être dépendant du hardware et donc de supporter en
même temps Altivec et SSE.
Reste sans doute que les routines de traitement du signal qui sont intéressantes à optimiser (image, son). Mais là, c'est le domaine de l'unité vectorielle ou "multimedia". C'est pour ça que je mentionnais l'Altivec. On peut en attendre des gains de performance considérables.
Même pour l'Altivec il n'y a que rarement besoin de passer par l'assembleur, il existe des API de plus haut niveau qui en plus permettent de ne pas être dépendant du hardware et donc de supporter en même temps Altivec et SSE.
Bah, il n'y a plus CW, il y a XCode qui ne fait pas l'unanimité mais semble intégrer pas mal de fonctionnalités, que faire si on souhaite se passer de ce dernier ? pour taper le code, je pense qu'un TextMate ou autre doit bien passer, maintenant, reste la suite, si on se passe de XCode, il faut le faire à la main non ?
A la main oui, mais n'importe quel outil de build un peu flexible fait l'affaire. Après il y a le problème du debugger, gdb étant la deuxième plus grosse merde produite par le GNU (la première étant bien sur emacs) c'est rarement une partie de plaisir.
Bah, il n'y a plus CW, il y a XCode qui ne fait pas l'unanimité mais
semble intégrer pas mal de fonctionnalités, que faire si on souhaite se
passer de ce dernier ? pour taper le code, je pense qu'un TextMate ou
autre doit bien passer, maintenant, reste la suite, si on se passe de
XCode, il faut le faire à la main non ?
A la main oui, mais n'importe quel outil de build un peu flexible fait
l'affaire. Après il y a le problème du debugger, gdb étant la deuxième
plus grosse merde produite par le GNU (la première étant bien sur emacs)
c'est rarement une partie de plaisir.
Bah, il n'y a plus CW, il y a XCode qui ne fait pas l'unanimité mais semble intégrer pas mal de fonctionnalités, que faire si on souhaite se passer de ce dernier ? pour taper le code, je pense qu'un TextMate ou autre doit bien passer, maintenant, reste la suite, si on se passe de XCode, il faut le faire à la main non ?
A la main oui, mais n'importe quel outil de build un peu flexible fait l'affaire. Après il y a le problème du debugger, gdb étant la deuxième plus grosse merde produite par le GNU (la première étant bien sur emacs) c'est rarement une partie de plaisir.
-- Luc Heinrich
laurent.pertois
Luc Heinrich wrote:
A la main oui, mais n'importe quel outil de build un peu flexible fait l'affaire.
Ok, merci de l'info.
Après il y a le problème du debugger, gdb étant la deuxième plus grosse merde produite par le GNU (la première étant bien sur emacs) c'est rarement une partie de plaisir.
Alalalala, ça va encore dégénérer si on parle d'emacs :-)
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Luc Heinrich <luc@honk-honk.com> wrote:
A la main oui, mais n'importe quel outil de build un peu flexible fait
l'affaire.
Ok, merci de l'info.
Après il y a le problème du debugger, gdb étant la deuxième
plus grosse merde produite par le GNU (la première étant bien sur emacs)
c'est rarement une partie de plaisir.
Alalalala, ça va encore dégénérer si on parle d'emacs :-)
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
A la main oui, mais n'importe quel outil de build un peu flexible fait l'affaire.
Ok, merci de l'info.
Après il y a le problème du debugger, gdb étant la deuxième plus grosse merde produite par le GNU (la première étant bien sur emacs) c'est rarement une partie de plaisir.
Alalalala, ça va encore dégénérer si on parle d'emacs :-)
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
ASM
En réponse à SbM qui écrivit, en date du : 12/09/07 17:08, le message suivant :
ASM wrote:
ha ben j'ai pas copié la totale jack 3,5
MacTracker n'est pas assez précis pour le coup. Tu dois sans doute avoir:
1/ une entrée *ligne* en jack 3,5mm 2/ un micro intégré
Même pour l'Altivec il n'y a que rarement besoin de passer par l'assembleur
En fait quand je parle d'assembleur, je parle de ça:
for (i=0; i<NumPix/4; i++) { ...
C'est du C avec des instructions Altivec.
Pas sûr qu'un optimiseur sache le pondre à partir de pur C, surtout pour les instruction à 3 opérandes.
Pas sur du contraire non plus !! Les compilateurs modernes font parfois des merveilles.
Olivier
olivier.marti
Laurent Pertois wrote:
Luc Heinrich wrote:
A la main oui, mais n'importe quel outil de build un peu flexible fait l'affaire.
Ok, merci de l'info.
Après il y a le problème du debugger, gdb étant la deuxième plus grosse merde produite par le GNU (la première étant bien sur emacs) c'est rarement une partie de plaisir.
Tu as au moins oublié Gnu Hurd dans ta liste ...
Alalalala, ça va encore dégénérer si on parle d'emacs :-)
J'osais pas .. On peut ? Chic !
Olivier (20 ans d'emacs, et encore tout mes doigts qui fonctionnent !!)
A la main oui, mais n'importe quel outil de build un peu flexible fait
l'affaire.
Ok, merci de l'info.
Après il y a le problème du debugger, gdb étant la deuxième
plus grosse merde produite par le GNU (la première étant bien sur emacs)
c'est rarement une partie de plaisir.
Tu as au moins oublié Gnu Hurd dans ta liste ...
Alalalala, ça va encore dégénérer si on parle d'emacs :-)
J'osais pas .. On peut ? Chic !
Olivier (20 ans d'emacs, et encore tout mes doigts qui fonctionnent !!)
A la main oui, mais n'importe quel outil de build un peu flexible fait l'affaire.
Ok, merci de l'info.
Après il y a le problème du debugger, gdb étant la deuxième plus grosse merde produite par le GNU (la première étant bien sur emacs) c'est rarement une partie de plaisir.
Tu as au moins oublié Gnu Hurd dans ta liste ...
Alalalala, ça va encore dégénérer si on parle d'emacs :-)
J'osais pas .. On peut ? Chic !
Olivier (20 ans d'emacs, et encore tout mes doigts qui fonctionnent !!)
