Come compcer "dimostra" cose diverse nella sua base di codice

Question

Per capire Esempi di prove formali, Sono interessato a come Compcert Applica tecniche di "prova". In particolare, mi chiedo quale sia un esempio particolare di qualcosa di compenst "dimostra" nel loro repo di Github, quindi posso ottenere una comprensione di come le prove vengono applicate nella pratica (a qualcosa che è in qualche modo familiare, tecnologia compilatore). Ho avuto un po 'di esperienza minima con CoQ, quindi dovrei essere in grado di seguire. Ho anche qualche esperienza con x86, quindi forse qualcosa nella cartella X86 sarebbe un buon esempio. O forse qualcosa direttamente a che fare con la lingua C (come GLIGHT) o con con memoria.

In X86/ASM.V, ne hanno diversi Inductive Definizioni, che penso sia una prova in sé. Per esempio:

Inductive ireg: Type :=
  | RAX | RBX | RCX | RDX | RSI | RDI | RBP | RSP
  | R8  | R9  | R10 | R11 | R12 | R13 | R14 | R15.

Inductive instruction: Type :=
  ...

Allora ne hanno un po ' Definition Definizioni:

Definition code := list instruction.

Definition is_label (lbl: label) (instr: instruction) : bool :=
  match instr with
  | Plabel lbl' => if peq lbl lbl' then true else false
  | _ => false
  end.

Chiedendosi se questa è anche una "prova" di qualche tipo da quando (penso) è una sorta di genere.

Loro hanno anche Lemma definizioni, dove il esplicito Le prove sono:

Lemma is_label_correct:
  forall lbl instr,
  if is_label lbl instr then instr = Plabel lbl else instr  Plabel lbl.
Proof.
  intros.  destruct instr; simpl; try discriminate.
  case (peq lbl l); intro; congruence.
Qed.

Capisco COQ TACTICS, ma in realtà non ho scritto prove da solo, quindi non ho applicato conoscenze.

Quindi qui abbiamo Inductive è usato in a Definition che viene utilizzato in a Lemma. E poi sembra che il lemma sia usato da altri lemmi:

Lemma transl_code_label:
  forall lbl f c ep tc,
  transl_code f c ep = OK tc ->
  match Mach.find_label lbl c with
  | None => find_label lbl tc = None
  | Some c' => exists tc', find_label lbl tc = Some tc' /\ transl_code f c' false = OK tc'
  end.
Proof.
  induction c; simpl; intros.
  inv H. auto.
  monadInv H. rewrite (transl_instr_label' lbl _ _ _ _ _ EQ0).
  generalize (Mach.is_label_corct lbl a).
  destruct (Mach.is_label lbl a); intros.
  subst a. simpl in EQ. exists x; auto.
  eapply IHc; eauto.
Qed.

In questa domanda mi chiedo cosa consista una prova in Compcert, dato un esempio come quanto sopra. Vorrei essere in grado di sapere cosa ho bisogno di scrivere una prova per il mio software, sapendo prima cosa sta effettivamente "dimostrando" e come lo stanno "dimostrando". Sembra che ci siano tipi (Induttivo e definizione), e poi prove (Lemma e prova). Non sono sicuro se le cose induttive/definizioni siano prove in sé e per sé. Le prove tradizionalmente sono essenzialmente solo alberi di derivazione dell'applicazione di regole, ma non sono esattamente sicuro se questo è ciò che sta accadendo qui. Sembra che le tattiche di CoQ stiano solo creando un albero di derivazione, correggimi se sbaglio. Quindi il lemma/prova è solo un albero di derivazione (un mucchio di regole applicate) fino agli "assiomi" (definizioni e tipi induttivi). Il fatto che potrebbe esserci un errore di elettronica (non credo), quindi la prova è davvero di un sistema "puro" in un certo senso. Quindi prove pratiche vengono applicate a sistemi puri che fanno alcune ipotesi sull'ambiente.

Alla fine, mi chiedo, il tipo di "sistema di prova" compone è. Ciò che lo rende un buon sistema di prove formali. Sapendo questo, sarei in grado di applicare "prove" su roba al di fuori di Compcert ma in altri contesti di programmazione. Si chiede anche se esiste una sorta di "specifica" su cui Compcer viene verificato formalmente o se è solo il "modello" (come nel modello nel controllo del modello vs. specifica).