From 45183ec019f667d5333cdda334eebacbdd508bc1 Mon Sep 17 00:00:00 2001 From: ymherklotz Date: Sun, 19 Sep 2021 16:48:27 +0000 Subject: deploy: 79ac5829c25b966214b33e28198eaa279ffe7f15 --- 404.html | 2 +- blog/index.html | 4 + blog/index.xml | 1 + blog/page/1/index.html | 1 + ...954131fab2f5270d34b966e42f893b9227dc1d3f68f.css | 1 + ...155a3e6d06d0c41e4afe4d81564015c56799705b0ca.css | 1 - categories/index.html | 6 +- categories/index.xml | 2 +- coq-style-guide/index.html | 168 --------------------- docs/building/index.html | 8 +- docs/coq-style-guide/index.html | 168 +++++++++++++++++++++ docs/index.html | 8 +- docs/index.xml | 7 +- docs/unreleased/index.html | 24 +-- docs/using-vericert/index.html | 8 +- ...3f30a542976090c3f9807c531c3bc8fe3c2ac72f323b.js | 1 + ...3e553ec3a8536feb7ae73b0074ffe8c42afc5e73bc54.js | 1 - ...127df0d1e8aaf9fc6cac5de780c02ac61d54f95f6d9d.js | 11 -- ...965fa29a56c40c4f8892dff5bfae0b331df4b63bb70d.js | 11 ++ future/index.html | 30 ++-- index.html | 8 +- index.xml | 10 +- manifest.json | 4 +- sitemap.xml | 2 +- tags/index.html | 6 +- tags/index.xml | 2 +- 26 files changed, 255 insertions(+), 240 deletions(-) create mode 100644 blog/index.html create mode 100644 blog/index.xml create mode 100644 blog/page/1/index.html create mode 100644 book.min.92c1de61cce4ee29dff6c954131fab2f5270d34b966e42f893b9227dc1d3f68f.css delete mode 100644 book.min.b07e338e07a9a926c141d155a3e6d06d0c41e4afe4d81564015c56799705b0ca.css delete mode 100644 coq-style-guide/index.html create mode 100644 docs/coq-style-guide/index.html create mode 100644 en.search-data.min.0797930edc4d082d567e3f30a542976090c3f9807c531c3bc8fe3c2ac72f323b.js delete mode 100644 en.search-data.min.0c06afa37fbc905f9d2b3e553ec3a8536feb7ae73b0074ffe8c42afc5e73bc54.js delete mode 100644 en.search.min.54c55766af8da62210d3127df0d1e8aaf9fc6cac5de780c02ac61d54f95f6d9d.js create mode 100644 en.search.min.8744a59deef42a09f73b965fa29a56c40c4f8892dff5bfae0b331df4b63bb70d.js diff --git a/404.html b/404.html index 279d1a5..3878b7d 100644 --- a/404.html +++ b/404.html @@ -1 +1 @@ -404 Page not found |

404

Page Not Found

\ No newline at end of file +404 Page not found | Vericert

404

Page Not Found

Vericert

