user
2.0 KiB
2.0 KiB
FC01 heap_4 — stan weryfikacji
Stan na 2026-07-20
Karta ma jeden centralny eksperyment na niezmodyfikowanym
heap_4.c z FreeRTOS-Kernel V11.3.0. Przebieg jest podzielony na osiem
deterministycznych checkpointów E01–E08 i działa na RV32I/Hazard3.
Potwierdzone na Hazard3
| Event | Stan | Dowód |
|---|---|---|
| E01 | arena po inicjalizacji | free=largest=4080, 1 blok |
| E02 | alloc A(24) |
zużyto 48, zostało 4032 |
| E03 | alloc B(40) |
zużyto 64, zostało 3968 |
| E04 | alloc C(16) |
zużyto 32, zostało 3936 |
| E05 | free(A) |
3984, 2 wolne bloki |
| E06 | free(C) |
4016, 2 bloki, free > largest |
| E07 | free(B) |
free=largest=4080, 1 blok |
| E08 | kontrolowany OOM | NULL, hook=1, asserts=0, PASS=1 |
Na RV32 sizeof(BlockLink_t) == 8, ale portBYTE_ALIGNMENT == 16, więc
prywatne xHeapStructSize == 16. To wyjaśnia zużycie 48/64/32 bajtów.
Diagramy i iteracja
- A1 CONTEXT: pięć kroków CODE — granice odpowiedzialności.
- A2 STRUCTURE: jeden krok CODE i pięć kroków RUN — nagłówek, split, lista adresowa oraz scalenie lewego i prawego sąsiada.
- A5 FLOW: osiem kroków RUN mapowanych 1:1 na E01–E08.
- A6 STATE: pięć reprezentatywnych stanów E01, E04, E06, E07 i E08.
- A7 RUNTIME: tożsamość źródła/ELF, pamięć
ucHeapi końcowy werdykt. - A3, A4 i A8 są jawnie pominięte, ponieważ dublowałyby A2/A5.
Szczegółowa kolejność komend, obserwacji i kryteriów znajduje się w
hazard3-iteration-plan.md.
Wykonane testy
- testy hostowe Task 1–3;
- budowa RV32I i kontrola symboli ELF;
- Hazard3 RTL: zakończenie kodem 0 po 27308 cyklach;
- osiem checkpointów obecnych w ELF;
- walidacja JSON i odwołań
code_ref/snapshot_ref; - kontrola PlantUML, SVG, HTML, TeX i siedmiostronicowego PDF;
- TypeScript/React typecheck generatora.
Pozostaje poza zakresem tej iteracji
- próba na fizycznym RP2350/Pico 2 W;
- commit i publikacja — wymagają osobnego polecenia.