gnx a écrit 420 commentaires

Une version en x86_64, pour Linux. À assembler avec FASM.

Pour l'ASCII étendu, suit l'ISO 8859-15 (aka Latin-9), et donc pas l'UTF-8. Limites en dur pour la longueur de la ligne et des mots.

format ELF64 executable 3

entry _start

TAILLE_BUF=256
TAILLE_MOT=64

segment readable executable

_start:
    XOR RAX, RAX        ; 0 (sys_read)
    XOR RDI, RDI        ; 0 (stdin)
    MOV RSI, bufin      ; adresse du tampon d'entrée
    MOV RDX, TAILLE_BUF ; taille du tampon
    SYSCALL             ; lecture

    MOV [longueur], RAX  ; nombre d'octets lus


    XOR RDI, RDI
teste_nouveau_caractere:
; on teste le nouveau caractère
    CALL nature_caractere
    CMP AL, 0
    JNE nouveau_mot
; ponctuation et divers : on l'écrit tel quel
    MOV [bufout+RDI], DL
    JMP suivant

nouveau_mot:
; lettre : début d'un nouveau mot
    XOR RBX, RBX        ; compteur des caractères du mot
    MOV RSI, RDI        ; mémorise la position (offset) du début du mot
; on recherche la fin de ce nouveau mot en enregistrant pour chaque lettre son type
continue_mot:
    MOV [mot+RBX], DL
    MOV [type_car+RBX], AL
    MOV [casse_car+RBX], AH
    INC RDI
    CALL nature_caractere
    CMP AL, 0
    JE fin_mot
    INC RBX
    JMP continue_mot
fin_mot:
    push RDX

    XOR RCX, RCX
inverse_mot:
; quelle casse faut-il ?
    MOV AL, [casse_car+RCX] ; casse du caractère d'origine
    CMP AL, 0
    JNE minuscule
; majuscule
    MOV AL, [casse_car+RBX] ; casse du nouveau caractère
    CMP AL, 0
    JNE monter_casse
; déjà en majuscule, il faut juste copier
    MOV AL, [bufin+RSI+RBX]
    MOV [bufout+RSI+RCX], AL
    JMP fin_corps_boucle_mot
monter_casse:
    MOV AL, [type_car+RBX]
    CMP AL, 1
    JNE pas_min_std
    MOV AL, [mot+RBX]
    ADD AL, "A"
    MOV [bufout+RSI+RCX], AL
    JMP fin_corps_boucle_mot
pas_min_std:
    CMP AL, 2
    JNE pas_min_acc
    MOV AL, [mot+RBX]
    ADD AL, 0xC0  ; "À"
    MOV [bufout+RSI+RCX], AL
    JMP fin_corps_boucle_mot
pas_min_acc: ; e dans l'o
    mov [bufout+RSI+RCX], 0xBC ; "Œ"
    JMP fin_corps_boucle_mot
minuscule:
    MOV AL, [casse_car+RBX] ; casse du nouveau caractère
    CMP AL, 1
    JNE baisser_casse
; déjà en minuscule, il faut juste copier
    MOV AL, [bufin+RSI+RBX]
    MOV [bufout+RSI+RCX], AL
    JMP fin_corps_boucle_mot
baisser_casse:
    MOV AL, [type_car+RBX]
    CMP AL, 1
    JNE pas_maj_std
    MOV AL, [mot+RBX]
    ADD AL, "a"
    MOV [bufout+RSI+RCX], AL
    JMP fin_corps_boucle_mot
pas_maj_std:
    CMP AL, 2
    JNE pas_maj_acc
    MOV AL, [mot+RBX]
    ADD AL, 0xE0  ; "à"
    MOV [bufout+RSI+RCX], AL
    JMP fin_corps_boucle_mot
pas_maj_acc: ; E dans l'O
    mov [bufout+RSI+RCX], 0xBD  ; "œ"
fin_corps_boucle_mot:
    INC RCX
    DEC RBX
    JNS inverse_mot
; on copie le dernier caractère que l'on vient de trouver
    pop RDX
    MOV [bufout+RDI], DL