\ No newline at end of file diff --git a/blog/index.html b/blog/index.html new file mode 100644 index 0000000..507378e --- /dev/null +++ b/blog/index.html @@ -0,0 +1,4 @@ +Blog | Vericert +
+Blog +
\ No newline at end of file diff --git a/blog/index.xml b/blog/index.xml new file mode 100644 index 0000000..8303f31 --- /dev/null +++ b/blog/index.xml @@ -0,0 +1 @@ +Blog on Vericerthttps://vericert.ymhg.org/blog/Recent content in Blog on VericertHugo -- gohugo.ioen-uk© 2020-2021 Yann Herklotz \ No newline at end of file diff --git a/blog/page/1/index.html b/blog/page/1/index.html new file mode 100644 index 0000000..a1bd1c0 --- /dev/null +++ b/blog/page/1/index.html @@ -0,0 +1 @@ +https://vericert.ymhg.org/blog/ \ No newline at end of file diff --git a/book.min.92c1de61cce4ee29dff6c954131fab2f5270d34b966e42f893b9227dc1d3f68f.css b/book.min.92c1de61cce4ee29dff6c954131fab2f5270d34b966e42f893b9227dc1d3f68f.css new file mode 100644 index 0000000..2925353 --- /dev/null +++ b/book.min.92c1de61cce4ee29dff6c954131fab2f5270d34b966e42f893b9227dc1d3f68f.css @@ -0,0 +1 @@ +:root{--gray-100: #fff8e5;--gray-200: #f2e6c1;--gray-500: #e5dab7;--color-link: #33a083;--color-visited-link: #33a083;--body-background: #f7eed2;--body-font-color: #0b1326;--icon-filter: none;--hint-color-info: #6bf;--hint-color-warning: #fd6;--hint-color-danger: #f66}@media(prefers-color-scheme:dark){:root{--gray-100: rgba(255, 255, 255, 0.1);--gray-200: rgba(255, 255, 255, 0.2);--gray-500: rgba(255, 255, 255, 0.5);--color-link: #80e5ca;--color-visited-link: #80e5ca;--body-background: #363f54;--body-font-color: #fffbf2;--icon-filter: brightness(0) invert(1);--hint-color-info: #6bf;--hint-color-warning: #fd6;--hint-color-danger: #f66}}/*!normalize.css v8.0.1 | MIT License | github.com/necolas/normalize.css*/html{line-height:1.15;-webkit-text-size-adjust:100%}body{margin:0}main{display:block}h1{font-size:2em;margin:.67em 0}hr{box-sizing:content-box;height:0;overflow:visible}pre{font-family:monospace,monospace;font-size:1em}a{background-color:transparent}abbr[title]{border-bottom:none;text-decoration:underline;text-decoration:underline dotted}b,strong{font-weight:bolder}code,kbd,samp{font-family:monospace,monospace;font-size:1em}small{font-size:80%}sub,sup{font-size:75%;line-height:0;position:relative;vertical-align:baseline}sub{bottom:-.25em}sup{top:-.5em}img{border-style:none}button,input,optgroup,select,textarea{font-family:inherit;font-size:100%;line-height:1.15;margin:0}button,input{overflow:visible}button,select{text-transform:none}button,[type=button],[type=reset],[type=submit]{-webkit-appearance:button}button::-moz-focus-inner,[type=button]::-moz-focus-inner,[type=reset]::-moz-focus-inner,[type=submit]::-moz-focus-inner{border-style:none;padding:0}button:-moz-focusring,[type=button]:-moz-focusring,[type=reset]:-moz-focusring,[type=submit]:-moz-focusring{outline:1px dotted ButtonText}fieldset{padding:.35em .75em .625em}legend{box-sizing:border-box;color:inherit;display:table;max-width:100%;padding:0;white-space:normal}progress{vertical-align:baseline}textarea{overflow:auto}[type=checkbox],[type=radio]{box-sizing:border-box;padding:0}[type=number]::-webkit-inner-spin-button,[type=number]::-webkit-outer-spin-button{height:auto}[type=search]{-webkit-appearance:textfield;outline-offset:-2px}[type=search]::-webkit-search-decoration{-webkit-appearance:none}::-webkit-file-upload-button{-webkit-appearance:button;font:inherit}details{display:block}summary{display:list-item}template{display:none}[hidden]{display:none}.flex{display:flex}.flex-auto{flex:1 1 auto}.flex-even{flex:1 1}.flex-wrap{flex-wrap:wrap}.justify-start{justify-content:flex-start}.justify-end{justify-content:flex-end}.justify-center{justify-content:center}.justify-between{justify-content:space-between}.align-center{align-items:center}.mx-auto{margin:0 auto}.text-center{text-align:center}.text-left{text-align:left}.text-right{text-align:right}.hidden{display:none}input.toggle{height:0;width:0;overflow:hidden;opacity:0;position:absolute}.clearfix::after{content:"";display:table;clear:both}html{font-size:16px;scroll-behavior:smooth;touch-action:manipulation}body{min-width:20rem;color:var(--body-font-color);background:var(--body-background);letter-spacing:.33px;font-weight:400;text-rendering:optimizeLegibility;-webkit-font-smoothing:antialiased;-moz-osx-font-smoothing:grayscale;box-sizing:border-box}body *{box-sizing:inherit}h1,h2,h3,h4,h5{font-weight:400}a{text-decoration:none;color:var(--color-link)}img{vertical-align:baseline}:focus{outline-style:auto;outline-color:currentColor;outline-color:-webkit-focus-ring-color}aside nav ul{padding:0;margin:0;list-style:none}aside nav ul li{margin:1em 0;position:relative}aside nav ul a{display:block}aside nav ul a:hover{opacity:.5}aside nav ul ul{padding-inline-start:1rem}ul.pagination{display:flex;justify-content:center;list-style-type:none}ul.pagination .page-item a{padding:1rem}.container{max-width:80rem;margin:0 auto}.book-icon{filter:var(--icon-filter)}.book-brand{margin-top:0}.book-brand img{height:1.5em;width:auto;vertical-align:middle;margin-inline-end:.5rem}.book-menu{flex:0 0 16rem;font-size:.875rem}.book-menu nav{width:16rem;padding:1rem;background:var(--body-background);position:fixed;top:0;bottom:0;overflow-x:hidden;overflow-y:auto}.book-menu a,.book-menu label{color:inherit;cursor:pointer;word-wrap:break-word}.book-menu a.active{color:var(--color-link)}.book-menu input.toggle+label+ul{display:none}.book-menu input.toggle:checked+label+ul{display:block}.book-section-flat{margin-bottom:2rem}.book-section-flat:not(:first-child){margin-top:2rem}.book-section-flat>a,.book-section-flat>span,.book-section-flat>label{font-weight:bolder}.book-section-flat>ul{padding-inline-start:0}.book-page{min-width:20rem;flex-grow:1;padding:1rem}.book-post{margin-bottom:3rem}.book-header{display:none;margin-bottom:1rem}.book-header label{line-height:0}.book-search{position:relative;margin:1rem 0;border-bottom:1px solid transparent}.book-search input{width:100%;padding:.5rem;border:0;border-radius:.25rem;background:var(--gray-100);color:var(--body-font-color)}.book-search input:required+.book-search-spinner{display:block}.book-search .book-search-spinner{position:absolute;top:0;margin:.5rem;margin-inline-start:calc(100% - 1.5rem);width:1rem;height:1rem;border:1px solid transparent;border-top-color:var(--body-font-color);border-radius:50%;animation:spin 1s ease infinite}@keyframes spin{100%{transform:rotate(360deg)}}.book-search small{opacity:.5}.book-toc{flex:0 0 16rem;font-size:.75rem}.book-toc nav{width:16rem;padding:1rem;position:fixed;top:0;bottom:0;overflow-x:hidden;overflow-y:auto}.book-toc img{height:1em}.book-toc nav>ul>li:first-child{margin-top:0}.book-footer{padding-top:1rem;font-size:.875rem}.book-footer img{height:1em;margin-inline-end:.5rem}.book-comments{margin-top:1rem}.book-languages{position:relative;overflow:visible;padding:1rem;margin:-1rem}.book-languages ul{margin:0;padding:0;list-style:none}.book-languages ul li{white-space:nowrap;cursor:pointer}.book-languages:hover .book-languages-list,.book-languages:focus .book-languages-list,.book-languages:focus-within .book-languages-list{display:block}.book-languages .book-languages-list{display:none;position:absolute;bottom:100%;left:0;padding:.5rem 0;background:var(--body-background);box-shadow:0 0 .25rem rgba(0,0,0,.1)}.book-languages .book-languages-list li img{opacity:.25}.book-languages .book-languages-list li.active img,.book-languages .book-languages-list li:hover img{opacity:initial}.book-languages .book-languages-list a{color:inherit;padding:.5rem 1rem}.book-home{padding:1rem}aside nav,.book-page,.book-header aside,.markdown{transition:.2s ease-in-out;transition-property:transform,margin,opacity,visibility;will-change:transform,margin,opacity}@media screen and (max-width:56rem){#menu-control,#toc-control{display:inline}.book-menu{visibility:hidden;margin-inline-start:-16rem;font-size:16px;z-index:1}.book-toc{display:none}.book-header{display:block}#menu-control:focus~main label[for=menu-control]{outline-style:auto;outline-color:currentColor;outline-color:-webkit-focus-ring-color}#menu-control:checked~main .book-menu{visibility:initial}#menu-control:checked~main .book-menu nav{transform:translateX(16rem);box-shadow:0 0 .5rem rgba(0,0,0,.1)}#menu-control:checked~main .book-page{opacity:.25}#menu-control:checked~main .book-menu-overlay{display:block;position:absolute;top:0;bottom:0;left:0;right:0}#toc-control:focus~main label[for=toc-control]{outline-style:auto;outline-color:currentColor;outline-color:-webkit-focus-ring-color}#toc-control:checked~main .book-header aside{display:block}body[dir=rtl] #menu-control:checked+main .book-menu nav{transform:translateX(-16rem)}}@media screen and (min-width:80rem){.book-page,.book-menu nav,.book-toc nav{padding:2rem 1rem}}@font-face{font-family:hk grotesk;font-style:italic;font-weight:400;font-display:swap;src:local("HK Grotesk Italic"),local("HKGrotesk-Italic"),url(fonts/HKGrotesk-Italic.woff2)format("woff2")}@font-face{font-family:hk grotesk;font-style:normal;font-weight:400;font-display:swap;src:local("HK Grotesk"),local("HKGrotesk"),url(fonts/HKGrotesk-Regular.woff2)format("woff2")}@font-face{font-family:hk grotesk;font-style:normal;font-weight:700;font-display:swap;src:local("HK Grotesk Bold"),local("HKGrotesk-Bold"),url(fonts/HKGrotesk-Bold.woff2)format("woff2")}@font-face{font-family:iosevka fixed;font-style:normal;font-weight:400;font-display:swap;src:local("Iosevka Fixed Regular"),local("IosevkaFixed-Regular"),url(fonts/iosevka-fixed-regular.woff2)format("woff2")}body{font-family:hk grotesk,sans-serif}code{font-family:iosevka fixed,roboto mono monospace}@media print{.book-menu,.book-footer,.book-toc{display:none}.book-header,.book-header aside{display:block}main{display:block!important}}.markdown{line-height:1.6}.markdown>:first-child{margin-top:0}.markdown h1,.markdown h2,.markdown h3,.markdown h4,.markdown h5,.markdown h6{font-weight:400;line-height:1;margin-top:1.5em;margin-bottom:1rem}.markdown h1 a.anchor,.markdown h2 a.anchor,.markdown h3 a.anchor,.markdown h4 a.anchor,.markdown h5 a.anchor,.markdown h6 a.anchor{opacity:0;font-size:.75em;vertical-align:middle;text-decoration:none}.markdown h1:hover a.anchor,.markdown h1 a.anchor:focus,.markdown h2:hover a.anchor,.markdown h2 a.anchor:focus,.markdown h3:hover a.anchor,.markdown h3 a.anchor:focus,.markdown h4:hover a.anchor,.markdown h4 a.anchor:focus,.markdown h5:hover a.anchor,.markdown h5 a.anchor:focus,.markdown h6:hover a.anchor,.markdown h6 a.anchor:focus{opacity:initial}.markdown h4,.markdown h5,.markdown h6{font-weight:bolder}.markdown h5{font-size:.875em}.markdown h6{font-size:.75em}.markdown b,.markdown optgroup,.markdown strong{font-weight:bolder}.markdown a{text-decoration:none}.markdown a:hover{text-decoration:underline}.markdown a:visited{color:var(--color-visited-link)}.markdown img{max-width:100%}.markdown code{padding:0 .25rem;background:var(--gray-200);border-radius:.25rem;font-size:.875em}.markdown pre{padding:1rem;background:var(--gray-100);border-radius:.25rem;overflow-x:auto}.markdown pre code{padding:0;background:0 0}.markdown blockquote{margin:1rem 0;padding:.5rem 1rem .5rem .75rem;border-inline-start:.25rem solid var(--gray-200);border-radius:.25rem}.markdown blockquote :first-child{margin-top:0}.markdown blockquote :last-child{margin-bottom:0}.markdown table{overflow:auto;display:block;border-spacing:0;border-collapse:collapse;margin-top:1rem;margin-bottom:1rem}.markdown table tr th,.markdown table tr td{padding:.5rem 1rem;border:1px solid var(--gray-200)}.markdown table tr:nth-child(2n){background:var(--gray-100)}.markdown hr{height:1px;border:none;background:var(--gray-200)}.markdown ul,.markdown ol{padding-inline-start:2rem}.markdown dl dt{font-weight:bolder;margin-top:1rem}.markdown dl dd{margin-inline-start:1rem;margin-bottom:1rem}.markdown .highlight table tr td:nth-child(1) pre{margin:0;padding-inline-end:0}.markdown .highlight table tr td:nth-child(2) pre{margin:0;padding-inline-start:0}.markdown details{padding:1rem;border:1px solid var(--gray-200);border-radius:.25rem}.markdown details summary{line-height:1;padding:1rem;margin:-1rem;cursor:pointer}.markdown details[open] summary{margin-bottom:0}.markdown figure{margin:1rem 0}.markdown figure figcaption p{margin-top:0}.markdown-inner>:first-child{margin-top:0}.markdown-inner>:last-child{margin-bottom:0}.markdown .book-expand{margin-top:1rem;margin-bottom:1rem;border:1px solid var(--gray-200);border-radius:.25rem;overflow:hidden}.markdown .book-expand .book-expand-head{background:var(--gray-100);padding:.5rem 1rem;cursor:pointer}.markdown .book-expand .book-expand-content{display:none;padding:1rem}.markdown .book-expand input[type=checkbox]:checked+.book-expand-content{display:block}.markdown .book-tabs{margin-top:1rem;margin-bottom:1rem;border:1px solid var(--gray-200);border-radius:.25rem;overflow:hidden;display:flex;flex-wrap:wrap}.markdown .book-tabs label{display:inline-block;padding:.5rem 1rem;border-bottom:1px transparent;cursor:pointer}.markdown .book-tabs .book-tabs-content{order:999;width:100%;border-top:1px solid var(--gray-100);padding:1rem;display:none}.markdown .book-tabs input[type=radio]:checked+label{border-bottom:1px solid var(--color-link)}.markdown .book-tabs input[type=radio]:checked+label+.book-tabs-content{display:block}.markdown .book-tabs input[type=radio]:focus+label{outline-style:auto;outline-color:currentColor;outline-color:-webkit-focus-ring-color}.markdown .book-columns{margin-left:-1rem;margin-right:-1rem}.markdown .book-columns>div{margin:1rem 0;min-width:10rem;padding:0 1rem}.markdown a.book-btn{display:inline-block;font-size:.875rem;color:var(--color-link);line-height:2rem;padding:0 1rem;border:1px solid var(--color-link);border-radius:.25rem;cursor:pointer}.markdown a.book-btn:hover{text-decoration:none}.markdown .book-hint.info{border-color:#6bf;background-color:rgba(102,187,255,.1)}.markdown .book-hint.warning{border-color:#fd6;background-color:rgba(255,221,102,.1)}.markdown .book-hint.danger{border-color:#f66;background-color:rgba(255,102,102,.1)}@media(prefers-color-scheme:light){.chroma{background-color:#fff}.chroma .err{color:red;background-color:#faa}.chroma .lntd{vertical-align:top;padding:0;margin:0;border:0}.chroma .lntable{border-spacing:0;padding:0;margin:0;border:0;width:auto;overflow:auto;display:block}.chroma .hl{display:block;width:100%;background-color:#ffc}.chroma .lnt{margin-right:.4em;padding:0 .4em;color:#7f7f7f}.chroma .ln{margin-right:.4em;padding:0 .4em;color:#7f7f7f}.chroma .k{color:#289;font-weight:700}.chroma .kc{color:#289;font-weight:700}.chroma .kd{color:#289;font-weight:700}.chroma .kn{color:#289;font-weight:700}.chroma .kp{color:#08f;font-weight:700}.chroma .kr{color:#289;font-weight:700}.chroma .kt{color:#66f;font-weight:700}.chroma .na{color:#007}.chroma .nb{color:#072}.chroma .nc{color:#e9e;font-weight:700}.chroma .no{color:#23b2a1;font-weight:700}.chroma .nd{color:#555;font-weight:700}.chroma .ni{color:#800}.chroma .ne{color:red;font-weight:700}.chroma .nf{color:#23b2a1;font-weight:700}.chroma .nl{color:#970;font-weight:700}.chroma .nn{color:#0e84b5;font-weight:700}.chroma .nt{color:#070}.chroma .nv{color:#036}.chroma .vc{color:#ccf}.chroma .vg{color:#f84}.chroma .vi{color:#aaf}.chroma .s{background-color:#e0e0ff}.chroma .sa{background-color:#e0e0ff}.chroma .sb{background-color:#e0e0ff}.chroma .sc{color:#88f;background-color:#e0e0ff}.chroma .dl{background-color:#e0e0ff}.chroma .sd{color:#d42;background-color:#e0e0ff}.chroma .s2{background-color:#e0e0ff}.chroma .se{color:#666;background-color:#e0e0ff;font-weight:700}.chroma .sh{background-color:#e0e0ff}.chroma .si{background-color:#eee}.chroma .sx{color:#f88;background-color:#e0e0ff}.chroma .sr{color:#000;background-color:#e0e0ff}.chroma .s1{background-color:#e0e0ff}.chroma .ss{color:#fc8;background-color:#e0e0ff}.chroma .m{color:#60e;font-weight:700}.chroma .mb{color:#60e;font-weight:700}.chroma .mf{color:#60e;font-weight:700}.chroma .mh{color:#058;font-weight:700}.chroma .mi{color:#66f;font-weight:700}.chroma .il{color:#60e;font-weight:700}.chroma .mo{color:#40e;font-weight:700}.chroma .o{color:#333}.chroma .ow{color:#000;font-weight:700}.chroma .c{color:#666;font-style:italic}.chroma .ch{color:#666;font-style:italic}.chroma .cm{color:#666;font-style:italic}.chroma .c1{color:#666;font-style:italic}.chroma .cs{color:#c00;font-weight:700;font-style:italic}.chroma .cp{color:#579}.chroma .cpf{color:#579}.chroma .gd{color:#a00000}.chroma .ge{font-style:italic}.chroma .gr{color:red}.chroma .gh{color:navy;font-weight:700}.chroma .gi{color:#00a000}.chroma .go{color:#888}.chroma .gp{color:#c65d09;font-weight:700}.chroma .gs{font-weight:700}.chroma .gu{color:purple;font-weight:700}.chroma .gt{color:#04d}.chroma .gl{text-decoration:underline}.chroma .w{color:#bbb}#book-logo{background-image:url(/vericert-main.svg);height:5rem;background-repeat:no-repeat;background-size:cover}}@media(prefers-color-scheme:dark){.chroma{color:#fff;background-color:#111}.chroma .lntd{vertical-align:top;padding:0;margin:0;border:0}.chroma .lntable{border-spacing:0;padding:0;margin:0;border:0;width:auto;overflow:auto;display:block}.chroma .hl{display:block;width:100%;background-color:#ffc}.chroma .lnt{margin-right:.4em;padding:0 .4em;color:#7f7f7f}.chroma .ln{margin-right:.4em;padding:0 .4em;color:#7f7f7f}.chroma .k{color:#fb660a;font-weight:700}.chroma .kc{color:#fb660a;font-weight:700}.chroma .kd{color:#fb660a;font-weight:700}.chroma .kn{color:#fb660a;font-weight:700}.chroma .kp{color:#fb660a}.chroma .kr{color:#fb660a;font-weight:700}.chroma .kt{color:#cdcaa9;font-weight:700}.chroma .na{color:#ff0086;font-weight:700}.chroma .no{color:#0086d2}.chroma .nf{color:#ff0086;font-weight:700}.chroma .nt{color:#fb660a;font-weight:700}.chroma .nv{color:#fb660a}.chroma .s{color:#0086d2}.chroma .sa{color:#0086d2}.chroma .sb{color:#0086d2}.chroma .sc{color:#0086d2}.chroma .dl{color:#0086d2}.chroma .sd{color:#0086d2}.chroma .s2{color:#0086d2}.chroma .se{color:#0086d2}.chroma .sh{color:#0086d2}.chroma .si{color:#0086d2}.chroma .sx{color:#0086d2}.chroma .sr{color:#0086d2}.chroma .s1{color:#0086d2}.chroma .ss{color:#0086d2}.chroma .m{color:#0086f7;font-weight:700}.chroma .mb{color:#0086f7;font-weight:700}.chroma .mf{color:#0086f7;font-weight:700}.chroma .mh{color:#0086f7;font-weight:700}.chroma .mi{color:#0086f7;font-weight:700}.chroma .il{color:#0086f7;font-weight:700}.chroma .mo{color:#0086f7;font-weight:700}.chroma .c{color:#080;background-color:#0f140f;font-style:italic}.chroma .ch{color:#080;background-color:#0f140f;font-style:italic}.chroma .cm{color:#080;background-color:#0f140f;font-style:italic}.chroma .c1{color:#080;background-color:#0f140f;font-style:italic}.chroma .cs{color:#080;background-color:#0f140f;font-style:italic}.chroma .cp{color:#ff0007;background-color:#0f140f;font-weight:700;font-style:italic}.chroma .cpf{color:#ff0007;background-color:#0f140f;font-weight:700;font-style:italic}.chroma .gh{font-weight:700}.chroma .go{color:#444;background-color:#222}.chroma .gu{font-weight:700}.chroma .w{color:#888}#book-logo{background-image:url(/vericert-white.svg);height:5rem;background-repeat:no-repeat;background-size:cover}}.book-brand{padding-bottom:1rem}.book-brand p{line-height:1.3;text-align:center}.book-page{background:var(--gray-100);border-radius:20px;padding:3rem}.markdown pre{background-color:var(--body-background)}.markdown h1{font-size:3em}.book-categories-tag{padding-right:1em}.book-tags-tag{padding-right:1em}.markdown .book-by-line{margin-top:0;margin-bottom:.2em} \ No newline at end of file diff --git a/book.min.b07e338e07a9a926c141d155a3e6d06d0c41e4afe4d81564015c56799705b0ca.css b/book.min.b07e338e07a9a926c141d155a3e6d06d0c41e4afe4d81564015c56799705b0ca.css deleted file mode 100644 index d7b1391..0000000 --- a/book.min.b07e338e07a9a926c141d155a3e6d06d0c41e4afe4d81564015c56799705b0ca.css +++ /dev/null @@ -1 +0,0 @@ -:root{--gray-100: #fff8e5;--gray-200: #f2e6c1;--gray-500: #e5dab7;--color-link: #33a083;--color-visited-link: #8333a0;--body-background: #f7eed2;--body-font-color: #0b1326;--icon-filter: none;--hint-color-info: #6bf;--hint-color-warning: #fd6;--hint-color-danger: #f66}@media(prefers-color-scheme:dark){:root{--gray-100: rgba(255, 255, 255, 0.1);--gray-200: rgba(255, 255, 255, 0.2);--gray-500: rgba(255, 255, 255, 0.5);--color-link: #80e5ca;--color-visited-link: #c173dd;--body-background: #363f54;--body-font-color: #fffbf2;--icon-filter: brightness(0) invert(1);--hint-color-info: #6bf;--hint-color-warning: #fd6;--hint-color-danger: #f66}}/*!normalize.css v8.0.1 | MIT License | github.com/necolas/normalize.css*/html{line-height:1.15;-webkit-text-size-adjust:100%}body{margin:0}main{display:block}h1{font-size:2em;margin:.67em 0}hr{box-sizing:content-box;height:0;overflow:visible}pre{font-family:monospace,monospace;font-size:1em}a{background-color:transparent}abbr[title]{border-bottom:none;text-decoration:underline;text-decoration:underline dotted}b,strong{font-weight:bolder}code,kbd,samp{font-family:monospace,monospace;font-size:1em}small{font-size:80%}sub,sup{font-size:75%;line-height:0;position:relative;vertical-align:baseline}sub{bottom:-.25em}sup{top:-.5em}img{border-style:none}button,input,optgroup,select,textarea{font-family:inherit;font-size:100%;line-height:1.15;margin:0}button,input{overflow:visible}button,select{text-transform:none}button,[type=button],[type=reset],[type=submit]{-webkit-appearance:button}button::-moz-focus-inner,[type=button]::-moz-focus-inner,[type=reset]::-moz-focus-inner,[type=submit]::-moz-focus-inner{border-style:none;padding:0}button:-moz-focusring,[type=button]:-moz-focusring,[type=reset]:-moz-focusring,[type=submit]:-moz-focusring{outline:1px dotted ButtonText}fieldset{padding:.35em .75em .625em}legend{box-sizing:border-box;color:inherit;display:table;max-width:100%;padding:0;white-space:normal}progress{vertical-align:baseline}textarea{overflow:auto}[type=checkbox],[type=radio]{box-sizing:border-box;padding:0}[type=number]::-webkit-inner-spin-button,[type=number]::-webkit-outer-spin-button{height:auto}[type=search]{-webkit-appearance:textfield;outline-offset:-2px}[type=search]::-webkit-search-decoration{-webkit-appearance:none}::-webkit-file-upload-button{-webkit-appearance:button;font:inherit}details{display:block}summary{display:list-item}template{display:none}[hidden]{display:none}.flex{display:flex}.flex-auto{flex:1 1 auto}.flex-even{flex:1 1}.flex-wrap{flex-wrap:wrap}.justify-start{justify-content:flex-start}.justify-end{justify-content:flex-end}.justify-center{justify-content:center}.justify-between{justify-content:space-between}.align-center{align-items:center}.mx-auto{margin:0 auto}.text-center{text-align:center}.text-left{text-align:left}.text-right{text-align:right}.hidden{display:none}input.toggle{height:0;width:0;overflow:hidden;opacity:0;position:absolute}.clearfix::after{content:"";display:table;clear:both}html{font-size:16px;scroll-behavior:smooth;touch-action:manipulation}body{min-width:20rem;color:var(--body-font-color);background:var(--body-background);letter-spacing:.33px;font-weight:400;text-rendering:optimizeLegibility;-webkit-font-smoothing:antialiased;-moz-osx-font-smoothing:grayscale;box-sizing:border-box}body *{box-sizing:inherit}h1,h2,h3,h4,h5{font-weight:400}a{text-decoration:none;color:var(--color-link)}img{vertical-align:baseline}:focus{outline-style:auto;outline-color:currentColor;outline-color:-webkit-focus-ring-color}aside nav ul{padding:0;margin:0;list-style:none}aside nav ul li{margin:1em 0;position:relative}aside nav ul a{display:block}aside nav ul a:hover{opacity:.5}aside nav ul ul{padding-inline-start:1rem}ul.pagination{display:flex;justify-content:center;list-style-type:none}ul.pagination .page-item a{padding:1rem}.container{max-width:80rem;margin:0 auto}.book-icon{filter:var(--icon-filter)}.book-brand{margin-top:0}.book-brand img{height:1.5em;width:auto;vertical-align:middle;margin-inline-end:.5rem}.book-menu{flex:0 0 16rem;font-size:.875rem}.book-menu nav{width:16rem;padding:1rem;background:var(--body-background);position:fixed;top:0;bottom:0;overflow-x:hidden;overflow-y:auto}.book-menu a,.book-menu label{color:inherit;cursor:pointer;word-wrap:break-word}.book-menu a.active{color:var(--color-link)}.book-menu input.toggle+label+ul{display:none}.book-menu input.toggle:checked+label+ul{display:block}.book-section-flat{margin-bottom:2rem}.book-section-flat:not(:first-child){margin-top:2rem}.book-section-flat>a,.book-section-flat>span,.book-section-flat>label{font-weight:bolder}.book-section-flat>ul{padding-inline-start:0}.book-page{min-width:20rem;flex-grow:1;padding:1rem}.book-post{margin-bottom:3rem}.book-header{display:none;margin-bottom:1rem}.book-header label{line-height:0}.book-search{position:relative;margin:1rem 0;border-bottom:1px solid transparent}.book-search input{width:100%;padding:.5rem;border:0;border-radius:.25rem;background:var(--gray-100);color:var(--body-font-color)}.book-search input:required+.book-search-spinner{display:block}.book-search .book-search-spinner{position:absolute;top:0;margin:.5rem;margin-inline-start:calc(100% - 1.5rem);width:1rem;height:1rem;border:1px solid transparent;border-top-color:var(--body-font-color);border-radius:50%;animation:spin 1s ease infinite}@keyframes spin{100%{transform:rotate(360deg)}}.book-search small{opacity:.5}.book-toc{flex:0 0 16rem;font-size:.75rem}.book-toc nav{width:16rem;padding:1rem;position:fixed;top:0;bottom:0;overflow-x:hidden;overflow-y:auto}.book-toc img{height:1em}.book-toc nav>ul>li:first-child{margin-top:0}.book-footer{padding-top:1rem;font-size:.875rem}.book-footer img{height:1em;margin-inline-end:.5rem}.book-comments{margin-top:1rem}.book-languages{position:relative;overflow:visible;padding:1rem;margin:-1rem}.book-languages ul{margin:0;padding:0;list-style:none}.book-languages ul li{white-space:nowrap;cursor:pointer}.book-languages:hover .book-languages-list,.book-languages:focus .book-languages-list,.book-languages:focus-within .book-languages-list{display:block}.book-languages .book-languages-list{display:none;position:absolute;bottom:100%;left:0;padding:.5rem 0;background:var(--body-background);box-shadow:0 0 .25rem rgba(0,0,0,.1)}.book-languages .book-languages-list li img{opacity:.25}.book-languages .book-languages-list li.active img,.book-languages .book-languages-list li:hover img{opacity:initial}.book-languages .book-languages-list a{color:inherit;padding:.5rem 1rem}.book-home{padding:1rem}aside nav,.book-page,.book-header aside,.markdown{transition:.2s ease-in-out;transition-property:transform,margin,opacity,visibility;will-change:transform,margin,opacity}@media screen and (max-width:56rem){#menu-control,#toc-control{display:inline}.book-menu{visibility:hidden;margin-inline-start:-16rem;font-size:16px;z-index:1}.book-toc{display:none}.book-header{display:block}#menu-control:focus~main label[for=menu-control]{outline-style:auto;outline-color:currentColor;outline-color:-webkit-focus-ring-color}#menu-control:checked~main .book-menu{visibility:initial}#menu-control:checked~main .book-menu nav{transform:translateX(16rem);box-shadow:0 0 .5rem rgba(0,0,0,.1)}#menu-control:checked~main .book-page{opacity:.25}#menu-control:checked~main .book-menu-overlay{display:block;position:absolute;top:0;bottom:0;left:0;right:0}#toc-control:focus~main label[for=toc-control]{outline-style:auto;outline-color:currentColor;outline-color:-webkit-focus-ring-color}#toc-control:checked~main .book-header aside{display:block}body[dir=rtl] #menu-control:checked+main .book-menu nav{transform:translateX(-16rem)}}@media screen and (min-width:80rem){.book-page,.book-menu nav,.book-toc nav{padding:2rem 1rem}}@font-face{font-family:hk grotesk;font-style:italic;font-weight:400;font-display:swap;src:local("HK Grotesk Italic"),local("HKGrotesk-Italic"),url(fonts/HKGrotesk-Italic.woff2)format("woff2")}@font-face{font-family:hk grotesk;font-style:normal;font-weight:400;font-display:swap;src:local("HK Grotesk"),local("HKGrotesk"),url(fonts/HKGrotesk-Regular.woff2)format("woff2")}@font-face{font-family:hk grotesk;font-style:normal;font-weight:700;font-display:swap;src:local("HK Grotesk Bold"),local("HKGrotesk-Bold"),url(fonts/HKGrotesk-Bold.woff2)format("woff2")}@font-face{font-family:iosevka fixed;font-style:normal;font-weight:400;font-display:swap;src:local("Iosevka Fixed Regular"),local("IosevkaFixed-Regular"),url(fonts/iosevka-fixed-regular.woff2)format("woff2")}body{font-family:hk grotesk,sans-serif}code{font-family:iosevka fixed,roboto mono monospace}@media print{.book-menu,.book-footer,.book-toc{display:none}.book-header,.book-header aside{display:block}main{display:block!important}}.markdown{line-height:1.6}.markdown>:first-child{margin-top:0}.markdown h1,.markdown h2,.markdown h3,.markdown h4,.markdown h5,.markdown h6{font-weight:400;line-height:1;margin-top:1.5em;margin-bottom:1rem}.markdown h1 a.anchor,.markdown h2 a.anchor,.markdown h3 a.anchor,.markdown h4 a.anchor,.markdown h5 a.anchor,.markdown h6 a.anchor{opacity:0;font-size:.75em;vertical-align:middle;text-decoration:none}.markdown h1:hover a.anchor,.markdown h1 a.anchor:focus,.markdown h2:hover a.anchor,.markdown h2 a.anchor:focus,.markdown h3:hover a.anchor,.markdown h3 a.anchor:focus,.markdown h4:hover a.anchor,.markdown h4 a.anchor:focus,.markdown h5:hover a.anchor,.markdown h5 a.anchor:focus,.markdown h6:hover a.anchor,.markdown h6 a.anchor:focus{opacity:initial}.markdown h4,.markdown h5,.markdown h6{font-weight:bolder}.markdown h5{font-size:.875em}.markdown h6{font-size:.75em}.markdown b,.markdown optgroup,.markdown strong{font-weight:bolder}.markdown a{text-decoration:none}.markdown a:hover{text-decoration:underline}.markdown a:visited{color:var(--color-visited-link)}.markdown img{max-width:100%}.markdown code{padding:0 .25rem;background:var(--gray-200);border-radius:.25rem;font-size:.875em}.markdown pre{padding:1rem;background:var(--gray-100);border-radius:.25rem;overflow-x:auto}.markdown pre code{padding:0;background:0 0}.markdown blockquote{margin:1rem 0;padding:.5rem 1rem .5rem .75rem;border-inline-start:.25rem solid var(--gray-200);border-radius:.25rem}.markdown blockquote :first-child{margin-top:0}.markdown blockquote :last-child{margin-bottom:0}.markdown table{overflow:auto;display:block;border-spacing:0;border-collapse:collapse;margin-top:1rem;margin-bottom:1rem}.markdown table tr th,.markdown table tr td{padding:.5rem 1rem;border:1px solid var(--gray-200)}.markdown table tr:nth-child(2n){background:var(--gray-100)}.markdown hr{height:1px;border:none;background:var(--gray-200)}.markdown ul,.markdown ol{padding-inline-start:2rem}.markdown dl dt{font-weight:bolder;margin-top:1rem}.markdown dl dd{margin-inline-start:1rem;margin-bottom:1rem}.markdown .highlight table tr td:nth-child(1) pre{margin:0;padding-inline-end:0}.markdown .highlight table tr td:nth-child(2) pre{margin:0;padding-inline-start:0}.markdown details{padding:1rem;border:1px solid var(--gray-200);border-radius:.25rem}.markdown details summary{line-height:1;padding:1rem;margin:-1rem;cursor:pointer}.markdown details[open] summary{margin-bottom:0}.markdown figure{margin:1rem 0}.markdown figure figcaption p{margin-top:0}.markdown-inner>:first-child{margin-top:0}.markdown-inner>:last-child{margin-bottom:0}.markdown .book-expand{margin-top:1rem;margin-bottom:1rem;border:1px solid var(--gray-200);border-radius:.25rem;overflow:hidden}.markdown .book-expand .book-expand-head{background:var(--gray-100);padding:.5rem 1rem;cursor:pointer}.markdown .book-expand .book-expand-content{display:none;padding:1rem}.markdown .book-expand input[type=checkbox]:checked+.book-expand-content{display:block}.markdown .book-tabs{margin-top:1rem;margin-bottom:1rem;border:1px solid var(--gray-200);border-radius:.25rem;overflow:hidden;display:flex;flex-wrap:wrap}.markdown .book-tabs label{display:inline-block;padding:.5rem 1rem;border-bottom:1px transparent;cursor:pointer}.markdown .book-tabs .book-tabs-content{order:999;width:100%;border-top:1px solid var(--gray-100);padding:1rem;display:none}.markdown .book-tabs input[type=radio]:checked+label{border-bottom:1px solid var(--color-link)}.markdown .book-tabs input[type=radio]:checked+label+.book-tabs-content{display:block}.markdown .book-tabs input[type=radio]:focus+label{outline-style:auto;outline-color:currentColor;outline-color:-webkit-focus-ring-color}.markdown .book-columns{margin-left:-1rem;margin-right:-1rem}.markdown .book-columns>div{margin:1rem 0;min-width:10rem;padding:0 1rem}.markdown a.book-btn{display:inline-block;font-size:.875rem;color:var(--color-link);line-height:2rem;padding:0 1rem;border:1px solid var(--color-link);border-radius:.25rem;cursor:pointer}.markdown a.book-btn:hover{text-decoration:none}.markdown .book-hint.info{border-color:#6bf;background-color:rgba(102,187,255,.1)}.markdown .book-hint.warning{border-color:#fd6;background-color:rgba(255,221,102,.1)}.markdown .book-hint.danger{border-color:#f66;background-color:rgba(255,102,102,.1)}@media(prefers-color-scheme:light){.chroma{background-color:#fff}.chroma .err{color:red;background-color:#faa}.chroma .lntd{vertical-align:top;padding:0;margin:0;border:0}.chroma .lntable{border-spacing:0;padding:0;margin:0;border:0;width:auto;overflow:auto;display:block}.chroma .hl{display:block;width:100%;background-color:#ffc}.chroma .lnt{margin-right:.4em;padding:0 .4em;color:#7f7f7f}.chroma .ln{margin-right:.4em;padding:0 .4em;color:#7f7f7f}.chroma .k{color:#289;font-weight:700}.chroma .kc{color:#289;font-weight:700}.chroma .kd{color:#289;font-weight:700}.chroma .kn{color:#289;font-weight:700}.chroma .kp{color:#08f;font-weight:700}.chroma .kr{color:#289;font-weight:700}.chroma .kt{color:#66f;font-weight:700}.chroma .na{color:#007}.chroma .nb{color:#072}.chroma .nc{color:#e9e;font-weight:700}.chroma .no{color:#23b2a1;font-weight:700}.chroma .nd{color:#555;font-weight:700}.chroma .ni{color:#800}.chroma .ne{color:red;font-weight:700}.chroma .nf{color:#23b2a1;font-weight:700}.chroma .nl{color:#970;font-weight:700}.chroma .nn{color:#0e84b5;font-weight:700}.chroma .nt{color:#070}.chroma .nv{color:#036}.chroma .vc{color:#ccf}.chroma .vg{color:#f84}.chroma .vi{color:#aaf}.chroma .s{background-color:#e0e0ff}.chroma .sa{background-color:#e0e0ff}.chroma .sb{background-color:#e0e0ff}.chroma .sc{color:#88f;background-color:#e0e0ff}.chroma .dl{background-color:#e0e0ff}.chroma .sd{color:#d42;background-color:#e0e0ff}.chroma .s2{background-color:#e0e0ff}.chroma .se{color:#666;background-color:#e0e0ff;font-weight:700}.chroma .sh{background-color:#e0e0ff}.chroma .si{background-color:#eee}.chroma .sx{color:#f88;background-color:#e0e0ff}.chroma .sr{color:#000;background-color:#e0e0ff}.chroma .s1{background-color:#e0e0ff}.chroma .ss{color:#fc8;background-color:#e0e0ff}.chroma .m{color:#60e;font-weight:700}.chroma .mb{color:#60e;font-weight:700}.chroma .mf{color:#60e;font-weight:700}.chroma .mh{color:#058;font-weight:700}.chroma .mi{color:#66f;font-weight:700}.chroma .il{color:#60e;font-weight:700}.chroma .mo{color:#40e;font-weight:700}.chroma .o{color:#333}.chroma .ow{color:#000;font-weight:700}.chroma .c{color:#666;font-style:italic}.chroma .ch{color:#666;font-style:italic}.chroma .cm{color:#666;font-style:italic}.chroma .c1{color:#666;font-style:italic}.chroma .cs{color:#c00;font-weight:700;font-style:italic}.chroma .cp{color:#579}.chroma .cpf{color:#579}.chroma .gd{color:#a00000}.chroma .ge{font-style:italic}.chroma .gr{color:red}.chroma .gh{color:navy;font-weight:700}.chroma .gi{color:#00a000}.chroma .go{color:#888}.chroma .gp{color:#c65d09;font-weight:700}.chroma .gs{font-weight:700}.chroma .gu{color:purple;font-weight:700}.chroma .gt{color:#04d}.chroma .gl{text-decoration:underline}.chroma .w{color:#bbb}#book-logo{background-image:url(/vericert-main.svg);height:5rem;background-repeat:no-repeat;background-size:cover}}@media(prefers-color-scheme:dark){.chroma{color:#fff;background-color:#111}.chroma .lntd{vertical-align:top;padding:0;margin:0;border:0}.chroma .lntable{border-spacing:0;padding:0;margin:0;border:0;width:auto;overflow:auto;display:block}.chroma .hl{display:block;width:100%;background-color:#ffc}.chroma .lnt{margin-right:.4em;padding:0 .4em;color:#7f7f7f}.chroma .ln{margin-right:.4em;padding:0 .4em;color:#7f7f7f}.chroma .k{color:#fb660a;font-weight:700}.chroma .kc{color:#fb660a;font-weight:700}.chroma .kd{color:#fb660a;font-weight:700}.chroma .kn{color:#fb660a;font-weight:700}.chroma .kp{color:#fb660a}.chroma .kr{color:#fb660a;font-weight:700}.chroma .kt{color:#cdcaa9;font-weight:700}.chroma .na{color:#ff0086;font-weight:700}.chroma .no{color:#0086d2}.chroma .nf{color:#ff0086;font-weight:700}.chroma .nt{color:#fb660a;font-weight:700}.chroma .nv{color:#fb660a}.chroma .s{color:#0086d2}.chroma .sa{color:#0086d2}.chroma .sb{color:#0086d2}.chroma .sc{color:#0086d2}.chroma .dl{color:#0086d2}.chroma .sd{color:#0086d2}.chroma .s2{color:#0086d2}.chroma .se{color:#0086d2}.chroma .sh{color:#0086d2}.chroma .si{color:#0086d2}.chroma .sx{color:#0086d2}.chroma .sr{color:#0086d2}.chroma .s1{color:#0086d2}.chroma .ss{color:#0086d2}.chroma .m{color:#0086f7;font-weight:700}.chroma .mb{color:#0086f7;font-weight:700}.chroma .mf{color:#0086f7;font-weight:700}.chroma .mh{color:#0086f7;font-weight:700}.chroma .mi{color:#0086f7;font-weight:700}.chroma .il{color:#0086f7;font-weight:700}.chroma .mo{color:#0086f7;font-weight:700}.chroma .c{color:#080;background-color:#0f140f;font-style:italic}.chroma .ch{color:#080;background-color:#0f140f;font-style:italic}.chroma .cm{color:#080;background-color:#0f140f;font-style:italic}.chroma .c1{color:#080;background-color:#0f140f;font-style:italic}.chroma .cs{color:#080;background-color:#0f140f;font-style:italic}.chroma .cp{color:#ff0007;background-color:#0f140f;font-weight:700;font-style:italic}.chroma .cpf{color:#ff0007;background-color:#0f140f;font-weight:700;font-style:italic}.chroma .gh{font-weight:700}.chroma .go{color:#444;background-color:#222}.chroma .gu{font-weight:700}.chroma .w{color:#888}#book-logo{background-image:url(/vericert-white.svg);height:5rem;background-repeat:no-repeat;background-size:cover}}.book-brand{padding-bottom:1rem}.book-brand p{line-height:1.3;text-align:center}.book-page{background:var(--gray-100);border-radius:20px}.markdown pre{background-color:var(--body-background)} \ No newline at end of file diff --git a/categories/index.html b/categories/index.html index 6b28713..abcdece 100644 --- a/categories/index.html +++ b/categories/index.html @@ -1,4 +1,4 @@ -Categories | -
+Categories | Vericert +
Categories -

