■_
アラン・チューリング生誕100年とかなんとか。
2012年05月10日
■_ C!
階層構造を持ったモジュール云々という話に関しては、 オブジェクト(と実行ファイル)にも踏み込まないとダメじゃないかなあ とは常々思ってます。 詳しくは書かないけどw
C! - system oriented programming - LSE Blog C! - system oriented programming Written by Marwan Burelle May 09, 2012 at 14:52 This is a first article, intended to be an introduction to to C!, more articles presenting syntax and inner parts of the compiler will follow. C! is one of our projects here at LSE (System Lab of EPITA.) It is a programming language oriented toward lower-level system programming (kernel or driver for example.) C! は(カーネルやドライバーのような)低水準のシステムプログラミングを指向したプログラミング言語です We were looking for a modern programming language for kernel programming and after trying some (D, C++, OCaml … ) it appears that most of them were too oriented toward userland to be used in kernel programming context. わたしたちはカーネルプログラミングのための modern なプログラミング言語を探していて いくつかの言語は試してみました(D、C++、OCamlなどなど)のですが、 それらのほとんどはカーネルプログラミングのコンテキストでは ユーザーランド向けの開発を指向しすぎていているように思われたのです。 So we decide to modify and extend C to fit our need and quickly aim toward a new programming language: C! そこでわたしたちは自分たちのニーズを満たすためにCを改修し拡張して 新しい言語を作り出すことを目指すことにしたのです。それが C! Modern languages and kernel programming modern な言語とカーネルプログラミング Most parts of kernel code are rather classical: data structures, algorithms and a lot of glue. But, some crucial aspects require lower-level programming: direct management of memory, talking to specific CPU part (interruption management, MMU … ), complete control over data layout, bit-by-bit data manipulation … カーネルのコードの大部分はとても classical なものです。 データ構造があり、アルゴリズムがあり、そしてたくさんの glue (糊)。 しかし、一部の重要なものは低水準 (low-level) のプログラミングを要求しているのです。 それはメモリーの直接的な管理であったり、CPU の特定の部分(割り込みの管理、MMU、など) とのやりとり、データのレイアウトについての完全な制御、ビットごとのデータ操作など といったものです。 Thus, to write some kernel code (or a complete kernel) we need a native language with direct access to this kind of low-level operations. This implies the ability to include ASM code somehow, to manage function calls from ASM and to build standard functions (so you can have function pointers for various interruption mechanisms.) ですから、一部のカーネルコード(あるいは完全なカーネル)を記述するためには 今挙げたような低水準操作に対する直接的なアクセスができる native な言語が 必要なのです。これはアセンブラからの関数呼び出しの管理や 標準関数群を構築するためにアセンブリコードの類を取り込む能力を仮定しています (さまざまな割り込み機構のために関数ポインターも持てます)。 And, since you're not in user-land, you can't use user-land facilities (standard system libs for example). For most languages this means that you must rewrite memory allocators and tools that come shipped with them (especially for managed memory languages using garbage collection). さらに、ユーザーランドにいないのでユーザーランドの facilities (たとえば標準システムライブラリ) を使ったりはできません。 大部分の言語にとってこれはメモリアロケーターやそれに付随するツールを 書き直さなければならないことを意味します (特に、ガーベジコレクションを使っている managed memory な言語の場合)。 Another issue is the binary format: when writing user-land programs, your compiler builds a file suited for the kernel binary loader. On most current Unix systems, your file will respect the ELF format. Of course, you can write an ELF loader in your bootloader (or any part of your booting process for that matters) but since you are managing memory and memory mapping, you can't rely on the way a program is loaded on your system and thus the organization of your ELF must reflect these constraints. もうひとつの問題はバイナリーフォーマットです。 ユーザーランドのプログラムを記述するとき、コンパイラーはカーネルのバイナリローダー に合わせたファイルを作り出します。 現状の大半のUnixシステムでは、ELFフォーマットを期待できるでしょう。 もちろんあなたのブートローダー(や、ブートプロセスの任意の部分)で ELFローダーを書くことができます。けれども、メモリやメモリーのマッピングは あなたが管理しているのでプログラムがあなたのシステムにロードされることは 期待できないのです。したがって、ELF であってもこういった制約を反映した 構造にしなければなりません。 Of course, this issue is not language dependent, even with a pure ASM or C kernel, you will have to control the way your linker builds the final binary. But, in C (and obviously in ASM) there are no major issues there, the structure of your program will be sufficiently simple so that the only important question is: where will I be in memory? もちろんこの問題は言語に依存したものではありません。 pure なアセンブラや C のカーネルに対してさえ リンカーが最終的にビルドする手法をコントロールしなければならなくなるでしょう。 So, what's wrong with modern languages? では、modern な言語で間違っていることとはなにか? For the most evolved ones such as languages with transparent memory management and garbage collection, one of the most important problem is to provide a replacement for all aspects of the standard libraries of the system: memory allocator, threads and locks management, etc. And in that case some aspects just can't be rewritten the same way it is in user-land. The C++ situation is somehow better and worse: in theory there is less runtime needs than most modern languages. The good part is that you can bypass the most problematic elements of C++ (such as RTTI or exceptions) so you don't have to fight against them. Once you've deactivated problematic features and found what can't be used without them, you have to provide runtime elements needed by your code: start-up code, pure virtual fallback, dynamic stack allocation code, dynamic memory allocation for new and delete operators (for objects and array) … Roaming here and there, you'll find documentation on how you can write your C++ kernel, but let's face it: is the required work really worth the pain? What's wrong with C (Cで間違っているところ) So, if you're still reading me, this means that you're partially convinced that using C++ (or D, or OCaml, or … ) is not a good idea for your kernel. But, why not go on with the good old C programming language? Since it was designed for that job, it is probably the best (or one of the best) fit for it. But, we want more. Here is a quick list of what we may find wrong or missing in C: C に欠けていたりCが間違っていること The C syntax contains a lot of ambiguous traps C の構文にはたくさんの ambiguous なわながある While the type system of C is basically size based, a lot of types have an ambiguous size (int for example) C の型システムは大きさに基づいたものであるにもかかわらず型の多くはその大きさが曖昧である Controlling size and signedness of integers is often painful 整数の大きさや符号を操作することは大抵 painful である There is no clean way to provide some form of genericity or polymorphism genericity や polymophism (多態) といったものを提供するための clean な方法がない There's no typed macros 型付きマクロがない The type system and most static verification mechanisms are too basic compared to what could be done now 型システムや静的な検査機構の大部分が今の時代には basic なものすぎる C miss a namespace (or module) mechanism 名前空間やモジュールの機構がない While you can do object oriented programming, it is tedious and error prone オブジェクト指向プログラミングが可能ではあるけれど In fact, the above list can divided in two categories: 上記のリストは二つのカテゴリに分けられます syntax and base language issues 構文と言語の基本的な部分の問題 missing modern features 欠けている modern な機能 Genese of C! Once we stated what was wrong with C, I came up with the idea that we could write a simple syntactic front-end to C or a kind of preprocessor, where we would fix most syntax issues. Since we were playing with syntax, we could add some syntactic sugar as well. We then decided to take a look at object oriented C: smart usage of function pointers and structures let you build some basic objects. You can even have fully object oriented code. But while it is dead simple to use code with object oriented design, the code itself is complex, tedious, error prone and most of the time unreadable. So, all the gain of the OOP on the outer side, is lost on the inner side. So why not encapsulated object oriented code in our syntax extension ? But, OOP means typing (Ok, I wanted static typing for OOP.) And thus, we need to write our own type system and type checker. Finally, from a simple syntax preprocessor, we ended up with a language of its own. Compiler-to-compiler Designing and implementing a programing language implies a lot of work: parsing, static analysis (mostly type checking), managing syntactic sugar, and a lot of code transformations in order to produce machine code. While syntactic parts and typing are unavoidable, code productions can be shortened somehow: you write a frontend for an existing compiler or use a generic backend such as LLVM. But you still need to produce some kind of abstract ASM, a kind of generic machine code that will be transformed into target specific machine code. The fact is that a normal compiler will already have done a lot of optimization and smart code transformation before the backend stage. In our case, this means that we should do an important part of the job of a complete C compiler while we are working with code that is mainly C (with a different concrete syntax.) The last solution (the one we chose) is to produce code for another compiler: in that case all the magic is in the target compiler and we can concentrate our effort on syntax, typing and extensions that can be expressed in the target language. Based on our previous discussion, you can deduce that we chose to produce C code. Presenting all aspects of using C as a target language will be discussed further in a future article. Syntactic Sugar An interesting aspect of building a high-level language is that we can add new shiny syntax extensions quite simply. We decided to focus on syntax extensions that offer comfort without introducing hidden complexity. Integers as bit-arrays ビット配列としての整数 In lower-level code, you often manipulate integers a bit at a time, so we decided to add a syntax to do that without manipulating masks and bitwise logical operands. Thus, any integer value (even signed, but this may change, or trigger a warning) can be used as array in left and right position (you can test and assign bit per bit your integer!). A small example (wait for the next article for full syntax description): x : int<+32> = 0b001011; // yes, binary value! t : int<+1>; t = x[0]; x[0] = x[5]; x[5] = t; Assembly blocks アセンブリブロック When writing kernel code, you need assembly code blocks. The syntax provided by gcc is annoying, you have to correctly manage the string yourself (adding newline and so on.) カーネルのコードを記述するときにはアセンブリコードブロックが必要となります。 gcc が提供するアセンブリコードブロックのための構文は annoying で、 あなた自身が(アセンブリコードを表現している)文字列を正しく管理しなければなりません。 On the other hand, I don't want to add a full assembly parser (as in D compiler for example.) Despite the fact that it is boring and tedious, it implies that the language is stuck to some architectures and we have to rewrite the parser for each new architecture we need … といって、Dコンパイラーのように完全なアセンブリ言語のパーザーを追加したくはありません。 In the end, I found a way to integrate asm blocks without the noise of gcc but keeping it close enough to be able to translate it directly. Of course, this means that you still have to write clobber lists and stuff. A little example (using a typed macro function): #cas(val: volatile void**, cmp: volatile void*, exch: volatile void*) : void* { old: volatile void*; asm ("=a" (old); "r" (val), "a" (cmp), "r" (exch);) { lock cmpxchg %3, (%1) } return old; } Macro stuff マクロ Actually, C! has no dedicated preprocessing tools but we included some syntax to provide code that will be macro rather than functions or variables. First, you can transform any variable or function declaration into a kind of typed macro by simply adding a sharp in front of the name (see previous example). The generated code will be a traditional C macro with all the "dirty" code needed to manage return, call by value and so on. The other nice syntax extension is macro classes: a macro class provides methods (in fact macro functions) on non object types. The idea is to define simple and recurring operations on a value without boxing it (next article will provide examples). Modules モジュール Another missing feature of C is a proper module mechanism. We provide a simple module infrastructure sharing a lot (but far simpler) with C++ namespaces. Basically, every C! file is a module and referring to symbols from that module requires the module name, like namespaces. Of course you can also open the module, that is making directly available (without namespace) every symbol of the module. もうひとつのCに欠けている機能が適切なモジュール機構です。 わたしたちは C++ の名前空間と多くを共有する(しかし格段にシンプルな) モジュール infurasturacture を提供します。 基本的にはすべてのC! ファイルはひとつのモジュールであり and referring to symbols from that module requires the module name, like namespaces. もちろｎモジュールをオープンすることも可能で、 そのモジュールにあるすべての(namespace 抜きの)シンボルを直接扱えます。 Namespaces provide a simple way to avoid name specialization: inside the module you can refer to it directly and outside you use the module name and thus no inter-module conflict could happen. 名前空間は name specialization を除去するためのシンプルな方法を提供します。 モジュールの内側のものは直接参照することができ、 モジュールの外側のものはジュール名を使うので 複数のモジュール間で名前の衝突が起きることはありません。 What's next In the next article of this series I will present you with C! syntax, the very basis of the object system and macro stuff. The compiler is still in a prototype state: all features described here are working, but some details are still a bit fuzzy and may need you to do some adjustments in the generated code. As of now, you can clone C! on its LSE git repository, take a look at the examples in the tests directory and begin writing your own code. Unfortunately, we don't have an automated build procedure yet, so you will have to do it step by step. © LSE 2012 — Main website — RSS Feed
■_ C!
名前についていろいろ
C! - new system oriented programming language : programming This name will be so easy to google for!I love C!Oh, the modern irony!Remember to name it after C, but with a special character at the end. C++,C--,C#,Cω,C♫, C₀ and C! are already taken, might I recommend "C-:"? It looks something like a smiley face.Cಠ_ಠ maybe?C💩How about C+- (C more or less).You mean C±.C∓ is a much better language
■_ safety-critical software
安全で重要なソフトウェアを作るには
Ada の名前があがりますねー
Which languages are used for safety-critical software? - Stack Overflow I'm researching the development of safety-critical software, and in particular what effects the choice of programming language has on such development. Please explain, in detail, which languages are commonly used, and why.Ada and SPARK (which is an Ada dialect with some hooks for static verification) are used in aerospace circles for building high reliability software such as avionics systems. There is something of an ecosystem of code verification tooling for these languages, although this technology also exists for more mainstream languages as well. Erlang was designed from the ground up for writing high-reliability telecommunications code. It is designed to facilitate separation of concerns for error recovery (i.e. the subsystem generating the error is different from the subsystem that handles the error). It can also be subjected to formal proofs although this capability hasn't really moved far out of research circles. Functional languages such as Haskell can be subjected to formal proofs by automated systems due to the declarative nature of the language. This allows code with side effects to be contained in monadic functions. For a formal correctness proof the rest of the code can be assumed to do nothing but what is specified. However, these languages are garbage collected and the garbage collection is transparent to the code, so it cannot be reasoned about in this manner. Garbage collected languages are not normally predictable enough for hard realtime applications, although there is a body of ongoing research in time bounded incremental garbage collectors. Eiffel and its descendants have built-in support for a technique called Design By Contract which provides a robust runtime mechanism for incorporating pre- and post- checks for invariants. While Eiffel never really caught on, developing high-reliability software tends to consist of writing checks and handlers for failure modes up-front before actually writing the functionality. Although C and C++ were not specifically designed for this type of application, they are widely used for embedded and safety-critical software for several reasons. The main properties of note are control over memory management (which allows you to avoid having to garbage collect, for example), simple, well debugged core run-time libraries and mature tool support. A lot of the embedded development tool chains in use today were first developed in the 1980s and 1990s when this was current technology and come from the Unix culture that was prevalent at that time, so these tools remain popular for this sort of work. While manual memory management code must be carefully checked to avoid errors, it allows a degree of control over application response times that is not available with languages that depend on garbage collection. The core run time libraries of C and C++ languages are relatively simple, mature and well understood, so they are amongst the most stable platforms available. Most if not all of the static analysis tools used for Ada also support C and C++, and there are many other such tools available for C. There are also several widely used C/C++ based tool chains; most tool chains used for Ada also come in versions that support C and/or C++. Formal Methods such as Axiomatic Semantics (PDF), Z Notation or Communicating Sequential Processes allow program logic to be mathematically verified, and are often used in the design of safety critical software where the application is simple enough to apply them (typically embedded control systems). For example, one of my former lecturers did a formal correctness proof of a signaling system for the German railway network. The main shortcoming of formal methods is their tendency to grow exponentially in complexity with respect to the underlying system being proved. This means that there is significant risk of errors in the proof, so they are practically limited to fairly simple applications. Formal methods are quite widely used for verifying hardware correctness as hardware bugs are very expensive to fix, particularly on mass-market products. Since the Pentium FDIV bug, formal methods have gained quite a lot of attention, and have been used to verify the correctness of the FPU on all Intel processors since the Pentium Pro. Many other languages have been used to develop highly reliable software. A lot of research has been done on the subject. One can reasonably argue that methodology is more important than the platform although there are principles like simplicity and selection and control of dependencies that might preclude the use of certain platforms. As various of the others have noted, certain O/S platforms have features to promote reliability and predictable behaviour, such as watchdog timers and guaranteed interrupt response times. Simplicity is also a strong driver of reliability, and many RT systems are deliberately kept very simple and compact. QNX (the only such O/S that I am familiar with, having once worked with a concrete batching system based on it) is very small, and will fit on a single floppy. For similar reasons, the people who make OpenBSD - which is known for its robust security and thorough code auditing - also go out of their way keep the system simple. EDIT: This posting has some links to good articles about safety critical software, in particular Here and Here. Props to S.Lott and Adam Davis for the source. The story of the THERAC-25 is a bit of a classic work in this field.For C++, the Joint Strike Fighter (F-35) C++ Coding Standard is a good read: http://www.research.att.com/~bs/JSF-AV-rules.pdf
長い回答だなあ
■_
reddit 編
What's The Best Language For Safety Critical Software? : programming I work in this field (specifically aerospace) and nearly always use the 'C' language (NOT C++) but we always use a restricted subset, MISRA Guidelines are often applied which should largly remove undefined behaviours and when done properly the tool qualification will involve understanding any erratas or weaknesses in your tools and further restrictions can be added to the coding standards. For instance if there is a problem using a shift operator with the specific compiler used then shift will be banned in the coding standards. I have only seen C and Ada used, I have heard of C++ being used and assembler is always used for some aspects. You can in theory use any language but with safety critical you will need someone to agree and sign off on your choice. In aerospace the cert authorities will most likely be reluctant to let you choose something interesting. Everyone likes things that have been done before, so C and Ada dominate.practically right now, probably still ada.When I was in aerospace (20 years of it) I worked on safety-critical systems. On the systems I worked on, we used C and (in some cases) a very highly restricted subset of C++. Ada, at that time, was another option but there were several reasons to avoid it: back then, the tool chain was buggy and inefficient, and its cross-platform support was uneven-- though I hear that it's much improved now. And, as one of the commenters in the linked article pointed out, the methodology matters more than the tools. I might add that, for any nontrivial application, proving correctness is impossible too. The complexity of your proof will always be massively greater than the complexity of your code. At best you can have "islands" of provable correctness of some components (e.g, the code but not the OS or the full suite of hardware). There are also engineering compromises. Some safety-critical code also has to have deterministic (hard) realtime performance. I worked on systems that required that certain pieces of processing never took longer than N milliseconds to complete. So this limits the opportunity to run garbage collection, and it also means that recursion has to be avoided, and lazy evaluation has to be looked at very hard as well. Generally speaking, sophisticated language features are unhelpful in this world unless a normal human being can still understand exactly what the compiler has done with any given segment of code. Hence the continuing use of C. Edit: I'm out of that game now, but I agree that some FP concepts are well-suited to safety-critical systems. But with the caveats I listed above. Some considerations are quite implementation-specific.
■_
- 超簡単に Ruby プログラムを exe にする新しい方式 (構想) - まめめも
- F#言語の基礎文法 － ＠IT
- Big Sky :: Go言語から mruby が操作できる go-mruby 書いた
- 【書評】サンデル教授が新著で問う市場主義の限界 - WSJ日本版 - jp.WSJ.com
- 引数の順番にこだわる話 - mizon dev
- “Buzzになる数字をn個挙げる”をScalaで - 裏紙
-
講談社、電子書籍の復刊リクエストを受付開始：ニュース：PC Online
復刊の対象は、過去に講談社から刊行されて現在入手困難な作品。海外翻訳作品、コミック、雑誌は対象外。
- パナソニック、「Let'snote J10」に仕様を強化した夏モデル | パソコン | マイナビニュース
- Programming Perl
-
In 1993 … | Richard WM Jones
I should be happy, but the sad part of this is Linux now needs gigabytes of RAM to run properly.
- Hexenkessel, Tumblr とか RSS Reader...
- 喜ばしくも寂しいお知らせ - もりぐち！！！！
-
Modegramming Style: データフローDSL考 (5) - アイデアメモ
この点も含めて、Monadicプログラミングの記述方式がデータフローDSLを構成するパイプラインの記述に直接使用できそうな感触を得ました。
- ガベッジコレクタ系言語は 本当に初心者にやさしいのか？ （クライアント） | レビログ
- Bertrand Meyer's technology blog ≫ Blog Archive ≫ Domain Theory: the forgotten step in program verification
![Interface (インターフェース) 増刊 組み込みシステム開発に役立つ理論と手法 2012年 05月号 [雑誌]](http://ecx.images-amazon.com/images/I/51hLfpk9ETL._SL160_.jpg)
![歴史群像 2012年 06月号 [雑誌]](http://ecx.images-amazon.com/images/I/5102htwJ8bL._SL160_.jpg)