suivant:
    INC RDI
    CMP RDI, [longueur]
    JL teste_nouveau_caractere

    MOV RDI, 1          ; 1 (stdout)
    MOV RSI, bufout     ; adresse du message à afficher
    MOV RDX, [longueur] ; nombre d'octets à écrire
    MOV RAX, 1          ; 1 (sys_write)
    SYSCALL             ; écriture

; Exit
    MOV RDI, 0          ; status de sortie = SUCCESS
    MOV RAX, 60         ; 60 (sys_exit)
    SYSCALL             ; exécution de la sortie


;; === ROUTINE nature_caractere ===
;; entrée :
;;   rdi : index caractère dans le tampon bufin
;; sorties :
;;   al  : type du caractère :
;;         0 : ponctuation, divers
;;         1 : lettre standard
;;         2 : lettre accentuée
;;         3 : e dans l'o
;;   ah  : 0 : majuscule
;;         1 : minuscule
;;   dl  : rang du caractère dans le type
;; ===

nature_caractere:
    MOV DL, [bufin+RDI]
test_majuscule:
    CMP DL, "A"
    JB autres
    CMP DL, "Z"
    JA test_minuscule
; majuscule standard
    MOV AL, 1
    MOV AH, 0
    SUB DL, "A"
    RET

test_minuscule: 
    CMP DL, "a"
    JB autres
    CMP DL, "z"
    JA test_edanlo
; minuscule standard
    MOV AL, 1
    MOV AH, 1
    SUB DL, "a"
    RET

test_edanlo:
    CMP DL, 0xBC  ; "Œ"
    JB autres
    JNE test_edanlo_min
; e dans l'o majuscule
    MOV AL, 3
    MOV AH, 0
    SUB DL, 0xBC  ; "Œ"
    RET
test_edanlo_min:
    CMP DL, 0xBD  ; "œ"
    JA test_majuscule_accentuee
; e dans l'o minuscule
    MOV AL, 3
    MOV AH, 1
    SUB DL, 0xBC  ; "Œ"
    RET

test_majuscule_accentuee:
    CMP DL, 0xC0  ; "À"
    JB autres
    CMP DL, 0xDD  ; "Y'"
    JA test_minuscule_accentuee
; majuscule accentuee
    MOV AL, 2
    MOV AH, 0
    SUB DL, 0xC0
    RET

test_minuscule_accentuee:
    CMP DL, 0xE0  ; "à"
    JB autres
    CMP DL, 0xFD  ; "y'"
    JA autres
; minuscule accentuee
    MOV AL, 2
    MOV AH, 1
    SUB DL, 0xE0
    RET

autres: 
    MOV AX, 0
    RET
;; === FIN nature_caractere ===


segment readable writeable

    bufin       RB TAILLE_BUF
    bufout      RB TAILLE_BUF
    mot         RB TAILLE_MOT
    type_car    RB TAILLE_MOT
    casse_car   RB TAILLE_MOT
    longueur    DQ 0

Pas spécialement propre (je dois écrire en moyenne 50 lignes d'assembleur par an…), ni documenté, ni optimisé (mais vus les langages d'urbains épilés présentés dans la plupart des autres propositions, ce programme (binaire de 1364 octets) devrait avoir fini son exécution avant que les autres n'aient fini leur chargement en mémoire). Ne gère pas pas correctement les signes « multiplication » et « division » (pas envie de m'embêter pour ce cas particulier « intelligemment » placé au beau milieu des majuscules accentuées).

À moins que ce soit « une page commune » ? Qu'est-ce que c'est, une « page commune » ?

3 à 6 lignes par categories d'acces ???
ils vont arriver à faire installer 24 lignes ADSL, les Fibres de tous les operateurs dans les 8 centres de mesure ?
Ils vont pas, ils ont fait. As-tu lu le document ?

Ça serait bien que toi et Bortzmeyer le lisiez, avant de reprocher aux autres de ne pas le faire !

Pour la fibre, 2 sites (Schiltigheim et Toulouse) ne sont pas du tout équipés. Et il n'y a en tout et pour tout que 3 lignes Orange et 3 lignes SFR, donc il y a au moins 5 sites sur lesquels ces 2 opérateurs ne sont pas testés pour la fibre.