Categories

\ No newline at end of file +
\ No newline at end of file diff --git a/categories/index.xml b/categories/index.xml index 7b6c3cd..dacd9ff 100644 --- a/categories/index.xml +++ b/categories/index.xml @@ -1 +1 @@ -Categories onhttps://vericert.ymhg.org/categories/Recent content in Categories onHugo -- gohugo.ioen-us© 2020-2021 Yann Herklotz \ No newline at end of file +Categories on Vericerthttps://vericert.ymhg.org/categories/Recent content in Categories on VericertHugo -- gohugo.ioen-uk© 2020-2021 Yann Herklotz \ No newline at end of file diff --git a/coq-style-guide/index.html b/coq-style-guide/index.html deleted file mode 100644 index 820cf1f..0000000 --- a/coq-style-guide/index.html +++ /dev/null @@ -1,168 +0,0 @@ -Coq Style Guide | -
-Coq Style Guide -

Coq Style Guide

This style guide was taken from Silveroak, it outlines code style for Coq code in this -repository. There are certainly other valid strategies and opinions on Coq code style; this is laid -out purely in the name of consistency. For a visual example of the style, see the example at the -bottom of this file.

Code organization -#

  • Files should begin with a copyright/license banner, as shown in the example above.

Import statements -#

  • Require Import statements should all go at the top of the file, followed by file-wide Import -statements.

    • =Import=s often contain notations or typeclass instances that might override notations or -instances from another library, so it’s nice to highlight them separately.

  • One Require Import statement per line; it’s easier to scan that way.

  • Require Import statements should use “fully-qualified” names (e.g. =Require Import -Coq.ZArith.ZArith= instead of Require Import ZArith).

    • Use the Locate command to find the fully-qualified name!

  • Require Import’s should go in the following order:

    1. Standard library dependencies (start with Coq.)
    2. External dependencies (anything outside the current project)
    3. Same-project dependencies

  • Require Import’s with the same root library (the name before the first .) should be grouped -together. Within each root-library group, they should be in alphabetical order (so Coq.Lists.List -before Coq.ZArith.ZArith).

