koika
CompCert
koika | CompCert | |
---|---|---|
2 | 40 | |
156 | 1,998 | |
1.9% | 0.5% | |
0.0 | 9.0 | |
29 days ago | 29 days ago | |
Rocq Prover | Rocq Prover | |
GNU Lesser General Public License v3.0 only | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
koika
-
Let's collect relatively new research programming languages in this thread
https://github.com/koka-lang/koka Algebraic effects and reference counting. https://github.com/mit-plv/koika hardware description DSL for coq
-
There's an ongoing effort to rewrite Principia Mathematica using Coq
There are ongoing research projects about that, you may want to have a look at Kôika (https://github.com/mit-plv/koika), Kami (https://github.com/mit-plv/kami), Lutsig (https://github.com/CakeML/hardware) and silveroak (https://github.com/project-oak/silveroak). Closer to HLS there is also Vericert (https://github.com/ymherklotz/vericert). There may be other research project I am unaware of, feel free to add them in a reply, I am interested in it.
CompCert
- The Illustrated Guide to a PhD
- CompCert: Formally verified compilers usable for critical embedded software
-
Breaking Bad: How Compilers Break Constant-Time~Implementations
Possibly (I don't know how volatile interact with registers allocation), but the thing is you don't just want this specific example to work, there are a lot of things you want to be able to really ensure, i.e., have rigorous proof of [1]. So maybe if the semantics is adequate and the compiler itself is formally proved like CompCert [2] you can rely on volatile, but that's a lot a assumptions.
[1] See for example the work we did in this paper: Formally Proved Security of Assembly Code Against Power Analysis: A Case Study on Balanced Logic https://eprint.iacr.org/2013/554
[2] https://compcert.org/
-
Translation of the Rust's core and alloc crates to Coq for formal verification
You can write programs in Coq and extract them in OCaml with the `Extraction' command: https://coq.inria.fr/doc/v8.19/refman/addendum/extraction.ht...
This is used by compcert: https://compcert.org/
-
Differ: Tool for testing and validating transformed programs
A big problem is that proving that transformations preserve semantics is very hard. Formal methods has huge potential and I believe it will be a big part of the future, but it hasn't become mainstream yet. Probably a big reason why is that right now it's simply not practical: the things you can prove are much more limited than the things you can do, and it's a lot less work to just create a large testsuite.
Example: CompCert (https://compcert.org/), a formally-verified compiler AKA formally-verified sequence of semantics-preserving transformations from C code to Assembly. It's a great accomplishment, but few people are actually compiling their code with CompCert. Because GCC and LLVM are much faster[1], and have been used so widely that >99.9% of code is going to be compiled correctly, especially code which isn't doing anything extremely weird.
But as articles like this show, no matter how large a testsuite there may always be bugs, tests will never provide the kind of guarantees formal verification does.
[1] From CompCert, "Performance of the generated code is decent but not outstanding: on PowerPC, about 90% of the performance of GCC version 4 at optimization level 1"
- So you think you know C?
-
Can the language of proof assistants be used for general purpose programming?
Also a C compiler (https://compcert.org/). I did exaggerate bit in saying that anything non-trivial is "nearly impossible".
However, both CompCert and sel4 took a few years to develop, whereas it would only take months if not weeks to make versions of both which aren't formally verified but heavily tested.
-
A Guide to Undefined Behavior in C and C++
From my experience, while many MCUs have settled for the big compilers (GCC and Clang), DSPs and some FPGAs (not Intel and Xilinx, those have lately settled for Clang and a combination of Clang and GCC respectively) use some pretty bespoke compilers (just running ./ --version is enough to verify this, if the compiler even offers that option). That's not necessarily bad, since many of them offer some really useful features, but error messages can be really cryptic in some cases. Also some industries require use of verified compilers, like CompCert[1], and in such cases GCC and Clang just don't cut it.
[1]: https://compcert.org/
-
Recently I am having too much friction with the borrow checker... Would you recommend I rewrite the compiler in another language, or keep trying to implement it in rust?
CompCert sends its regards
- Rosenpass – formally verified post-quantum WireGuard
What are some alternatives?
silveroak - Formal specification and verification of hardware, especially for security and privacy.
vericert - A formally verified high-level synthesis tool based on CompCert and written in Coq.
kami - A Platform for High-Level Parametric Hardware Specification and its Modular Verification
winix - A UNIX-style Operating System for the Waikato RISC Architecture Microprocessor (WRAMP)
datafun - Research on integrating datalog & lambda calculus via monotonicity types
seL4 - The seL4 microkernel