Pour l'ADSL, le document n'est pas clair du tout pour ce qui est de savoir si chaque opérateur est testé sur tous les 8 sites : « maximum 6 lignes par catégorie et par opérateur » peut laisser entendre que c'est possible, mais « les mesures ont été effectuées sur trois à six lignes par catégorie d’accès, réparties sur huit sites en France métropolitaine » laisse entendre l'inverse. Le plus bizarre en fait, c'est que ce ne soit pas clairement et simplement indiqué quelque part (en tout cas je n'ai pas trouvé).
La seule chose de certaine, c'est que toutes les catégories ADSL ne sont pas testées partout : pas de lignes courtes sur 2 sites (Dijon et Paris).

Par contre, je ne sais pas d'où sortent vos 8 points de mesure à tous les deux.

« Les mesures ont été effectuées sur trois à six lignes par catégorie d’accès, réparties sur huit
sites en France métropolitaine [Dijon, La Garenne Colombes, Marseille, Nantes, Paris, Schiltigheim, Toulouse, Villeurbanne]. »

Notons que ça semble également vouloir dire qu'il n'y a qu'une seule ligne et donc qu'un opérateur testés par catégorie et par lieu… ce qui serait à mon goût très très léger (déjà que 2 des catégories d'ADSL sont justes simulées par rapport à la première !).

Mais comme ce rapport a l'air d'être écrit avec les pieds¹, ce n'est peut-être quand même pas le cas.

Je ne vois pas le problème : on peut voir en bas à droite de ta capture que tu as sélectionné comme moyen de locomotion le F-106, qui met bien le temps indiqué pour effectuer ce trajet (pause café comprise).

Ça tombe bien, ils lèvent des fonds pour des sujets précis. Ici c'était défendre leur nom en justice (libre à toi de ne pas participer).

C'est tellement précis qu'ils ne vont pas les utiliser pour ça (et c'était écrit que ça se passerait ainsi dans le « contrat »).

Pareil, je n'ai jamais été confronté à des FPGA dans le rôle d'accélérateurs matériels. J'ajouterais à ce que tu dis la possibilité d'avoir à disposition une énorme quantité d'I/O numériques (et, outre le nombre, rapides et sans latence, si c'est le besoin).

VHDL et Verilog seront toujours utilisés pour les interfaces/IP très optimisées. Pour le reste les techniques de HLS sont en train de les remplacer.

Hum… déjà que ce n'est pas toujours évident d'estimer la complexité de ce qui va être généré par un synthétiseur à partir d'un HDL (VHDL, Vérilog, etc.), avec ça, on risque d'aller au carnage. Surtout qu'avec l'apparence de langages classiques qui camouflera quasi-totalement ce qu'on génère, on risque d'y coller des purs softeux qui n'ont aucune idée de la nature et des contraintes sous-jacentes : autant dire qu'on n'a pas le cul sorti des ronces.

Alors soyons clair, les deux langages sont relativement mauvais, verbeux, mal standardisés et sujet à interprétation en fonction de l'outil utilisé.

Tu peux illustrer s'il te plait? Je crois que souvent on confond ces langages matériels avec des langages informatiques (je sais pas comment dire).

Ouais, non, ce n'est pas vraiment ça le problème, c'est que c'est vraiment (je parle surtout du VHDL) lourdingue parce que hyper-verbeux (mots-clé, begin - end machin, déclaration/instantiation des entités, conversion de types, etc.), irrégulier / pas orthogonal, parce qu'on n'utilise que 10% du langage (et que les 90% n'apportent que confusion lorsqu'on débute, ne sachant pas ce qui est utile et qui ne l'est pas), parce que le langage ne fait pas la différence entre ce qui est synthétisable et ce qui ne l'est pas (normal d'un certain point de vue mais du coup on marche sur des œufs et on se contente des 10% dont on est à peu près sûr, sinon on s'expose à de mauvaises surprises), parce que le support des attributs ou même juste des valeurs initiales dépend des outils utilisés, parce qu'il n'y a pas de préprocesseur défini…
Certains points se sont améliorés au fil de l'évolution du standard (irrégularités) et des outils (plus de trucs compris et synthétisables, support des attributs, packages), mais putain, c'est quand même toujours bien relou.

Du Verilog, je n'en ai jamais beaucoup écrit ; m'a semblé un peu abscons, pour un gain en concision /légèreté insuffisant.

