Proposal: Globals (pre-cursor to Compilation Units) #30
Conversation
|
Just a note, on top of this definition we would have something like: Record module :=
{ imports : list globname
; definitions : map globname (function + data)
; exports : list globname
}. |
|
|
||
| Section WithFunctions. | ||
| Context (call : funname -> trace -> mem -> list word -> (trace -> mem -> list word -> Prop) -> Prop). | ||
| Context (call : word -> trace -> mem -> list word -> (trace -> mem -> list word -> Prop) -> Prop). |
There was a problem hiding this comment.
funname should remain abstract in this file
There was a problem hiding this comment.
It is abstract, in this version of the semantics you don't call a funname, you call the word that it resolves to.
There was a problem hiding this comment.
Further clarification. The resolve function maps globname to option word and global g denotes to resolve g (if it is defined). So previously, if you wanted to say that ""swap" has this specification", you would now say "resolve "swap" has this specification".
There was a problem hiding this comment.
It wouldn't be difficult to remove this functionality (just don't allow calling expressions), if that is truly desireable. This seems like an easy way to support function pointers within the "be concrete" mantra of bedrock2.
There was a problem hiding this comment.
I'd like to be able to use the file WeakestPrecondition.v with funname being instantitated to string, while others might want to instantiate it to word or to Z or whatever. Can you adapt it so that this becomes possible again?
|
I'd like to see what I still believe that "Because it was simple" is not a good reason for replacing |
bedrock2/src/CompilationUnit.v
Outdated
| Require Import Coq.ZArith.BinIntDef. | ||
| Require Import ExtLib.Data.HList. | ||
| Require Import ExtLib.Data.Fin. | ||
| Require Import ExtLib.Data.Map.FMapAList. |
There was a problem hiding this comment.
looks like these ExtLib dependencies are not needed (but make the build fail)
|
@samuelgruetter I've ported If you can think of any reason within the compiler to separate the two, I'd be really interested in knowing what it is. I've reverted the ability to call expressions per your request. I guess we can also drop the |
|
In the latest build, |
- the automation needs some work right now.
|
@samuelgruetter The only thing that didn't compile in the bedrock2 directory is the swap example. I've updated that with the latest push. Now what breaks is in the compiler directory. |
| Context {varset: SetFunctions var}. | ||
| Notation vars := (set var). | ||
|
|
||
| Variable resolve : glob -> option word. |
There was a problem hiding this comment.
nitpick: I'd prefer mword over word here, even though both refer to the same in this context, it's just that this file consistently uses mword. Or if you prefer, you could make sure nothing of bbv is imported to avoid confusion with bbv's word, and then replace all occurrences of mword by word.
There was a problem hiding this comment.
That's fine. Does nitpicking mean that you're considering merging this?
There was a problem hiding this comment.
If you think that you want to keep using and contributing to (a part of) the code in this repo, and you tell me that merging this would enable you to do so, and you're willing to fix what you broke in the compiler subdirectory so that the build becomes green, and you're willing to deal with further potential nitpicks from my side, then I'd be happy to merge it
2 participants
This generalizes functions into globals. It still doesn't support function pointers though doing so is relatively simple. In summary,
Because it was simple, I also changed
callfrom taking afunnameto taking anexpr(sofbecomesglobal f). Generalizing the semantics completely isn't too difficult. I can add that to this PR if it would be useful. #27 is preventing a complete operational semantics, but if we solve that, it shouldn't be difficult to do this.