Notations and scopes -#

  • Any file-wide Local Open Scope’s should come immediately after the =Import=s (see example).

    • Always use Local Open Scope; just Open Scope will sneakily open the scope for those who import -your file.

  • Put notations in their own separate modules or files, so that those who import your file can -choose whether or not they want the notations.

    • Conflicting notations can cause a lot of headache, so it comes in very handy to leave this -flexibility!

Formatting -#

Line length -#

  • Maximum line length 80 characters.
    • Many Coq IDE setups divide the screen in half vertically and use only half to display source -code, so more than 80 characters can be genuinely hard to read on a laptop.

Whitespace and indentation -#

  • No trailing whitespace.

  • Spaces, not tabs.

  • Files should end with a newline.

    • Many editors do this automatically on save.

  • Colons may be either “English-spaced”, with no space before the colon and one space after (x: nat) -or “French-spaced”, with one space before and after (x : nat).

  • Default indentation is 2 spaces.

    • Keeping this small prevents complex proofs from being indented ridiculously far, and matches IDE -defaults.

  • Use 2-space indents if inserting a line break immediately after:

    • Proof.
    • fun <...> =>
    • forall <...>,
    • exists <....>,

  • The style for indenting arguments in function application depends on where you make a line -break. If you make the line break immediately after the function name, use a 2-space -indent. However, if you make it after one or more arguments, align the next line with the first -argument:

    (Z.pow
-   1 2)
-(Z.pow 1 2 3
-       4 5 6)
-

  • Inductive cases should not be indented. Example:

    Inductive Foo : Type :=
-| FooA : Foo
-| FooB : Foo
-.
-

  • match or lazymatch cases should line up with the “m” in match or “l” in lazymatch, as in the -following examples:

    match x with
-| 3 => true
-| _ => false
-end.
-
-lazymatch x with
-| 3 => idtac
-| _ => fail "Not equal to 3:" x
-end.
-
-repeat match goal with
-       | _ => progress subst
-       | _ => reflexivity
-       end.
-
-do 2 lazymatch goal with
-     | |- context [eq] => idtac
-     end.
-

Definitions and Fixpoints -#

  • It’s okay to leave the return type of Definition’s and Fixpoint’s implicit (e.g. Definition x := 5 -instead of Definition x : nat := 5) when the type is very simple or obvious (for instance, the -definition is in a file which deals exclusively with operations on Z).

Inductives -#

  • The . ending an Inductive can be either on the same line as the last case or on its own line -immediately below. That is, both of the following are acceptable:

    Inductive Foo : Type :=
-| FooA : Foo
-| FooB : Foo
-.
-Inductive Foo : Type :=
-| FooA : Foo
-| FooB : Foo.
-

Lemma/Theorem statements -#

  • Generally, use Theorem for the most important, top-level facts you prove and Lemma for everything -else.
  • Insert a line break after the colon in the lemma statement.
  • Insert a line break after the comma for forall or exist quantifiers.
  • Implication arrows (->) should share a line with the previous hypothesis, not the following one.
  • There is no need to make a line break after every ->; short preconditions may share a line.

Proofs and tactics -#

  • Use the Proof command (lined up vertically with Lemma or Theorem it corresponds to) to open a -proof, and indent the first line after it 2 spaces.

  • Very small proofs (where Proof. <tactics> Qed. is <= 80 characters) can go all in one line.

  • When ending a proof, align the ending statement (Qed, Admitted, etc.) with Proof.

  • Avoid referring to autogenerated names (e.g. =H0=, n0). It’s okay to let Coq generate these names, -but you should not explicitly refer to them in your proof. So intros; my_solver is fine, but -intros; apply H1; my_solver is not fine.

    • You can force a non-autogenerated name by either putting the variable before the colon in the -lemma statement (Lemma foo x : ... instead of Lemma foo : forall x, ...), or by passing -arguments to intros (e.g. =intros ? x= to name the second argument x)

  • This way, the proof won’t break when new hypotheses are added or autogenerated variable names -change.

  • Use curly braces {} for subgoals, instead of bullets.

  • Never write tactics with more than one subgoal focused. This can make the proof very confusing to -step through! If you have more than one subgoal, use curly braces.

  • Consider adding a comment after the opening curly brace that explains what case you’re in (see -example).

    • This is not necessary for small subgoals but can help show the major lines of reasoning in large -proofs.

  • If invoking a tactic that is expected to return multiple subgoals, use [ | ... | ] before the . to -explicitly specify how many subgoals you expect.

    • Examples: split; [ | ]. induction z; [ | | ].
    • This helps make code more maintainable, because it fails immediately if your tactic no longer -solves as many subgoals as expected (or unexpectedly solves more).

  • If invoking a string of tactics (composed by ;) that will break the goal into multiple subgoals -and then solve all but one, still use [ ] to enforce that all but one goal is solved.

    • Example: split; try lia; [ ].

  • Tactics that consist only of repeat-ing a procedure (e.g. repeat match, repeat first) should -factor out a single step of that procedure a separate tactic called <tactic name>_step, because -the single-step version is much easier to debug. For instance:

    Ltac crush_step :=
-  match goal with
-  | _ => progress subst
-  | _ => reflexivity
-  end.
-Ltac crush := repeat crush_step.
-

Naming -#

  • Helper proofs about standard library datatypes should go in a module that is named to match the -standard library module (see example).

    • This makes the helper proofs look like standard-library ones, which is helpful for categorizing -them if they’re genuinely at the standard-library level of abstraction.

  • Names of modules should start with capital letters.

  • Names of inductives and their constructors should start with capital letters.

  • Names of other definitions/lemmas should be snake case.

Example -#

A small standalone Coq file that exhibits many of the style points.