SystemVerilog a l'air pas mal, mais je n'ai fait que parcourir un ou deux bouquins et je n'ai pas écrit de vrai code car les outils gratuits (au moins chez Xilinx) qui comprennent ce langage ne sont utilisables que pour les composants de dernières générations et pas pour les précédents :-(

Sinon, le mieux, le plus clair, le plus concis, c'était mon langage à moi, qui ne reprenais que les quelques concepts que j'utilisais en VHDL sans sa lourdeur, avec une apparence un peu "C". Mais il y a juste un petit problème : je n'ai jamais écrit de compilateur/traducteur vers un autre langage, donc une fois le programme écrit, tout ce qu'on peut en faire, c'est le mettre à la poubelle :-D

Ps : le tor*t* tue.

Mais heureusement que ce n'est pas le cas du ridicule.

Posté par Zenitram le 11/11/14 à 23:03.

Tu torts mes dires pour qu'ils t'arrangent.

Pouf pouf :-D

Pour immerger les utilisateurs dans une ambiance « salle de réunion »

Oh putain l'horreur !

T'es gentil mais on parlait du hitman payé en bitcoins…

Maintenant, très probablement. Au départ, j'en suis beaucoup moins convaincu.

Pour le moment, ça semble être des conneries, tout ce que les gens ont trouvé jusqu'ici, c'est une blagounette sur un canal IRC (non lié à systemd ou à la LKML) comme je crois qu'on a pu en lire ici-même, et pas le début du commencement d'envisager l'amorce de sa mise en pratique.

Non, il ne dit pas juste ça.

the Open Source community is full of assholes

The Internet is full of deranged people,

there are certain communities where it appears to be a lot more accepted to vent hate, communities that attract a certain kind of people (Hey, Gentoo!)

I'd actually put some blame on a certain circle of folks that play a major role in kernel development, and first and foremost Linus Torvalds himself.

C'est vraiment lui qui écrit ça ??? Donc, il est entouré de trous du cul et de malades mentaux, et le pire d'entre eux est Linus Torvalds. Bien, bien, bien…

Pour cela, il aurait fallu qu'il ait une idée d'où il voulait aller, et je ne crois pas que ç'ait été le cas.

Pour la protection de vos enfants, venez manifester contre l'infection de l'enseignement supérieur par la théorie du genre.

Halte à la féminisation des processus !!!

OK, merci pour les corrections et précisions. Encore faut-il avoir suffisamment de trafic et/ou de clients, pour lâcher les centaines d'euros que doit coûter la licence.

Oui, ça serait beaucoup plus simple avec du libre.

comment le relay peut-il être sûr qu'il bloque 100% des spams ? (ou plus exactement: les mêmes spams que ceux qui seront aussi détectés par OVH, si ce dernier est susceptible de bloquer le serveur au premier SPAM détecté…)

Surtout que si je me rappelle bien, OVH utilise un logiciel propriétaire (ou un matériel ?) de détection, ne veut pas le proposer comme service aux gens qui en auraient besoin pour ces cas là, et ne veut pas en donner les règles. Donc tu vas forcément sortir du spam au sens OVH même si tu filtres toi-même. Alors que si tu chiffres, tu peux envoyer autant de spam que tu veux, puisqu'OVH se fiche de lutter contre le spam, le seule chose qui les intéresse, c'est de ne pas se faire blacklister trop d'IP parce qu'après, les clients râlent et s'en vont.

Comme je disais au début, c'est de mémoire donc je peux me mélanger les pinceaux et ça peut avoir changé.

C'est ce que Tatave répond à tous ceux qui ont le même problème, en tous cas.

Plutôt :

On est tous un peu autiste quelque part…

Pfff, en HQ9+ :

H

Super, la nouvelle interface hipster flat de mes 2.0 : elle ne fonctionne pas sur mon vieux portable. Je ne parle même pas des animations qui te sautent à la gueule en prenant 100% de CPU mais de l'IDE qui ne marche pas du tout.

On peut conduire une bagnole sans rien comprendre au fonctionnement du moteur ou de la boite de vitesse.

Les comparaisons avec l'auto sont toujours périlleuses. Si on ne comprend pas du tout le fonctionnement de la boîte on va au devant de gros soucis assez rapidement.