TriCheck: Memory Model Verification at the Trisection of Software, Hardware, and ISA
Furkejuvvon:
| Publikašuvnnas: | arXiv.org (Feb 8, 2017), p. n/a |
|---|---|
| Váldodahkki: | |
| Eará dahkkit: | , , , |
| Almmustuhtton: |
Cornell University Library, arXiv.org
|
| Fáttát: | |
| Liŋkkat: | Citation/Abstract Full text outside of ProQuest |
| Fáddágilkorat: |
Eai fáddágilkorat, Lasit vuosttaš fáddágilkora!
|
MARC
| LEADER | 00000nab a2200000uu 4500 | ||
|---|---|---|---|
| 001 | 2075307729 | ||
| 003 | UK-CbPIL | ||
| 022 | |a 2331-8422 | ||
| 024 | 7 | |a 10.1145/3037697.3037719 |2 doi | |
| 035 | |a 2075307729 | ||
| 045 | 0 | |b d20170208 | |
| 100 | 1 | |a Trippel, Caroline | |
| 245 | 1 | |a TriCheck: Memory Model Verification at the Trisection of Software, Hardware, and ISA | |
| 260 | |b Cornell University Library, arXiv.org |c Feb 8, 2017 | ||
| 513 | |a Working Paper | ||
| 520 | 3 | |a Memory consistency models (MCMs) which govern inter-module interactions in a shared memory system, are a significant, yet often under-appreciated, aspect of system design. MCMs are defined at the various layers of the hardware-software stack, requiring thoroughly verified specifications, compilers, and implementations at the interfaces between layers. Current verification techniques evaluate segments of the system stack in isolation, such as proving compiler mappings from a high-level language (HLL) to an ISA or proving validity of a microarchitectural implementation of an ISA. This paper makes a case for full-stack MCM verification and provides a toolflow, TriCheck, capable of verifying that the HLL, compiler, ISA, and implementation collectively uphold MCM requirements. The work showcases TriCheck's ability to evaluate a proposed ISA MCM in order to ensure that each layer and each mapping is correct and complete. Specifically, we apply TriCheck to the open source RISC-V ISA, seeking to verify accurate, efficient, and legal compilations from C11. We uncover under-specifications and potential inefficiencies in the current RISC-V ISA documentation and identify possible solutions for each. As an example, we find that a RISC-V-compliant microarchitecture allows 144 outcomes forbidden by C11 to be observed out of 1,701 litmus tests examined. Overall, this paper demonstrates the necessity of full-stack verification for detecting MCM-related bugs in the hardware-software stack. | |
| 653 | |a Mapping | ||
| 653 | |a Systems design | ||
| 653 | |a Program verification (computers) | ||
| 653 | |a Compilers | ||
| 653 | |a Hardware | ||
| 653 | |a Specifications | ||
| 653 | |a Software | ||
| 653 | |a Computer architecture | ||
| 653 | |a Computer memory | ||
| 700 | 1 | |a Manerkar, Yatin A | |
| 700 | 1 | |a Lustig, Daniel | |
| 700 | 1 | |a Pellauer, Michael | |
| 700 | 1 | |a Martonosi, Margaret | |
| 773 | 0 | |t arXiv.org |g (Feb 8, 2017), p. n/a | |
| 786 | 0 | |d ProQuest |t Engineering Database | |
| 856 | 4 | 1 | |3 Citation/Abstract |u https://www.proquest.com/docview/2075307729/abstract/embedded/6A8EOT78XXH2IG52?source=fedsrch |
| 856 | 4 | 0 | |3 Full text outside of ProQuest |u http://arxiv.org/abs/1608.07547 |