(*
- * Vericert: Verified high-level synthesis.
- * Copyright (C) 2021 Name <email@example.com>
- *
- * <License...>
- *)
-
-  Require Import Coq.Lists.List.
-  Require Import Coq.micromega.Lia.
-  Require Import Coq.ZArith.ZArith.
-  Import ListNotations.
-  Local Open Scope Z_scope.
-
-  (* Helper proofs about standard library integers (Z) go within [Module Z] so
-     that they match standard-library Z lemmas when used. *)
-  Module Z.
-    Lemma pow_3_r x : x ^ 3 = x * x * x.
-    Proof. lia. Qed. (* very short proofs can go all on one line *)
-
-    Lemma pow_4_r x : x ^ 4 = x * x * x * x.
-    Proof.
-      change 4 with (Z.succ (Z.succ (Z.succ (Z.succ 0)))).
-      repeat match goal with
-	     | _ => rewrite Z.pow_1_r
-	     | _ => rewrite Z.pow_succ_r by lia
-	     | |- context [x * (?a * ?b)] =>
-	       replace (x * (a * b)) with (a * b * x) by lia
-	     | _ => reflexivity
-	     end.
-    Qed.
-  End Z.
-  (* Now we can access the lemmas above as Z.pow_3_r and Z.pow_4_r, as if they
-     were in the ZArith library! *)
-
-  Definition bar (x y : Z) := x ^ (y + 1).
-
-  (* example with a painfully manual proof to show case formatting *)
-  Lemma bar_upper_bound :
-    forall x y a,
-      0 <= x <= a -> 0 <= y ->
-      0 <= bar x y <= a ^ (y + 1).
-  Proof.
-    (* avoid referencing autogenerated names by explicitly naming variables *)
-    intros x y a Hx Hy. revert y Hy x a Hx.
-    (* explicitly indicate # subgoals with [ | ... | ] if > 1 *)
-    cbv [bar]; refine (natlike_ind _ _ _); [ | ].
-    { (* y = 0 *)
-      intros; lia. }
-    { (* y = Z.succ _ *)
-      intros.
-      rewrite Z.add_succ_l, Z.pow_succ_r by lia.
-      split.
-      { (* 0 <= bar x y *)
-	apply Z.mul_nonneg_nonneg; [ lia | ].
-	apply Z.pow_nonneg; lia. }
-      { (* bar x y < a ^ y *)
-	rewrite Z.pow_succ_r by lia.
-	apply Z.mul_le_mono_nonneg; try lia;
-	  [ apply Z.pow_nonneg; lia | ].
-	(* For more flexible proofs, use match statements to find hypotheses
-	   rather than referring to them by autogenerated names like H0. In this
-	   case, we'll take any hypothesis that applies to and then solves the
-	   goal. *)
-	match goal with H : _ |- _ => apply H; solve [auto] end. } }
-  Qed.
-
-  (* Put notations in a separate module or file so that importers can
-     decide whether or not to use them. *)
-  Module BarNotations.
-    Infix "#" := bar (at level 40) : Z_scope.
-    Notation "x '##'" := (bar x x) (at level 40) : Z_scope.
-  End BarNotations.
-
\ No newline at end of file diff --git a/docs/building/index.html b/docs/building/index.html index 49dc52b..b8fb391 100644 --- a/docs/building/index.html +++ b/docs/building/index.html @@ -2,10 +2,10 @@ The project is written in Coq, a theorem prover, which is extracted to OCaml so that it can then be compiled and executed. The dependencies of this project are the following: Coq: theorem prover that is used to also program the HLS tool.">Building Vericert | -
+ Coq: theorem prover that is used to also program the HLS tool.">Building Vericert | Vericert +
Building Vericert -

Building Vericert

To build Vericert, the provided Makefile can be used. External dependencies are needed to build the +

Building Vericert

To build Vericert, the provided Makefile can be used. External dependencies are needed to build the project, which can be pulled in automatically with nix using the provided default.nix and shell.nix files.

The project is written in Coq, a theorem prover, which is extracted to OCaml so that it can then be compiled and executed. The dependencies of this project are the following:

  • Coq: theorem prover that is used to also program the HLS tool.
  • OCaml: the OCaml compiler to compile the extracted files.
  • dune: build tool for ocaml projects to gather all the ocaml files and compile them in the right @@ -29,4 +29,4 @@ following:

    Or by running the test suite using the following command:

    make test
-
\ No newline at end of file +

\ No newline at end of file diff --git a/docs/coq-style-guide/index.html b/docs/coq-style-guide/index.html new file mode 100644 index 0000000..001df50 --- /dev/null +++ b/docs/coq-style-guide/index.html @@ -0,0 +1,168 @@ +Coq Style Guide | Vericert +
+Coq Style Guide +

Coq Style Guide

This style guide was taken from Silveroak, it outlines code style for Coq code in this +repository. There are certainly other valid strategies and opinions on Coq code style; this is laid +out purely in the name of consistency. For a visual example of the style, see the example at the +bottom of this file.

Code organization +#

  • Files should begin with a copyright/license banner, as shown in the example above.

Import statements +#

  • Require Import statements should all go at the top of the file, followed by file-wide Import +statements.

    • =Import=s often contain notations or typeclass instances that might override notations or +instances from another library, so it’s nice to highlight them separately.

  • One Require Import statement per line; it’s easier to scan that way.

  • Require Import statements should use “fully-qualified” names (e.g. =Require Import +Coq.ZArith.ZArith= instead of Require Import ZArith).

    • Use the Locate command to find the fully-qualified name!

  • Require Import’s should go in the following order:

    1. Standard library dependencies (start with Coq.)
    2. External dependencies (anything outside the current project)
    3. Same-project dependencies

  • Require Import’s with the same root library (the name before the first .) should be grouped +together. Within each root-library group, they should be in alphabetical order (so Coq.Lists.List +before Coq.ZArith.ZArith).

Notations and scopes +#

  • Any file-wide Local Open Scope’s should come immediately after the =Import=s (see example).

    • Always use Local Open Scope; just Open Scope will sneakily open the scope for those who import +your file.

  • Put notations in their own separate modules or files, so that those who import your file can +choose whether or not they want the notations.

    • Conflicting notations can cause a lot of headache, so it comes in very handy to leave this +flexibility!

Formatting +#

Line length +#

  • Maximum line length 80 characters.
    • Many Coq IDE setups divide the screen in half vertically and use only half to display source +code, so more than 80 characters can be genuinely hard to read on a laptop.

Whitespace and indentation +#

  • No trailing whitespace.

  • Spaces, not tabs.

  • Files should end with a newline.

    • Many editors do this automatically on save.

  • Colons may be either “English-spaced”, with no space before the colon and one space after (x: nat) +or “French-spaced”, with one space before and after (x : nat).

  • Default indentation is 2 spaces.

    • Keeping this small prevents complex proofs from being indented ridiculously far, and matches IDE +defaults.

  • Use 2-space indents if inserting a line break immediately after:

    • Proof.
    • fun <...> =>
    • forall <...>,
    • exists <....>,

  • The style for indenting arguments in function application depends on where you make a line +break. If you make the line break immediately after the function name, use a 2-space +indent. However, if you make it after one or more arguments, align the next line with the first +argument:

    (Z.pow
+   1 2)
+(Z.pow 1 2 3
+       4 5 6)
+

  • Inductive cases should not be indented. Example:

    Inductive Foo : Type :=
+| FooA : Foo
+| FooB : Foo
+.
+

  • match or lazymatch cases should line up with the “m” in match or “l” in lazymatch, as in the +following examples:

    match x with
+| 3 => true
+| _ => false
+end.
+
+lazymatch x with
+| 3 => idtac
+| _ => fail "Not equal to 3:" x
+end.
+
+repeat match goal with
+       | _ => progress subst
+       | _ => reflexivity
+       end.
+
+do 2 lazymatch goal with
+     | |- context [eq] => idtac
+     end.
+

Definitions and Fixpoints +#

  • It’s okay to leave the return type of Definition’s and Fixpoint’s implicit (e.g. Definition x := 5 +instead of Definition x : nat := 5) when the type is very simple or obvious (for instance, the +definition is in a file which deals exclusively with operations on Z).

Inductives +#

  • The . ending an Inductive can be either on the same line as the last case or on its own line +immediately below. That is, both of the following are acceptable:

    Inductive Foo : Type :=
+| FooA : Foo
+| FooB : Foo
+.
+Inductive Foo : Type :=
+| FooA : Foo
+| FooB : Foo.
+

Lemma/Theorem statements +#

  • Generally, use Theorem for the most important, top-level facts you prove and Lemma for everything +else.
  • Insert a line break after the colon in the lemma statement.
  • Insert a line break after the comma for forall or exist quantifiers.
  • Implication arrows (->) should share a line with the previous hypothesis, not the following one.
  • There is no need to make a line break after every ->; short preconditions may share a line.

Proofs and tactics +#

  • Use the Proof command (lined up vertically with Lemma or Theorem it corresponds to) to open a +proof, and indent the first line after it 2 spaces.

  • Very small proofs (where Proof. <tactics> Qed. is <= 80 characters) can go all in one line.

  • When ending a proof, align the ending statement (Qed, Admitted, etc.) with Proof.

  • Avoid referring to autogenerated names (e.g. =H0=, n0). It’s okay to let Coq generate these names, +but you should not explicitly refer to them in your proof. So intros; my_solver is fine, but +intros; apply H1; my_solver is not fine.

    • You can force a non-autogenerated name by either putting the variable before the colon in the +lemma statement (Lemma foo x : ... instead of Lemma foo : forall x, ...), or by passing +arguments to intros (e.g. =intros ? x= to name the second argument x)

  • This way, the proof won’t break when new hypotheses are added or autogenerated variable names +change.

  • Use curly braces {} for subgoals, instead of bullets.

  • Never write tactics with more than one subgoal focused. This can make the proof very confusing to +step through! If you have more than one subgoal, use curly braces.

  • Consider adding a comment after the opening curly brace that explains what case you’re in (see +example).

    • This is not necessary for small subgoals but can help show the major lines of reasoning in large +proofs.

  • If invoking a tactic that is expected to return multiple subgoals, use [ | ... | ] before the . to +explicitly specify how many subgoals you expect.

    • Examples: split; [ | ]. induction z; [ | | ].
    • This helps make code more maintainable, because it fails immediately if your tactic no longer +solves as many subgoals as expected (or unexpectedly solves more).

  • If invoking a string of tactics (composed by ;) that will break the goal into multiple subgoals +and then solve all but one, still use [ ] to enforce that all but one goal is solved.

    • Example: split; try lia; [ ].

  • Tactics that consist only of repeat-ing a procedure (e.g. repeat match, repeat first) should +factor out a single step of that procedure a separate tactic called <tactic name>_step, because +the single-step version is much easier to debug. For instance:

    Ltac crush_step :=
+  match goal with
+  | _ => progress subst
+  | _ => reflexivity
+  end.
+Ltac crush := repeat crush_step.
+

Naming +#

  • Helper proofs about standard library datatypes should go in a module that is named to match the +standard library module (see example).

    • This makes the helper proofs look like standard-library ones, which is helpful for categorizing +them if they’re genuinely at the standard-library level of abstraction.

  • Names of modules should start with capital letters.

  • Names of inductives and their constructors should start with capital letters.

  • Names of other definitions/lemmas should be snake case.

Example +#

A small standalone Coq file that exhibits many of the style points.

(*
+ * Vericert: Verified high-level synthesis.
+ * Copyright (C) 2021 Name <email@example.com>
+ *
+ * <License...>
+ *)
+
+  Require Import Coq.Lists.List.
+  Require Import Coq.micromega.Lia.
+  Require Import Coq.ZArith.ZArith.
+  Import ListNotations.
+  Local Open Scope Z_scope.
+
+  (* Helper proofs about standard library integers (Z) go within [Module Z] so
+     that they match standard-library Z lemmas when used. *)
+  Module Z.
+    Lemma pow_3_r x : x ^ 3 = x * x * x.
+    Proof. lia. Qed. (* very short proofs can go all on one line *)
+
+    Lemma pow_4_r x : x ^ 4 = x * x * x * x.
+    Proof.
+      change 4 with (Z.succ (Z.succ (Z.succ (Z.succ 0)))).
+      repeat match goal with
+	     | _ => rewrite Z.pow_1_r
+	     | _ => rewrite Z.pow_succ_r by lia
+	     | |- context [x * (?a * ?b)] =>
+	       replace (x * (a * b)) with (a * b * x) by lia
+	     | _ => reflexivity
+	     end.
+    Qed.
+  End Z.
+  (* Now we can access the lemmas above as Z.pow_3_r and Z.pow_4_r, as if they
+     were in the ZArith library! *)
+
+  Definition bar (x y : Z) := x ^ (y + 1).
+
+  (* example with a painfully manual proof to show case formatting *)
+  Lemma bar_upper_bound :
+    forall x y a,
+      0 <= x <= a -> 0 <= y ->
+      0 <= bar x y <= a ^ (y + 1).
+  Proof.
+    (* avoid referencing autogenerated names by explicitly naming variables *)
+    intros x y a Hx Hy. revert y Hy x a Hx.
+    (* explicitly indicate # subgoals with [ | ... | ] if > 1 *)
+    cbv [bar]; refine (natlike_ind _ _ _); [ | ].
+    { (* y = 0 *)
+      intros; lia. }
+    { (* y = Z.succ _ *)
+      intros.
+      rewrite Z.add_succ_l, Z.pow_succ_r by lia.
+      split.
+      { (* 0 <= bar x y *)
+	apply Z.mul_nonneg_nonneg; [ lia | ].
+	apply Z.pow_nonneg; lia. }
+      { (* bar x y < a ^ y *)
+	rewrite Z.pow_succ_r by lia.
+	apply Z.mul_le_mono_nonneg; try lia;
+	  [ apply Z.pow_nonneg; lia | ].
+	(* For more flexible proofs, use match statements to find hypotheses
+	   rather than referring to them by autogenerated names like H0. In this
+	   case, we'll take any hypothesis that applies to and then solves the
+	   goal. *)
+	match goal with H : _ |- _ => apply H; solve [auto] end. } }
+  Qed.
+
+  (* Put notations in a separate module or file so that importers can
+     decide whether or not to use them. *)
+  Module BarNotations.
+    Infix "#" := bar (at level 40) : Z_scope.
+    Notation "x '##'" := (bar x x) (at level 40) : Z_scope.
+  End BarNotations.
+

\ No newline at end of file diff --git a/docs/index.html b/docs/index.html index 419df0b..9a75c28 100644 --- a/docs/index.html +++ b/docs/index.html @@ -1,10 +1,10 @@ Docs | -
+ The design shown in Figure 1 shows how Vericert leverages an existing verified C compiler called CompCert to perform this translation.">Docs | Vericert +
Docs -

Docs

Vericert translates C code into a hardware description language called Verilog, which can then be +

Vericert translates C code into a hardware description language called Verilog, which can then be synthesised into hardware, to be placed onto a field-programmable gate array (FPGA) or -application-specific integrated circuit (ASIC).

Figure 1: Current design of Vericert, where HTL is an intermediate language representing a finite state machine with data-path (FSMD) and Verilog is the target language.

Figure 1: Current design of Vericert, where HTL is an intermediate language representing a finite state machine with data-path (FSMD) and Verilog is the target language.

The design shown in Figure 1 shows how Vericert leverages an existing verified C compiler +application-specific integrated circuit (ASIC).

Figure 1: Current design of Vericert, where HTL is an intermediate language representing a finite state machine with data-path (FSMD) and Verilog is the target language.

Figure 1: Current design of Vericert, where HTL is an intermediate language representing a finite state machine with data-path (FSMD) and Verilog is the target language.

The design shown in Figure 1 shows how Vericert leverages an existing verified C compiler called CompCert to perform this translation.

\ No newline at end of file diff --git a/docs/index.xml b/docs/index.xml index 42dff8e..d2c9847 100644 --- a/docs/index.xml +++ b/docs/index.xml @@ -1,5 +1,6 @@ -Docs onhttps://vericert.ymhg.org/docs/Recent content in Docs onHugo -- gohugo.ioen-us© 2020-2021 Yann HerklotzBuilding Vericerthttps://vericert.ymhg.org/docs/building/Mon, 01 Jan 0001 00:00:00 +0000https://vericert.ymhg.org/docs/building/To build Vericert, the provided Makefile can be used. External dependencies are needed to build the project, which can be pulled in automatically with nix using the provided default.nix and shell.nix files. +Docs on Vericerthttps://vericert.ymhg.org/docs/Recent content in Docs on VericertHugo -- gohugo.ioen-uk© 2020-2021 Yann HerklotzBuilding Vericerthttps://vericert.ymhg.org/docs/building/Mon, 01 Jan 0001 00:00:00 +0000https://vericert.ymhg.org/docs/building/To build Vericert, the provided Makefile can be used. External dependencies are needed to build the project, which can be pulled in automatically with nix using the provided default.nix and shell.nix files. The project is written in Coq, a theorem prover, which is extracted to OCaml so that it can then be compiled and executed. The dependencies of this project are the following: -Coq: theorem prover that is used to also program the HLS tool.Unreleased Featureshttps://vericert.ymhg.org/docs/unreleased/Mon, 01 Jan 0001 00:00:00 +0000https://vericert.ymhg.org/docs/unreleased/The following are unreleased features in Vericert that are currently being worked on and have not been completely proven correct yet. Currently this includes features such as: -scheduling, if-conversion, loop pipelining, and functions. This page gives some preliminary information on how the features are implemented and how the proofs for the features are being done. Once these features are properly implemented, they will be added to the proper documentation.Using Vericerthttps://vericert.ymhg.org/docs/using-vericert/Mon, 01 Jan 0001 00:00:00 +0000https://vericert.ymhg.org/docs/using-vericert/Vericert can be used to translate a subset of C into Verilog. As a simple example, consider the following C file (main.c): +Coq: theorem prover that is used to also program the HLS tool.Coq Style Guidehttps://vericert.ymhg.org/docs/coq-style-guide/Mon, 01 Jan 0001 00:00:00 +0000https://vericert.ymhg.org/docs/coq-style-guide/This style guide was taken from Silveroak, it outlines code style for Coq code in this repository. There are certainly other valid strategies and opinions on Coq code style; this is laid out purely in the name of consistency. For a visual example of the style, see the example at the bottom of this file. +Code organization # Legal banner # Files should begin with a copyright/license banner, as shown in the example above.Unreleased Featureshttps://vericert.ymhg.org/docs/unreleased/Mon, 01 Jan 0001 00:00:00 +0000https://vericert.ymhg.org/docs/unreleased/The following are unreleased features in Vericert that are currently being worked on and have not been completely proven correct yet. Currently this includes features such as: +scheduling, operation chaining, if-conversion, and functions. This page gives some preliminary information on how the features are implemented and how the proofs for the features are being done. Once these features are properly implemented, they will be added to the proper documentation.Using Vericerthttps://vericert.ymhg.org/docs/using-vericert/Mon, 01 Jan 0001 00:00:00 +0000https://vericert.ymhg.org/docs/using-vericert/Vericert can be used to translate a subset of C into Verilog. As a simple example, consider the following C file (main.c): void matrix_multiply(int first[2][2], int second[2][2], int multiply[2][2]) { int sum = 0; for (int c = 0; c &lt; 2; c++) { for (int d = 0; d &lt; 2; d++) { for (int k = 0; k &lt; 2; k++) { sum = sum + first[c][k]*second[k][d]; } multiply[c][d] = sum; sum = 0; } } } int main() { int f[2][2] = {{1, 2}, {3, 4}}; int s[2][2] = {{5, 6}, {7, 8}}; int m[2][2] = {{0, 0}, {0, 0}}; matrix_multiply(f, s, m); return m[1][1]; } It can be compiled using the following command, assuming that vericert is somewhere on the path. \ No newline at end of file diff --git a/docs/unreleased/index.html b/docs/unreleased/index.html index c3ec67a..6e0b068 100644 --- a/docs/unreleased/index.html +++ b/docs/unreleased/index.html @@ -1,14 +1,18 @@ Unreleased Features | -
+ scheduling, operation chaining, if-conversion, and functions. This page gives some preliminary information on how the features are implemented and how the proofs for the features are being done. Once these features are properly implemented, they will be added to the proper documentation.">Unreleased Features | Vericert +
Unreleased Features -

Unreleased Features

The following are unreleased features in Vericert that are currently being worked on and have not -been completely proven correct yet. Currently this includes features such as:

This page gives some preliminary information on how the features are implemented and how the proofs +

Unreleased Features

The following are unreleased features in Vericert that are currently being worked on and have not +been completely proven correct yet. Currently this includes features such as:

This page gives some preliminary information on how the features are implemented and how the proofs for the features are being done. Once these features are properly implemented, they will be added to the proper documentation.

Scheduling -#

Scheduling is an optimisation which is used to run

Operation Chaining -#

Scheduling is an optimisation which is used to run

If-conversion -#

If-conversion

Loop pipelining -#

Loop pipelining

Functions -#

Functions.

\ No newline at end of file +#

Scheduling is an optimisation which is used to run various instructions in parallel that are +independent to each other.

Operation Chaining +#

Operation chaining is an optimisation that can be added on to scheduling and allows for the +sequential execution of instructions in a clock cycle, while executing other instructions in +parallel in the same clock cycle.

If-conversion +#

If-conversion is an optimisation which can turn code with simple control flow into a single block +(called a hyper-block), using predicated instructions.

Functions +#

Functions are currently only inlined in Vericert, however, we are working on a proper interface to +integrate function calls into the hardware.

\ No newline at end of file diff --git a/docs/using-vericert/index.html b/docs/using-vericert/index.html index c8b352d..137cf67 100644 --- a/docs/using-vericert/index.html +++ b/docs/using-vericert/index.html @@ -1,9 +1,9 @@ Using Vericert | -
+void matrix_multiply(int first[2][2], int second[2][2], int multiply[2][2]) { int sum = 0; for (int c = 0; c < 2; c++) { for (int d = 0; d < 2; d++) { for (int k = 0; k < 2; k++) { sum = sum + first[c][k]*second[k][d]; } multiply[c][d] = sum; sum = 0; } } } int main() { int f[2][2] = {{1, 2}, {3, 4}}; int s[2][2] = {{5, 6}, {7, 8}}; int m[2][2] = {{0, 0}, {0, 0}}; matrix_multiply(f, s, m); return m[1][1]; } It can be compiled using the following command, assuming that vericert is somewhere on the path.">Using Vericert | Vericert +
Using Vericert -

Using Vericert

Vericert can be used to translate a subset of C into Verilog. As a simple example, consider the +

Using Vericert

Vericert can be used to translate a subset of C into Verilog. As a simple example, consider the following C file (main.c):

void matrix_multiply(int first[2][2], int second[2][2], int multiply[2][2]) {
     int sum = 0;
     for (int c = 0; c < 2; c++) {
@@ -35,4 +35,4 @@ finished: 50
 $ ./main_c
 $ echo $?
 50
-
\ No newline at end of file +

\ No newline at end of file diff --git a/en.search-data.min.0797930edc4d082d567e3f30a542976090c3f9807c531c3bc8fe3c2ac72f323b.js b/en.search-data.min.0797930edc4d082d567e3f30a542976090c3f9807c531c3bc8fe3c2ac72f323b.js new file mode 100644 index 0000000..e63bd7b --- /dev/null +++ b/en.search-data.min.0797930edc4d082d567e3f30a542976090c3f9807c531c3bc8fe3c2ac72f323b.js @@ -0,0 +1 @@ +'use strict';(function(){const indexCfg={cache:true};indexCfg.doc={id:'id',field:['title','content'],store:['title','href','section'],};const index=FlexSearch.create('balance',indexCfg);window.bookSearchIndex=index;index.add({'id':0,'href':'/blog/','title':"Blog",'section':"Vericert",'content':"Blog posts\n"});index.add({'id':1,'href':'/docs/building/','title':"Building Vericert",'section':"Docs",'content':"To build Vericert, the provided Makefile can be used. External dependencies are needed to build the project, which can be pulled in automatically with nix using the provided default.nix and shell.nix files.\nThe project is written in Coq, a theorem prover, which is extracted to OCaml so that it can then be compiled and executed. The dependencies of this project are the following:\n Coq: theorem prover that is used to also program the HLS tool. OCaml: the OCaml compiler to compile the extracted files. dune: build tool for ocaml projects to gather all the ocaml files and compile them in the right order. menhir: parser generator for ocaml. findlib to find installed OCaml libraries. GCC: compiler to help build CompCert. These dependencies can be installed manually, or automatically through Nix.\nDownloading CompCert # CompCert is added as a submodule in the lib/CompCert directory. It is needed to run the build process below, as it is the one dependency that is not downloaded by nix, and has to be downloaded together with the repository. To clone CompCert together with this project, you can run:\ngit clone --recursive https://github.com/ymherklotz/vericert If the repository is already cloned, you can run the following command to make sure that CompCert is also downloaded:\ngit submodule update --init Setting up Nix # Nix is a package manager that can create an isolated environment so that the builds are reproducible. Once nix is installed, it can be used in the following way.\nTo open a shell which includes all the necessary dependencies, one can use:\nnix-shell which will open a shell that has all the dependencies loaded.\nMakefile build # If the dependencies were installed manually, or if one is in the nix-shell, the project can be built by running:\nmake -j8 and installed locally, or under the PREFIX location using:\nmake install Which will install the binary in ./bin/vericert by default. However, this can be changed by changing the PREFIX environment variable, in which case the binary will be installed in $PREFIX/bin/vericert.\nTesting # To test out vericert you can try the following examples which are in the test folder using the following:\n./bin/vericert test/loop.c -o loop.v ./bin/vericert test/conditional.c -o conditional.v ./bin/vericert test/add.c -o add.v Or by running the test suite using the following command:\nmake test "});index.add({'id':2,'href':'/docs/coq-style-guide/','title':"Coq Style Guide",'section':"Docs",'content':"This style guide was taken from Silveroak, it outlines code style for Coq code in this repository. There are certainly other valid strategies and opinions on Coq code style; this is laid out purely in the name of consistency. For a visual example of the style, see the example at the bottom of this file.\nCode organization # Legal banner # Files should begin with a copyright/license banner, as shown in the example above. Import statements # Require Import statements should all go at the top of the file, followed by file-wide Import statements.\n =Import=s often contain notations or typeclass instances that might override notations or instances from another library, so it\u0026rsquo;s nice to highlight them separately. One Require Import statement per line; it\u0026rsquo;s easier to scan that way.\n Require Import statements should use \u0026ldquo;fully-qualified\u0026rdquo; names (e.g. =Require Import Coq.ZArith.ZArith= instead of Require Import ZArith).\n Use the Locate command to find the fully-qualified name! Require Import\u0026rsquo;s should go in the following order:\n Standard library dependencies (start with Coq.) External dependencies (anything outside the current project) Same-project dependencies Require Import\u0026rsquo;s with the same root library (the name before the first .) should be grouped together. Within each root-library group, they should be in alphabetical order (so Coq.Lists.List before Coq.ZArith.ZArith).\n Notations and scopes # Any file-wide Local Open Scope\u0026rsquo;s should come immediately after the =Import=s (see example).\n Always use Local Open Scope; just Open Scope will sneakily open the scope for those who import your file. Put notations in their own separate modules or files, so that those who import your file can choose whether or not they want the notations.\n Conflicting notations can cause a lot of headache, so it comes in very handy to leave this flexibility! Formatting # Line length # Maximum line length 80 characters. Many Coq IDE setups divide the screen in half vertically and use only half to display source code, so more than 80 characters can be genuinely hard to read on a laptop. Whitespace and indentation # No trailing whitespace.\n Spaces, not tabs.\n Files should end with a newline.\n Many editors do this automatically on save. Colons may be either \u0026ldquo;English-spaced\u0026rdquo;, with no space before the colon and one space after (x: nat) or \u0026ldquo;French-spaced\u0026rdquo;, with one space before and after (x : nat).\n Default indentation is 2 spaces.\n Keeping this small prevents complex proofs from being indented ridiculously far, and matches IDE defaults. Use 2-space indents if inserting a line break immediately after:\n Proof. fun \u0026lt;...\u0026gt; =\u0026gt; forall \u0026lt;...\u0026gt;, exists \u0026lt;....\u0026gt;, The style for indenting arguments in function application depends on where you make a line break. If you make the line break immediately after the function name, use a 2-space indent. However, if you make it after one or more arguments, align the next line with the first argument:\n(Z.pow 1 2) (Z.pow 1 2 3 4 5 6) Inductive cases should not be indented. Example:\nInductive Foo : Type := | FooA : Foo | FooB : Foo . match or lazymatch cases should line up with the \u0026ldquo;m\u0026rdquo; in match or \u0026ldquo;l\u0026rdquo; in lazymatch, as in the following examples:\nmatch x with | 3 =\u0026gt; true | _ =\u0026gt; false end. lazymatch x with | 3 =\u0026gt; idtac | _ =\u0026gt; fail \u0026#34;Not equal to 3:\u0026#34; x end. repeat match goal with | _ =\u0026gt; progress subst | _ =\u0026gt; reflexivity end. do 2 lazymatch goal with | |- context [eq] =\u0026gt; idtac end. Definitions and Fixpoints # It\u0026rsquo;s okay to leave the return type of Definition\u0026rsquo;s and Fixpoint\u0026rsquo;s implicit (e.g. Definition x := 5 instead of Definition x : nat := 5) when the type is very simple or obvious (for instance, the definition is in a file which deals exclusively with operations on Z). Inductives # The . ending an Inductive can be either on the same line as the last case or on its own line immediately below. That is, both of the following are acceptable:\nInductive Foo : Type := | FooA : Foo | FooB : Foo . Inductive Foo : Type := | FooA : Foo | FooB : Foo. Lemma/Theorem statements # Generally, use Theorem for the most important, top-level facts you prove and Lemma for everything else. Insert a line break after the colon in the lemma statement. Insert a line break after the comma for forall or exist quantifiers. Implication arrows (-\u0026gt;) should share a line with the previous hypothesis, not the following one. There is no need to make a line break after every -\u0026gt;; short preconditions may share a line. Proofs and tactics # Use the Proof command (lined up vertically with Lemma or Theorem it corresponds to) to open a proof, and indent the first line after it 2 spaces.\n Very small proofs (where Proof. \u0026lt;tactics\u0026gt; Qed. is \u0026lt;= 80 characters) can go all in one line.\n When ending a proof, align the ending statement (Qed, Admitted, etc.) with Proof.\n Avoid referring to autogenerated names (e.g. =H0=, n0). It\u0026rsquo;s okay to let Coq generate these names, but you should not explicitly refer to them in your proof. So intros; my_solver is fine, but intros; apply H1; my_solver is not fine.\n You can force a non-autogenerated name by either putting the variable before the colon in the lemma statement (Lemma foo x : ... instead of Lemma foo : forall x, ...), or by passing arguments to intros (e.g. =intros ? x= to name the second argument x) This way, the proof won\u0026rsquo;t break when new hypotheses are added or autogenerated variable names change.\n Use curly braces {} for subgoals, instead of bullets.\n Never write tactics with more than one subgoal focused. This can make the proof very confusing to step through! If you have more than one subgoal, use curly braces.\n Consider adding a comment after the opening curly brace that explains what case you\u0026rsquo;re in (see example).\n This is not necessary for small subgoals but can help show the major lines of reasoning in large proofs. If invoking a tactic that is expected to return multiple subgoals, use [ | ... | ] before the . to explicitly specify how many subgoals you expect.\n Examples: split; [ | ]. induction z; [ | | ]. This helps make code more maintainable, because it fails immediately if your tactic no longer solves as many subgoals as expected (or unexpectedly solves more). If invoking a string of tactics (composed by ;) that will break the goal into multiple subgoals and then solve all but one, still use [ ] to enforce that all but one goal is solved.\n Example: split; try lia; [ ]. Tactics that consist only of repeat-ing a procedure (e.g. repeat match, repeat first) should factor out a single step of that procedure a separate tactic called \u0026lt;tactic name\u0026gt;_step, because the single-step version is much easier to debug. For instance:\nLtac crush_step := match goal with | _ =\u0026gt; progress subst | _ =\u0026gt; reflexivity end. Ltac crush := repeat crush_step. Naming # Helper proofs about standard library datatypes should go in a module that is named to match the standard library module (see example).\n This makes the helper proofs look like standard-library ones, which is helpful for categorizing them if they\u0026rsquo;re genuinely at the standard-library level of abstraction. Names of modules should start with capital letters.\n Names of inductives and their constructors should start with capital letters.\n Names of other definitions/lemmas should be snake case.\n Example # A small standalone Coq file that exhibits many of the style points.\n(* * Vericert: Verified high-level synthesis. * Copyright (C) 2021 Name \u0026lt;email@example.com\u0026gt; * * \u0026lt;License...\u0026gt; *) Require Import Coq.Lists.List. Require Import Coq.micromega.Lia. Require Import Coq.ZArith.ZArith. Import ListNotations. Local Open Scope Z_scope. (* Helper proofs about standard library integers (Z) go within [Module Z] so that they match standard-library Z lemmas when used. *) Module Z. Lemma pow_3_r x : x ^ 3 = x * x * x. Proof. lia. Qed. (* very short proofs can go all on one line *) Lemma pow_4_r x : x ^ 4 = x * x * x * x. Proof. change 4 with (Z.succ (Z.succ (Z.succ (Z.succ 0)))). repeat match goal with | _ =\u0026gt; rewrite Z.pow_1_r | _ =\u0026gt; rewrite Z.pow_succ_r by lia | |- context [x * (?a * ?b)] =\u0026gt; replace (x * (a * b)) with (a * b * x) by lia | _ =\u0026gt; reflexivity end. Qed. End Z. (* Now we can access the lemmas above as Z.pow_3_r and Z.pow_4_r, as if they were in the ZArith library! *) Definition bar (x y : Z) := x ^ (y + 1). (* example with a painfully manual proof to show case formatting *) Lemma bar_upper_bound : forall x y a, 0 \u0026lt;= x \u0026lt;= a -\u0026gt; 0 \u0026lt;= y -\u0026gt; 0 \u0026lt;= bar x y \u0026lt;= a ^ (y + 1). Proof. (* avoid referencing autogenerated names by explicitly naming variables *) intros x y a Hx Hy. revert y Hy x a Hx. (* explicitly indicate # subgoals with [ | ... | ] if \u0026gt; 1 *) cbv [bar]; refine (natlike_ind _ _ _); [ | ]. { (* y = 0 *) intros; lia. } { (* y = Z.succ _ *) intros. rewrite Z.add_succ_l, Z.pow_succ_r by lia. split. { (* 0 \u0026lt;= bar x y *) apply Z.mul_nonneg_nonneg; [ lia | ]. apply Z.pow_nonneg; lia. } { (* bar x y \u0026lt; a ^ y *) rewrite Z.pow_succ_r by lia. apply Z.mul_le_mono_nonneg; try lia; [ apply Z.pow_nonneg; lia | ]. (* For more flexible proofs, use match statements to find hypotheses rather than referring to them by autogenerated names like H0. In this case, we\u0026#39;ll take any hypothesis that applies to and then solves the goal. *) match goal with H : _ |- _ =\u0026gt; apply H; solve [auto] end. } } Qed. (* Put notations in a separate module or file so that importers can decide whether or not to use them. *) Module BarNotations. Infix \u0026#34;#\u0026#34; := bar (at level 40) : Z_scope. Notation \u0026#34;x \u0026#39;##\u0026#39;\u0026#34; := (bar x x) (at level 40) : Z_scope. End BarNotations. "});index.add({'id':3,'href':'/docs/','title':"Docs",'section':"Vericert",'content':"Vericert translates C code into a hardware description language called Verilog, which can then be synthesised into hardware, to be placed onto a field-programmable gate array (FPGA) or application-specific integrated circuit (ASIC).\n\n Figure 1: Current design of Vericert, where HTL is an intermediate language representing a finite state machine with data-path (FSMD) and Verilog is the target language.\n The design shown in Figure 1 shows how Vericert leverages an existing verified C compiler called CompCert to perform this translation.\n"});index.add({'id':4,'href':'/future/','title':"Future Work",'section':"Vericert",'content':"This section contains future work that should be added to Vericert to make it into a better high-level synthesis tool.\nThe next interesting optimisations that should be looked at are the following:\n globals, type support, memory partitioning, and loop pipelining. Globals # Globals are an important feature to add, as have to be handled carefully in HLS, because they have to be placed into memory, and are often used in HLS designs. Proper handling of globals would allow for a larger subset of programs to be compiled, even allowing for larger benchmarks to be used, such as CHStone.\nType Support # It would also be useful to have support for other datatypes in C, such as char or short, as using these small datatypes is also quite popular in HLS to make the final designs more efficient.\nMemory Partitioning # Memory partitioning is quite an advanced optimisation, which could be combined with the support for globals so as to make memory layouts on the FPGA more efficient and run various memory operations in parallel.\nLoop pipelining # Loop pipelining is an optimisation to schedule loops, instead of only scheduling the instructions inside of the loop. There are two versions of loop pipelining, software and hardware loop pipelining. The former is done purely on instructions, whereas the latter is performed in tandem with scheduling.\n"});index.add({'id':5,'href':'/docs/unreleased/','title':"Unreleased Features",'section':"Docs",'content':"The following are unreleased features in Vericert that are currently being worked on and have not been completely proven correct yet. Currently this includes features such as:\n scheduling, operation chaining, if-conversion, and functions. This page gives some preliminary information on how the features are implemented and how the proofs for the features are being done. Once these features are properly implemented, they will be added to the proper documentation.\nScheduling # Scheduling is an optimisation which is used to run various instructions in parallel that are independent to each other.\nOperation Chaining # Operation chaining is an optimisation that can be added on to scheduling and allows for the sequential execution of instructions in a clock cycle, while executing other instructions in parallel in the same clock cycle.\nIf-conversion # If-conversion is an optimisation which can turn code with simple control flow into a single block (called a hyper-block), using predicated instructions.\nFunctions # Functions are currently only inlined in Vericert, however, we are working on a proper interface to integrate function calls into the hardware.\n"});index.add({'id':6,'href':'/docs/using-vericert/','title':"Using Vericert",'section':"Docs",'content':"Vericert can be used to translate a subset of C into Verilog. As a simple example, consider the following C file (main.c):\nvoid matrix_multiply(int first[2][2], int second[2][2], int multiply[2][2]) { int sum = 0; for (int c = 0; c \u0026lt; 2; c++) { for (int d = 0; d \u0026lt; 2; d++) { for (int k = 0; k \u0026lt; 2; k++) { sum = sum + first[c][k]*second[k][d]; } multiply[c][d] = sum; sum = 0; } } } int main() { int f[2][2] = {{1, 2}, {3, 4}}; int s[2][2] = {{5, 6}, {7, 8}}; int m[2][2] = {{0, 0}, {0, 0}}; matrix_multiply(f, s, m); return m[1][1]; } It can be compiled using the following command, assuming that vericert is somewhere on the path.\nvericert main.c -o main.v The Verilog file contains a top-level test-bench, which can be given to any Verilog simulator to simulate the hardware, which should give the same result as executing the C code. Using Icarus Verilog as an example:\niverilog -o main_v main.v When executing, it should therefore print the following:\n$ ./main_v finished: 50 This gives the same result as executing the C in the following way:\n$ gcc -o main_c main.c $ ./main_c $ echo $? 50 "});})(); \ No newline at end of file diff --git a/en.search-data.min.0c06afa37fbc905f9d2b3e553ec3a8536feb7ae73b0074ffe8c42afc5e73bc54.js b/en.search-data.min.0c06afa37fbc905f9d2b3e553ec3a8536feb7ae73b0074ffe8c42afc5e73bc54.js deleted file mode 100644 index c993b56..0000000 --- a/en.search-data.min.0c06afa37fbc905f9d2b3e553ec3a8536feb7ae73b0074ffe8c42afc5e73bc54.js +++ /dev/null @@ -1 +0,0 @@ -'use strict';(function(){const indexCfg={cache:true};indexCfg.doc={id:'id',field:['title','content'],store:['title','href','section'],};const index=FlexSearch.create('balance',indexCfg);window.bookSearchIndex=index;index.add({'id':0,'href':'/docs/building/','title':"Building Vericert",'section':"Docs",'content':"To build Vericert, the provided Makefile can be used. External dependencies are needed to build the project, which can be pulled in automatically with nix using the provided default.nix and shell.nix files.\nThe project is written in Coq, a theorem prover, which is extracted to OCaml so that it can then be compiled and executed. The dependencies of this project are the following:\n Coq: theorem prover that is used to also program the HLS tool. OCaml: the OCaml compiler to compile the extracted files. dune: build tool for ocaml projects to gather all the ocaml files and compile them in the right order. menhir: parser generator for ocaml. findlib to find installed OCaml libraries. GCC: compiler to help build CompCert. These dependencies can be installed manually, or automatically through Nix.\nDownloading CompCert # CompCert is added as a submodule in the lib/CompCert directory. It is needed to run the build process below, as it is the one dependency that is not downloaded by nix, and has to be downloaded together with the repository. To clone CompCert together with this project, you can run:\ngit clone --recursive https://github.com/ymherklotz/vericert If the repository is already cloned, you can run the following command to make sure that CompCert is also downloaded:\ngit submodule update --init Setting up Nix # Nix is a package manager that can create an isolated environment so that the builds are reproducible. Once nix is installed, it can be used in the following way.\nTo open a shell which includes all the necessary dependencies, one can use:\nnix-shell which will open a shell that has all the dependencies loaded.\nMakefile build # If the dependencies were installed manually, or if one is in the nix-shell, the project can be built by running:\nmake -j8 and installed locally, or under the PREFIX location using:\nmake install Which will install the binary in ./bin/vericert by default. However, this can be changed by changing the PREFIX environment variable, in which case the binary will be installed in $PREFIX/bin/vericert.\nTesting # To test out vericert you can try the following examples which are in the test folder using the following:\n./bin/vericert test/loop.c -o loop.v ./bin/vericert test/conditional.c -o conditional.v ./bin/vericert test/add.c -o add.v Or by running the test suite using the following command:\nmake test "});index.add({'id':1,'href':'/coq-style-guide/','title':"Coq Style Guide",'section':"Vericert",'content':"This style guide was taken from Silveroak, it outlines code style for Coq code in this repository. There are certainly other valid strategies and opinions on Coq code style; this is laid out purely in the name of consistency. For a visual example of the style, see the example at the bottom of this file.\nCode organization # Legal banner # Files should begin with a copyright/license banner, as shown in the example above. Import statements # Require Import statements should all go at the top of the file, followed by file-wide Import statements.\n =Import=s often contain notations or typeclass instances that might override notations or instances from another library, so it\u0026rsquo;s nice to highlight them separately. One Require Import statement per line; it\u0026rsquo;s easier to scan that way.\n Require Import statements should use \u0026ldquo;fully-qualified\u0026rdquo; names (e.g. =Require Import Coq.ZArith.ZArith= instead of Require Import ZArith).\n Use the Locate command to find the fully-qualified name! Require Import\u0026rsquo;s should go in the following order:\n Standard library dependencies (start with Coq.) External dependencies (anything outside the current project) Same-project dependencies Require Import\u0026rsquo;s with the same root library (the name before the first .) should be grouped together. Within each root-library group, they should be in alphabetical order (so Coq.Lists.List before Coq.ZArith.ZArith).\n Notations and scopes # Any file-wide Local Open Scope\u0026rsquo;s should come immediately after the =Import=s (see example).\n Always use Local Open Scope; just Open Scope will sneakily open the scope for those who import your file. Put notations in their own separate modules or files, so that those who import your file can choose whether or not they want the notations.\n Conflicting notations can cause a lot of headache, so it comes in very handy to leave this flexibility! Formatting # Line length # Maximum line length 80 characters. Many Coq IDE setups divide the screen in half vertically and use only half to display source code, so more than 80 characters can be genuinely hard to read on a laptop. Whitespace and indentation # No trailing whitespace.\n Spaces, not tabs.\n Files should end with a newline.\n Many editors do this automatically on save. Colons may be either \u0026ldquo;English-spaced\u0026rdquo;, with no space before the colon and one space after (x: nat) or \u0026ldquo;French-spaced\u0026rdquo;, with one space before and after (x : nat).\n Default indentation is 2 spaces.\n Keeping this small prevents complex proofs from being indented ridiculously far, and matches IDE defaults. Use 2-space indents if inserting a line break immediately after:\n Proof. fun \u0026lt;...\u0026gt; =\u0026gt; forall \u0026lt;...\u0026gt;, exists \u0026lt;....\u0026gt;, The style for indenting arguments in function application depends on where you make a line break. If you make the line break immediately after the function name, use a 2-space indent. However, if you make it after one or more arguments, align the next line with the first argument:\n(Z.pow 1 2) (Z.pow 1 2 3 4 5 6) Inductive cases should not be indented. Example:\nInductive Foo : Type := | FooA : Foo | FooB : Foo . match or lazymatch cases should line up with the \u0026ldquo;m\u0026rdquo; in match or \u0026ldquo;l\u0026rdquo; in lazymatch, as in the following examples:\nmatch x with | 3 =\u0026gt; true | _ =\u0026gt; false end. lazymatch x with | 3 =\u0026gt; idtac | _ =\u0026gt; fail \u0026#34;Not equal to 3:\u0026#34; x end. repeat match goal with | _ =\u0026gt; progress subst | _ =\u0026gt; reflexivity end. do 2 lazymatch goal with | |- context [eq] =\u0026gt; idtac end. Definitions and Fixpoints # It\u0026rsquo;s okay to leave the return type of Definition\u0026rsquo;s and Fixpoint\u0026rsquo;s implicit (e.g. Definition x := 5 instead of Definition x : nat := 5) when the type is very simple or obvious (for instance, the definition is in a file which deals exclusively with operations on Z). Inductives # The . ending an Inductive can be either on the same line as the last case or on its own line immediately below. That is, both of the following are acceptable:\nInductive Foo : Type := | FooA : Foo | FooB : Foo . Inductive Foo : Type := | FooA : Foo | FooB : Foo. Lemma/Theorem statements # Generally, use Theorem for the most important, top-level facts you prove and Lemma for everything else. Insert a line break after the colon in the lemma statement. Insert a line break after the comma for forall or exist quantifiers. Implication arrows (-\u0026gt;) should share a line with the previous hypothesis, not the following one. There is no need to make a line break after every -\u0026gt;; short preconditions may share a line. Proofs and tactics # Use the Proof command (lined up vertically with Lemma or Theorem it corresponds to) to open a proof, and indent the first line after it 2 spaces.\n Very small proofs (where Proof. \u0026lt;tactics\u0026gt; Qed. is \u0026lt;= 80 characters) can go all in one line.\n When ending a proof, align the ending statement (Qed, Admitted, etc.) with Proof.\n Avoid referring to autogenerated names (e.g. =H0=, n0). It\u0026rsquo;s okay to let Coq generate these names, but you should not explicitly refer to them in your proof. So intros; my_solver is fine, but intros; apply H1; my_solver is not fine.\n You can force a non-autogenerated name by either putting the variable before the colon in the lemma statement (Lemma foo x : ... instead of Lemma foo : forall x, ...), or by passing arguments to intros (e.g. =intros ? x= to name the second argument x) This way, the proof won\u0026rsquo;t break when new hypotheses are added or autogenerated variable names change.\n Use curly braces {} for subgoals, instead of bullets.\n Never write tactics with more than one subgoal focused. This can make the proof very confusing to step through! If you have more than one subgoal, use curly braces.\n Consider adding a comment after the opening curly brace that explains what case you\u0026rsquo;re in (see example).\n This is not necessary for small subgoals but can help show the major lines of reasoning in large proofs. If invoking a tactic that is expected to return multiple subgoals, use [ | ... | ] before the . to explicitly specify how many subgoals you expect.\n Examples: split; [ | ]. induction z; [ | | ]. This helps make code more maintainable, because it fails immediately if your tactic no longer solves as many subgoals as expected (or unexpectedly solves more). If invoking a string of tactics (composed by ;) that will break the goal into multiple subgoals and then solve all but one, still use [ ] to enforce that all but one goal is solved.\n Example: split; try lia; [ ]. Tactics that consist only of repeat-ing a procedure (e.g. repeat match, repeat first) should factor out a single step of that procedure a separate tactic called \u0026lt;tactic name\u0026gt;_step, because the single-step version is much easier to debug. For instance:\nLtac crush_step := match goal with | _ =\u0026gt; progress subst | _ =\u0026gt; reflexivity end. Ltac crush := repeat crush_step. Naming # Helper proofs about standard library datatypes should go in a module that is named to match the standard library module (see example).\n This makes the helper proofs look like standard-library ones, which is helpful for categorizing them if they\u0026rsquo;re genuinely at the standard-library level of abstraction. Names of modules should start with capital letters.\n Names of inductives and their constructors should start with capital letters.\n Names of other definitions/lemmas should be snake case.\n Example # A small standalone Coq file that exhibits many of the style points.\n(* * Vericert: Verified high-level synthesis. * Copyright (C) 2021 Name \u0026lt;email@example.com\u0026gt; * * \u0026lt;License...\u0026gt; *) Require Import Coq.Lists.List. Require Import Coq.micromega.Lia. Require Import Coq.ZArith.ZArith. Import ListNotations. Local Open Scope Z_scope. (* Helper proofs about standard library integers (Z) go within [Module Z] so that they match standard-library Z lemmas when used. *) Module Z. Lemma pow_3_r x : x ^ 3 = x * x * x. Proof. lia. Qed. (* very short proofs can go all on one line *) Lemma pow_4_r x : x ^ 4 = x * x * x * x. Proof. change 4 with (Z.succ (Z.succ (Z.succ (Z.succ 0)))). repeat match goal with | _ =\u0026gt; rewrite Z.pow_1_r | _ =\u0026gt; rewrite Z.pow_succ_r by lia | |- context [x * (?a * ?b)] =\u0026gt; replace (x * (a * b)) with (a * b * x) by lia | _ =\u0026gt; reflexivity end. Qed. End Z. (* Now we can access the lemmas above as Z.pow_3_r and Z.pow_4_r, as if they were in the ZArith library! *) Definition bar (x y : Z) := x ^ (y + 1). (* example with a painfully manual proof to show case formatting *) Lemma bar_upper_bound : forall x y a, 0 \u0026lt;= x \u0026lt;= a -\u0026gt; 0 \u0026lt;= y -\u0026gt; 0 \u0026lt;= bar x y \u0026lt;= a ^ (y + 1). Proof. (* avoid referencing autogenerated names by explicitly naming variables *) intros x y a Hx Hy. revert y Hy x a Hx. (* explicitly indicate # subgoals with [ | ... | ] if \u0026gt; 1 *) cbv [bar]; refine (natlike_ind _ _ _); [ | ]. { (* y = 0 *) intros; lia. } { (* y = Z.succ _ *) intros. rewrite Z.add_succ_l, Z.pow_succ_r by lia. split. { (* 0 \u0026lt;= bar x y *) apply Z.mul_nonneg_nonneg; [ lia | ]. apply Z.pow_nonneg; lia. } { (* bar x y \u0026lt; a ^ y *) rewrite Z.pow_succ_r by lia. apply Z.mul_le_mono_nonneg; try lia; [ apply Z.pow_nonneg; lia | ]. (* For more flexible proofs, use match statements to find hypotheses rather than referring to them by autogenerated names like H0. In this case, we\u0026#39;ll take any hypothesis that applies to and then solves the goal. *) match goal with H : _ |- _ =\u0026gt; apply H; solve [auto] end. } } Qed. (* Put notations in a separate module or file so that importers can decide whether or not to use them. *) Module BarNotations. Infix \u0026#34;#\u0026#34; := bar (at level 40) : Z_scope. Notation \u0026#34;x \u0026#39;##\u0026#39;\u0026#34; := (bar x x) (at level 40) : Z_scope. End BarNotations. "});index.add({'id':2,'href':'/docs/','title':"Docs",'section':"Vericert",'content':"Vericert translates C code into a hardware description language called Verilog, which can then be synthesised into hardware, to be placed onto a field-programmable gate array (FPGA) or application-specific integrated circuit (ASIC).\n\n Figure 1: Current design of Vericert, where HTL is an intermediate language representing a finite state machine with data-path (FSMD) and Verilog is the target language.\n The design shown in Figure 1 shows how Vericert leverages an existing verified C compiler called CompCert to perform this translation.\n"});index.add({'id':3,'href':'/future/','title':"Future Work",'section':"Vericert",'content':"This section contains future work that should be added to Vericert to make it into a better high-level synthesis tool.\nThe next interesting optimisations that should be looked at are the following:\n Globals Type Support Memory Partitioning Operation Chaining Globals # globals\nType Support # type support\nMemory Partitioning # memory\n"});index.add({'id':4,'href':'/docs/unreleased/','title':"Unreleased Features",'section':"Docs",'content':"The following are unreleased features in Vericert that are currently being worked on and have not been completely proven correct yet. Currently this includes features such as:\n scheduling, if-conversion, loop pipelining, and functions. This page gives some preliminary information on how the features are implemented and how the proofs for the features are being done. Once these features are properly implemented, they will be added to the proper documentation.\nScheduling # Scheduling is an optimisation which is used to run\nOperation Chaining # Scheduling is an optimisation which is used to run\nIf-conversion # If-conversion\nLoop pipelining # Loop pipelining\nFunctions # Functions.\n"});index.add({'id':5,'href':'/docs/using-vericert/','title':"Using Vericert",'section':"Docs",'content':"Vericert can be used to translate a subset of C into Verilog. As a simple example, consider the following C file (main.c):\nvoid matrix_multiply(int first[2][2], int second[2][2], int multiply[2][2]) { int sum = 0; for (int c = 0; c \u0026lt; 2; c++) { for (int d = 0; d \u0026lt; 2; d++) { for (int k = 0; k \u0026lt; 2; k++) { sum = sum + first[c][k]*second[k][d]; } multiply[c][d] = sum; sum = 0; } } } int main() { int f[2][2] = {{1, 2}, {3, 4}}; int s[2][2] = {{5, 6}, {7, 8}}; int m[2][2] = {{0, 0}, {0, 0}}; matrix_multiply(f, s, m); return m[1][1]; } It can be compiled using the following command, assuming that vericert is somewhere on the path.\nvericert main.c -o main.v The Verilog file contains a top-level test-bench, which can be given to any Verilog simulator to simulate the hardware, which should give the same result as executing the C code. Using Icarus Verilog as an example:\niverilog -o main_v main.v When executing, it should therefore print the following:\n$ ./main_v finished: 50 This gives the same result as executing the C in the following way:\n$ gcc -o main_c main.c $ ./main_c $ echo $? 50 "});})(); \ No newline at end of file diff --git a/en.search.min.54c55766af8da62210d3127df0d1e8aaf9fc6cac5de780c02ac61d54f95f6d9d.js b/en.search.min.54c55766af8da62210d3127df0d1e8aaf9fc6cac5de780c02ac61d54f95f6d9d.js deleted file mode 100644 index 12562e4..0000000 --- a/en.search.min.54c55766af8da62210d3127df0d1e8aaf9fc6cac5de780c02ac61d54f95f6d9d.js +++ /dev/null @@ -1,11 +0,0 @@ -'use strict';(function(){const input=document.querySelector('#book-search-input');const results=document.querySelector('#book-search-results');if(!input){return} -input.addEventListener('focus',init);input.addEventListener('keyup',search);document.addEventListener('keypress',focusSearchFieldOnKeyPress);function focusSearchFieldOnKeyPress(event){if(input===document.activeElement){return;} -const characterPressed=String.fromCharCode(event.charCode);if(!isHotkey(characterPressed)){return;} -input.focus();event.preventDefault();} -function isHotkey(character){const dataHotkeys=input.getAttribute('data-hotkeys')||'';return dataHotkeys.indexOf(character)>=0;} -function init(){input.removeEventListener('focus',init);input.required=true;loadScript('/flexsearch.min.js');loadScript('/en.search-data.min.0c06afa37fbc905f9d2b3e553ec3a8536feb7ae73b0074ffe8c42afc5e73bc54.js',function(){input.required=false;search();});} -function search(){while(results.firstChild){results.removeChild(results.firstChild);} -if(!input.value){return;} -const searchHits=window.bookSearchIndex.search(input.value,10);searchHits.forEach(function(page){const li=element('
    • ');const a=li.querySelector('a'),small=li.querySelector('small');a.href=page.href;a.textContent=page.title;small.textContent=page.section;results.appendChild(li);});} -function loadScript(src,callback){const script=document.createElement('script');script.defer=true;script.async=false;script.src=src;script.onload=callback;document.head.appendChild(script);} -function element(content){const div=document.createElement('div');div.innerHTML=content;return div.firstChild;}})(); \ No newline at end of file diff --git a/en.search.min.8744a59deef42a09f73b965fa29a56c40c4f8892dff5bfae0b331df4b63bb70d.js b/en.search.min.8744a59deef42a09f73b965fa29a56c40c4f8892dff5bfae0b331df4b63bb70d.js new file mode 100644 index 0000000..ea4000c --- /dev/null +++ b/en.search.min.8744a59deef42a09f73b965fa29a56c40c4f8892dff5bfae0b331df4b63bb70d.js @@ -0,0 +1,11 @@ +'use strict';(function(){const input=document.querySelector('#book-search-input');const results=document.querySelector('#book-search-results');if(!input){return} +input.addEventListener('focus',init);input.addEventListener('keyup',search);document.addEventListener('keypress',focusSearchFieldOnKeyPress);function focusSearchFieldOnKeyPress(event){if(input===document.activeElement){return;} +const characterPressed=String.fromCharCode(event.charCode);if(!isHotkey(characterPressed)){return;} +input.focus();event.preventDefault();} +function isHotkey(character){const dataHotkeys=input.getAttribute('data-hotkeys')||'';return dataHotkeys.indexOf(character)>=0;} +function init(){input.removeEventListener('focus',init);input.required=true;loadScript('/flexsearch.min.js');loadScript('/en.search-data.min.0797930edc4d082d567e3f30a542976090c3f9807c531c3bc8fe3c2ac72f323b.js',function(){input.required=false;search();});} +function search(){while(results.firstChild){results.removeChild(results.firstChild);} +if(!input.value){return;} +const searchHits=window.bookSearchIndex.search(input.value,10);searchHits.forEach(function(page){const li=element('
    • ');const a=li.querySelector('a'),small=li.querySelector('small');a.href=page.href;a.textContent=page.title;small.textContent=page.section;results.appendChild(li);});} +function loadScript(src,callback){const script=document.createElement('script');script.defer=true;script.async=false;script.src=src;script.onload=callback;document.head.appendChild(script);} +function element(content){const div=document.createElement('div');div.innerHTML=content;return div.firstChild;}})(); \ No newline at end of file diff --git a/future/index.html b/future/index.html index f139fb4..06622e1 100644 --- a/future/index.html +++ b/future/index.html @@ -1,16 +1,22 @@ Future Work | -
    + globals, type support, memory partitioning, and loop pipelining. Globals # Globals are an important feature to add, as have to be handled carefully in HLS, because they have to be placed into memory, and are often used in HLS designs.">Future Work | Vericert +
    Future Work -

    Future Work

    This section contains future work that should be added to Vericert to make it into a better -high-level synthesis tool.

    The next interesting optimisations that should be looked at are the following:

    Globals -#

    globals

    Type Support -#

    type support

    Memory Partitioning -#

    memory

    \ No newline at end of file +

    Future Work

    This section contains future work that should be added to Vericert to make it into a better +high-level synthesis tool.

    The next interesting optimisations that should be looked at are the following:

    Globals +#

    Globals are an important feature to add, as have to be handled carefully in HLS, because they have +to be placed into memory, and are often used in HLS designs. Proper handling of globals would allow +for a larger subset of programs to be compiled, even allowing for larger benchmarks to be used, such +as CHStone.

    Type Support +#

    It would also be useful to have support for other datatypes in C, such as char or short, as using +these small datatypes is also quite popular in HLS to make the final designs more efficient.

    Memory Partitioning +#

    Memory partitioning is quite an advanced optimisation, which could be combined with the support for +globals so as to make memory layouts on the FPGA more efficient and run various memory operations in +parallel.

    Loop pipelining +#

    Loop pipelining is an optimisation to schedule loops, instead of only scheduling the instructions +inside of the loop. There are two versions of loop pipelining, software and hardware loop +pipelining. The former is done purely on instructions, whereas the latter is performed in tandem +with scheduling.

    \ No newline at end of file diff --git a/index.html b/index.html index 9cb397c..1c98f50 100644 --- a/index.html +++ b/index.html @@ -1,13 +1,13 @@ Vericert | -
    +Features # The project is currently a work in progress, so proofs remain to be finished. Currently, the following C features are supported, but are not all proven correct yet:">Vericert | Vericert +
    Vericert -

    Vericert

    A formally verified high-level synthesis (HLS) tool written in Coq, building on top of CompCert. +

    A formally verified high-level synthesis (HLS) tool written in Coq, building on top of CompCert. This ensures the correctness of the C to Verilog translation according to our Verilog semantics and CompCert’s C semantics, removing the need to check the resulting hardware for behavioural correctness.

    Features #

    The project is currently a work in progress, so proofs remain to be finished. Currently, the -following C features are supported, but are not all proven correct yet:

    • all int operations,
    • non-recursive function calls,
    • local arrays and pointers
    • control-flow structures such as if-statements, for-loops, etc…

    Content +following C features are supported, but are not all proven correct yet:

    • all int operations,
    • non-recursive function calls,
    • local arrays and pointers, and
    • control-flow structures such as if-statements, for-loops, etc…

    Content #

    Papers #

    OOPSLA ‘21
    Yann Herklotz, James D. Pollard, Nadesh Ramanathan, and John Wickerson. Formal Verification of High-Level Synthesis. In Proc. ACM Program. Lang. 5, OOPSLA, 2021. [pdf]
    LATTE ‘21
    Yann Herklotz and John Wickerson. High-level synthesis tools should be proven diff --git a/index.xml b/index.xml index 27dac7e..a8ae56a 100644 --- a/index.xml +++ b/index.xml @@ -1,10 +1,8 @@ -Vericert onhttps://vericert.ymhg.org/Recent content in Vericert onHugo -- gohugo.ioen-us© 2020-2021 Yann HerklotzBuilding Vericerthttps://vericert.ymhg.org/docs/building/Mon, 01 Jan 0001 00:00:00 +0000https://vericert.ymhg.org/docs/building/To build Vericert, the provided Makefile can be used. External dependencies are needed to build the project, which can be pulled in automatically with nix using the provided default.nix and shell.nix files. +Vericerthttps://vericert.ymhg.org/Recent content on VericertHugo -- gohugo.ioen-uk© 2020-2021 Yann HerklotzBuilding Vericerthttps://vericert.ymhg.org/docs/building/Mon, 01 Jan 0001 00:00:00 +0000https://vericert.ymhg.org/docs/building/To build Vericert, the provided Makefile can be used. External dependencies are needed to build the project, which can be pulled in automatically with nix using the provided default.nix and shell.nix files. The project is written in Coq, a theorem prover, which is extracted to OCaml so that it can then be compiled and executed. The dependencies of this project are the following: -Coq: theorem prover that is used to also program the HLS tool.Coq Style Guidehttps://vericert.ymhg.org/coq-style-guide/Mon, 01 Jan 0001 00:00:00 +0000https://vericert.ymhg.org/coq-style-guide/This style guide was taken from Silveroak, it outlines code style for Coq code in this repository. There are certainly other valid strategies and opinions on Coq code style; this is laid out purely in the name of consistency. For a visual example of the style, see the example at the bottom of this file. +Coq: theorem prover that is used to also program the HLS tool.Coq Style Guidehttps://vericert.ymhg.org/docs/coq-style-guide/Mon, 01 Jan 0001 00:00:00 +0000https://vericert.ymhg.org/docs/coq-style-guide/This style guide was taken from Silveroak, it outlines code style for Coq code in this repository. There are certainly other valid strategies and opinions on Coq code style; this is laid out purely in the name of consistency. For a visual example of the style, see the example at the bottom of this file. Code organization # Legal banner # Files should begin with a copyright/license banner, as shown in the example above.Future Workhttps://vericert.ymhg.org/future/Mon, 01 Jan 0001 00:00:00 +0000https://vericert.ymhg.org/future/This section contains future work that should be added to Vericert to make it into a better high-level synthesis tool. The next interesting optimisations that should be looked at are the following: -Globals Type Support Memory Partitioning Operation Chaining Globals # globals -Type Support # type support -Memory Partitioning # memoryUnreleased Featureshttps://vericert.ymhg.org/docs/unreleased/Mon, 01 Jan 0001 00:00:00 +0000https://vericert.ymhg.org/docs/unreleased/The following are unreleased features in Vericert that are currently being worked on and have not been completely proven correct yet. Currently this includes features such as: -scheduling, if-conversion, loop pipelining, and functions. This page gives some preliminary information on how the features are implemented and how the proofs for the features are being done. Once these features are properly implemented, they will be added to the proper documentation.Using Vericerthttps://vericert.ymhg.org/docs/using-vericert/Mon, 01 Jan 0001 00:00:00 +0000https://vericert.ymhg.org/docs/using-vericert/Vericert can be used to translate a subset of C into Verilog. As a simple example, consider the following C file (main.c): +globals, type support, memory partitioning, and loop pipelining. Globals # Globals are an important feature to add, as have to be handled carefully in HLS, because they have to be placed into memory, and are often used in HLS designs.Unreleased Featureshttps://vericert.ymhg.org/docs/unreleased/Mon, 01 Jan 0001 00:00:00 +0000https://vericert.ymhg.org/docs/unreleased/The following are unreleased features in Vericert that are currently being worked on and have not been completely proven correct yet. Currently this includes features such as: +scheduling, operation chaining, if-conversion, and functions. This page gives some preliminary information on how the features are implemented and how the proofs for the features are being done. Once these features are properly implemented, they will be added to the proper documentation.Using Vericerthttps://vericert.ymhg.org/docs/using-vericert/Mon, 01 Jan 0001 00:00:00 +0000https://vericert.ymhg.org/docs/using-vericert/Vericert can be used to translate a subset of C into Verilog. As a simple example, consider the following C file (main.c): void matrix_multiply(int first[2][2], int second[2][2], int multiply[2][2]) { int sum = 0; for (int c = 0; c &lt; 2; c++) { for (int d = 0; d &lt; 2; d++) { for (int k = 0; k &lt; 2; k++) { sum = sum + first[c][k]*second[k][d]; } multiply[c][d] = sum; sum = 0; } } } int main() { int f[2][2] = {{1, 2}, {3, 4}}; int s[2][2] = {{5, 6}, {7, 8}}; int m[2][2] = {{0, 0}, {0, 0}}; matrix_multiply(f, s, m); return m[1][1]; } It can be compiled using the following command, assuming that vericert is somewhere on the path. \ No newline at end of file diff --git a/manifest.json b/manifest.json index 26a2c92..c9bce8a 100644 --- a/manifest.json +++ b/manifest.json @@ -1,6 +1,6 @@ { - "name": "", - "short_name": "", + "name": "Vericert", + "short_name": "Vericert", "start_url": "/", "scope": "/", "display": "standalone", diff --git a/sitemap.xml b/sitemap.xml index 8ab2110..d6d7f99 100644 --- a/sitemap.xml +++ b/sitemap.xml @@ -1 +1 @@ -https://vericert.ymhg.org/docs/building/https://vericert.ymhg.org/categories/https://vericert.ymhg.org/coq-style-guide/https://vericert.ymhg.org/docs/https://vericert.ymhg.org/future/https://vericert.ymhg.org/tags/https://vericert.ymhg.org/docs/unreleased/https://vericert.ymhg.org/docs/using-vericert/https://vericert.ymhg.org/ \ No newline at end of file +https://vericert.ymhg.org/blog/https://vericert.ymhg.org/docs/building/https://vericert.ymhg.org/categories/https://vericert.ymhg.org/docs/coq-style-guide/https://vericert.ymhg.org/docs/https://vericert.ymhg.org/future/https://vericert.ymhg.org/tags/https://vericert.ymhg.org/docs/unreleased/https://vericert.ymhg.org/docs/using-vericert/https://vericert.ymhg.org/ \ No newline at end of file diff --git a/tags/index.html b/tags/index.html index ea676a9..51e7d45 100644 --- a/tags/index.html +++ b/tags/index.html @@ -1,4 +1,4 @@ -Tags | -
    +Tags | Vericert +
    Tags -

    Tags

    \ No newline at end of file +
    \ No newline at end of file diff --git a/tags/index.xml b/tags/index.xml index 2f5d942..bd2a121 100644 --- a/tags/index.xml +++ b/tags/index.xml @@ -1 +1 @@ -Tags onhttps://vericert.ymhg.org/tags/Recent content in Tags onHugo -- gohugo.ioen-us© 2020-2021 Yann Herklotz \ No newline at end of file +Tags on Vericerthttps://vericert.ymhg.org/tags/Recent content in Tags on VericertHugo -- gohugo.ioen-uk© 2020-2021 Yann Herklotz \ No newline at end of file -- cgit