Discussion :

[LLB]

Un autre test :

Code :

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

1
2
3
4
5
int mod(int n, int k)
{
  if (n >= k) return mod(n - k, k);
  return n;
}

Pourquoi mod(500000, 2) plante à l'exécution, alors que presque tous les compilateurs C savent calculer le résultat ? C'est encore une autre optimisation classique.

[Marc.Samuro]

LLB : Marc.Samuro : pour un langage plus sûr, mais avec les mêmes performances que le C, je suggère Lisaac. Il a été conçu comme langage pour écrire un OS (il a donc tout ce qu'il faut de bas-niveau et se mélange facilement avec le C...

j'ai été voir le site de Lissac .. on ne peut pas dire que ce soit un langage conventionnel .. je cite : "ce langage est minimaliste avec l’absence de construction pour les conditionnelles, les boucles et les itérations". Cela donne une syntaxe assez spéciale à laquelle peu de programmeurs pourront s'habituer .. c'est expérimental bien sûr.

[gl]

Je suis vraiment désolé, je continue à penser que c'est un travail impressionnant, mais qu'il n'apporte rien d'intéressant par rapport à des projets existant, tels que Cyclone :-\

Ca résume assez bien mon ressenti également.


Je vais essayer de prendre le temps de lire le document fourni et de faire quelques tests pratiques avec le compilateur ce we

Au vue des premiers résutats obtenus par LLB, j'ai la vague impression que l'implémentation de ton compilateur est très naïve (comprendre par là que tu fait une simple conversion un pour un des instructions safe-C vers l'assembleur).

[TropMDR]

il faut poser la question autrement : comment cyclone rend-il l'incrémentation de pointeurs sûre ? en vérifiant chaque fois que le pointeur est toujours dans une zone mémoire donnée, par deux tests : p >= début && p < début + longueur.

N'importe quoi... Cyclone incrémente un pointeur en... incrémentant le pointeur. C'est à l'accès que le test de validité est fait (et eux, ils éliminent les tests inutiles...)

Il est bien plus économique d'utiliser un tableau et de ne faire qu'un seul test non-signé sur l'indice. En résumé : l'incrémentation de pointeur safe n'a plus aucun avantage sur les indices de tableaux.

Les indices ne permettent pas de considérer un sous tableau comme un tableau à part entière, et encore moins d'avoir un pointeur vers une sous structure.

Si ta seule utilisation du C est de parcourir un tableau, en accédant à chaque case via son indice, quel est l'intérêt de faire du C ? Pourquoi utiliser un langage si bas niveau, avec des types si faible, si ce n'est pas pour exposer un minimum la structure des types de donnée sous jacent ? Pour poser la question différemment, quelle est la cible, l'utilisation typique, de ton langage ?

[TropMDR]

Temps d'exécution sur ma machine :
C# : 00.580 s
Safe-C : 09.838 s

Holy crap !@#

Est ce qu'on peut voir l'assembleur produit par: (désolé, je n'ai toujours pas windows )

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
 
int foo (int i){
  int x = 5;
  int y = x * 10;
  int z = 0;
  if(i < 0){
    x = 1;
    z = 3;
  }else{
    x = 2;
    z = 3;
  }
  if(y==50)
    x = 5;
  if(z <> 3)
    x = 12;
  return (x + y + z);
}

ou encore

Code :

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

1
2
3
int bar(int[10] t){
  return t[4];
}

ou bien

Code :

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

1
2
3
4
 
  int baz(int[] t){
  return (t[3] + t[3]);
}

Est ce que

Code :

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

1
2
3
4
 
int tab5(int[5] t){return t[2];}
 
int tab10(int[10] t){return tab5(t);}

est bien accepté ? Si oui, est ce que tab5 est inliné ?

est ce que

Code :

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

1
2
3
4
 
int tab10(int[10] t){return t[2];}
 
int tab5(int[5] t){return tab10(t);}

est bien rejeté ?

[jabbounet]

je viens de lire rapidement ce post, et j'ai une petite question.

personnellement quand on me parle de sûreté de fonctionnement ou de langage sécurisé j'ai tendance a penser à ADA.

Comment safe-c se démarque t'il par rapport a ce langage?

[orfix]

Tout le monde n'a pas windows...

+1
Pas de code source non plus

[Marc.Samuro]

j'ai regardé hier comment un compilateur optimisé traduisait :

Code :

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

1
2
3
 
  for (i = 0; i < arr.Length; i++)
    arr[i] = 2;

c'est assez remarquable : au lieu de faire une boucle ou d'utiliser des indices, il traduit ceci en 1 seule instruction assembleur: un "rep movsb" donc instruction avec répétition. Donc pas étonnant que ça aille 20x plus vite. Cela ne marche évidemment que pour une boucle avec limites constantes avec exactement "ces" instructions.

J'en conclus que pour optimiser ce genre de boucle le compilateur doit probablement comparer le modèle de boucle avec des centaines de modèles de boucles standard simples qu'il garde dans une bibliothèque, et encore ça ne marche que sur un microprocesseur particulier qui a le genre d'intructions curieuses comme rep movsb. Bref, dur dur d'optimiser ..

personnellement quand on me parle de sûreté de fonctionnement ou de langage sécurisé j'ai tendance a penser à ADA.

Comment safe-c se démarque t'il par rapport a ce langage?

Ada a la fiabilité totale du logiciel comme objectif (en vérifiant les overflows, en imposant des contraintes d'intervalle autorisés aux variables, etc ..), alors que le Safe-C ne garantit qu'une fiabilité mémoire (on ne doit pas pouvoir écrire en dehors de la zone mémoire des variables). Une autre différence est qu'un compilateur Ada est environ 10 fois plus grand qu'un compilateur Safe-C, cela donne une idée de la taille du langage Ada, maintenant vous me direz on n'est pas obligé d'utiliser tout le langage bien sûr.

j'ai beaucoup d'admiration pour les concepteurs d'Ada (qui sont français disons-le en passant), j'ai étudié la version 1983 de ce langage en détail quand il a été publié. Il ont vraiment montré ce qu'était un langage pour les applications très sécurisées (ex: sous-marins nucléaires, missiles, Ariane, signalisation du tunnel sous la manche) en vérifiant absolumment tout et en misant sur la clarté d'écriture. Le manuel de référence de 1983 est un exemple de précision et d'exactitude.

Ensuite j'ai été horrifié en voyant comment les gens du Département de la Défense avaient modifié Ada durant la révision 1995 du langage : Ada était déjà un langage énorme, mais là il explosait carrément en complexité et en règles de toutes sortes. Il auraient pu le simplifier et retirer des choses, mais là ça a été un désastre. Heureusement ils sont restés compatibles avec Ada83.

Ada a choisi une syntaxe 'Pascal' qui est sans doute plus lourde à écrire, actuellement tous les langages utilisent la syntaxe 'C'. Pour un slice de tableau en Ada on doit spécifier l'indice inférieur et supérieur au lieu de l'indice inférieur et de la longueur comme j'ai choisi en Safe-C, ce qui rend assez complexe les calculs d'indice et de strings (ça ne se voit pas quand on étudie le langage, mais -j'ai écrit pas mal de code source Ada- ça donne une impression de lourdeur quand on l'utilise).

On ne peut que recommander d'étudier Ada au niveau théorique, on en apprend beaucoup. Au point de vue utilisation pratique le langage est un peu lourd à utiliser parce que la syntaxe Pascal a des conséquences de toutes sortes (par ex: les tableaux ne commencent pas forcément à zéro ce qui peut sembler un mieux pour le programmeur, mais en fait à l'usage, gérer 2 bords de tableau se révèle plus complexe qu'un seul).

Je me suis inspiré d'Ada pour certains concepts (sécurité, librairies, packages et génériques) en les simplifiant fortement, et même en avoir amélioré certains ce qui n'est pas difficile 15 ans après et vu les nombreuses réactions et propositions qu'à eu Ada dans les revues spécialisées.

En Ada les structures (appelés records) incluent le discriminant, alors qu'en Safe-C il est stocké à l'extérieur.

Ada a introduit les mode de passage de paramètres in, in out, et out. Une très bonne idée pour clarifier, mais beaucoup de gens considèrent maintenant qu'un mode 'ref' aurait été mieux que 'in out' (ça crée une faille qui a été publiée, mais il est trop tard pour changer).

Ada a choisi de ne pas préciser la longueur d'un "integer", ce qui fait que chaque implémentation peut avoir une taille différente. Au lieu de ça Ada permet de "construire" soi-même un type "int" dans le range qu'on souhaite. Mais à force de vouloir faire trop théorique, ça en devient compliqué. Il est bien plus simple de fixer dans le standard que int c'est 4 bytes. En 1983 il n'était sans doute pas encore certain que toutes les machines utiliseraient des bytes à 8 bits (certaines en avaient 9), Ada voulait être sûr de pouvoir être portable partout donc ne précisait rien sur la longueur des types. Le C a d'ailleurs ce même problème de non-portabilité des types de base.

Kernigan et Richie ont créé le C sur le tas grâce à leur expérience pratique, les concepteurs Ada sont partis d'un cahier des charges avec une approche théorique, méthodique et organisée. Pour faire un bon langage il faudrait idéalement les deux.

p.s: il faut que je me cache maintenant au cas où un adepte d'Ada passerait sur le forum, j'ai déjà les gens de C++ et cyclone qui veulent ma peau, sans parler des spécialistes en compilateurs optimisés

[TropMDR]

j'ai regardé hier comment un compilateur optimisé traduisait :

Code :

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

1
2
3
 
  for (i = 0; i < arr.Length; i++)
    arr[i] = 2;

c'est assez remarquable : au lieu de faire une boucle ou d'utiliser des indices, il traduit ceci en 1 seule instruction assembleur: un "rep movsb" donc instruction avec répétition. Donc pas étonnant que ça aille 20x plus vite. Cela ne marche évidemment que pour une boucle avec limites constantes avec exactement "ces" instructions.

Avant d'aller jusque là, ce qui nécessite effectivement de reconnaitre des patterns complètement ad hoc, il y a plein d'autres optimisations à faire. (J'aimerais d'ailleurs toujours que quelqu'un m'envoie l'asm produit pour les exemples cités plus haut, pour faire un peu de reverse enginiering sur les optims du compilo safe-C, puisque je n'arrive pas à obtenir d'info autrement)

Bref, dur dur d'optimiser ..

De l'intérêt de ne pas écrire son propre back-end...

[Marc.Samuro]

J'aimerais d'ailleurs toujours que quelqu'un m'envoie l'asm produit pour les exemples cités plus haut, pour faire un peu de reverse enginiering sur les optims du compilo safe-C, puisque je n'arrive pas à obtenir d'info autrement

bon je vais jouer la transparence : le compilateur Safe-C version 1.0 pour Windows que je propose sur mon site a un niveau d'optimisation très légèrement supérieur au compilateur Visual-C 6.0 de Microsoft quand on ne lui met aucune option d'optimisation. Il ne fait pas les inlines (mais c'est prévu), il ne combine pas encore plusieurs instructions mais traduit chacune en assembleur séparemment.

Rendez-vous l'année prochaine sans doute pour une version 2.0.

Cette année ma priorité c'est d'avoir des librairies puissantes et simples à utiliser, et couvrant tous les domaines (fenêtres, traitement d'image, réseau, encryption, fichiers isam, ..). J'ai ces librairies en C, je voulais initialement les convertir simplement en Safe-C mais je me suis pris au jeu à les améliorer et à les moderniser donc ça me prend plus de temps que prévu.

[Thierry Chappuis]

Je n'ai pas l'habitude de réveiller un fil qui dort depuis deux mois, mais j'ai eu du plaisir à suivre la discussion, même avec un petit décalage

Ada a choisi une syntaxe 'Pascal' qui est sans doute plus lourde à écrire, actuellement tous les langages utilisent la syntaxe 'C'.

Le point de vue exposé ici est tout de même très réducteur et pas très à jour. Si le lien de parenté entre C, C++, C# et Java est relativement clair, il existe tout de même d'autres langages très populaires qui se démarquent du C. Si python ou ruby ne sont pas des parents si éloignés, Lisp est encore plus utilisé que ce que j'ai pu lire dans ce fil. Sinon, Erlang, Haskell ou OCaml sont loin d'être seulement des curiosités et proposent aujourd'hui des performances intéressantes et un paradigme de programmation intéressant pour certains types d'application.

En ce qui concerne la conception des langages de la "famille" du C, on a me semble-t-il déjà pas mal fait le tour de la question. Aujourd'hui, je n'ai pas l'impression qu'il y a encore de la place pour un nème langage C-like. Pour innover, il convient de plancher sur de nouveaux paradigmes permettant de supporter efficacement les défits auxquels est confronté le programmeur d'aujourd'hui. Dans ce contexte, Erlang, conçu par Ericsson, se profile par exemple comme une technologie intéressante pour les systèmes concurrents et temps réel.

En ce qui concerne les benchmarks proposés dans ce fil, c'est toujours une tâche délicate de les évaluer à leur juste valeur. Sur des tests bien choisis, le RPython de PyPy s'est montré plus rapide que le C. Un programme python tournant sur un PyPy JITé, bien que plus rapide que l'implantation CPython de référence, reste toutefois en moyenne significativement plus lent qu'un programme écrit en C. Toutefois, pour 80% du code scientifique que je suis amené à produire, python se montre simple d'utilisation, propose une performance satisfaisante et offre le niveau de sécurité mémoire 100%. J'ai également fait quelques tests avec OCaml pour du code scientifique. Les performances de ce langage sont intéressantes et la philosophie sous-jacente est très différente du C.

Thierry

[acx01b]

Salut,

je trouve l'idée du Safe-C extrêmement intéressante du point de vu web/hébergeur de CGI sur des serveurs non dédiés :

Imaginons que je suis un hébergeur de sites web : j'ai des serveurs dédiés, avec en moyenne 500 sites web par serveur.

Bien sûr, il est hors de question que l'un des 500 sites web puisse faire bugger tout le serveur, et donc aussi les 499 autres sites web qui n'ont rien demandé.

Donc, je n'accepte comme applications que du php, du perl, du python, du java servlet, ou du javascript node.js.

Mais pourquoi pas également accepter les codes-sources C/C++ à condition que je les compile moi même, avec un compilateur spécial.
Compilateur qui n'accepte que les codes C/C++ "safe". Ce type de compilateur produit du code "safe" : partout où c'est nécessaire il ajoute les vérifications de pointeurs et de dépassement de tableau. Bien sûr, on ne peut pas "linker" avec n'importe quelle librairie, uniquement LA librairie wrapper vers les quelques fonctions systèmes autorisées.

Le problème c'est : ce langage, C/C++ "safe", il doit être proche au maximum du C/C++ pour que ça ne soit pas difficile de convertir un CGI lambda écrit en C/C++ en une version safe que le compilateur de l'hébergeur web acceptera.

ça m'intéresserait beaucoup marc.samuro, si tu es toujours là, d'avoir ton avis sur ce langage le plus proche du C/C++ possible, et sur le compilateur correspondant.

[Sve@r]

Salut,

je trouve l'idée du Safe-C extrêmement intéressante du point de vu web/hébergeur de CGI sur des serveurs non dédiés :

Imaginons que je suis un hébergeur de sites web : j'ai des serveurs dédiés, avec en moyenne 500 sites web par serveur.

Bien sûr, il est hors de question que l'un des 500 sites web puisse faire bugger tout le serveur, et donc aussi les 499 autres sites web qui n'ont rien demandé.

Salut
Si tu as tes serveurs sur des os multiutilisateurs/multitâches (typiquement les Unixlike) et que tu as un serveur web adapté à ces os (style Apache) alors tu n'auras aucun souci. Chaque cgi/bin sera exécuté dans un processus totalement indépendant et si un cgi/bin plante, il ne plantera que ce processus. Ainsi non seulement les 499 autres sites web seront protégés mais même le site qui aura lancé le cgi/bin foireux restera lui-aussi actif (du moins pour les pages qui n'utilisent pas ledit cgi/bin)...

[dragonno]

Je suis époustouflé quand même du travail accompli.

Je ne reviendrais pas sur ce qui a été dit pour ou contre, même s'il reste beaucoup de travail à faire en optimisation du compilo d'aprés ce que j'ai pu lire tout au long du topic, mais rappelons que Marc Samuro a précisé d'avance que son compilo n'était certainement pas des meilleurs, que l'on pouvait mieux faire et qu'il l'avait fait pour rendre concret son étude (syntaxe etc) de Safe-C.

18:58 h... annonce de l'écriture d'un tuto pour programmeur expérimenté.
0:43 h... Postage du lien vers le tuto.

ça c'est de la motivation^^

Je rajouterais que Marc Samuro il ne faudrait pas que les oppositions à ton idée t'empêchent de continuer ton projet, car même si ton projet aboutit et se distribue, cela n'empêchera pas tes opposants de dormir, par contre ceux qui auront choisi ton Safe-C en toute connaissance de cause, soit ils lui donneront une place dans le monde des langages de programmation, soit ils reviendront à un autre langage plus courant après avoir été éventuellement déçus, continue, optimise, c'est une démarche qui te plaît en plus, et l'avenir dira ce qu'il en est

PS : Edit fait pour corrections.

[Sve@r]

Je rajouterais que Marc Samuro il ne faudrait pas que les oppositions à ton idée t'empêchent de continuer ton projet, car même si ton projet aboutit et se distribue, cela n'empêchera pas tes opposants de dormir, par contre ceux qui auront choisi ton Safe-C en toute connaissance de cause, soit ils lui donneront une place dans le monde des langages de programmation, soit ils reviendront à un autre langage plus courant après avoir été éventuellement déçus, continue, optimise, c'est une démarche qui te plaît en plus, et l'avenir dira ce qu'il en est

+1. Ce n'est pas parce que certains (comme moi) ne sont absolument pas tentés que ça ne plaira pas à d'autres...

[jabbounet]

Je rajouterais que Marc Samuro il ne faudrait pas que les oppositions à ton idée t'empêchent de continuer ton projet, car même si ton projet aboutit et se distribue, cela n'empêchera pas tes opposants de dormir, par contre ceux qui auront choisi ton Safe-C en toute connaissance de cause, soit ils lui donneront une place dans le monde des langages de programmation, soit ils reviendront à un autre langage plus courant après avoir été éventuellement déçus, continue, optimise, c'est une démarche qui te plaît en plus, et l'avenir dira ce qu'il en est

Il est toujours intéressant d'avoir des points de vue divergeant sur un projet, cela permet de mettre en évidence ses points faible ou ses manques et donne donc des possibilité de les corriger.

[dragonno]

Effectivement Jabbounet
Personne n'a jamais dit le contraire