diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/design/027-computation-core.md | 11 | ||||
| -rw-r--r-- | docs/research/140-spec-suite.md | 41 |
2 files changed, 52 insertions, 0 deletions
diff --git a/docs/design/027-computation-core.md b/docs/design/027-computation-core.md index f26f2d5..cd8dd44 100644 --- a/docs/design/027-computation-core.md +++ b/docs/design/027-computation-core.md @@ -129,6 +129,17 @@ ### 2단계: 중첩, 갈래, 재귀, 글자 (JSON) +크기 때문에 셋으로 나눈다(2026-10-13). 각각 재는 일이 있다. +- **2a(만듦):** 형식 지정, 바이트 잇기와 자르기, 바이트와 text를 담는 `let`, `while`, `&&`와 `||`의 단락 평가. JSON을 받거나 + 거절하는 검사기로 잰다. 결과는 [140](../research/140-spec-suite.md)의 2a절이다. + - JSONTestSuite에서 틀린 것이 없다. + - 줄 수는 파이썬 이하다(80 대 90). + - 시간은 C의 116배, 파이썬의 1.2배다. + - 쓰다가 드러난 뜻의 틈 하나를 메웠다. `&&`가 양쪽을 다 계산해서 `i < n && d[i]`가 실패했다. 이제 단락 평가이고, 오른쪽이 + 실패할 수 없을 때는 지금처럼 AND 하나를 낸다. 그래서 TPC-C를 포함한 기존 모듈 35개가 바이트까지 같다. +- **2b:** 중첩(레코드 안의 레코드와 리스트), 갈래와 `match`, 값으로서의 리스트, 메시지 필드의 아무 값. JSON을 트리로 읽고 묻는다. +- **2c:** 재귀(부르기와 돌아가기, 함수마다의 검증), 글자로 읽기. + - 레코드의 필드와 리스트의 원소가 아무 값을 가진다. - 갈래와 `match`를 둔다. - 재귀하는 fn과 `while`을 둔다. Pure에는 부르기와 돌아가기, 함수마다의 검증이 생긴다. diff --git a/docs/research/140-spec-suite.md b/docs/research/140-spec-suite.md index 60d40ff..f4c6c48 100644 --- a/docs/research/140-spec-suite.md +++ b/docs/research/140-spec-suite.md @@ -192,6 +192,47 @@ - 기계어 계층은 이 루프를 빠르게 하지 못했다. `PURE_JIT=all`이어도 시간이 같다. 새 명령마다 실행기의 걸음을 불러서다. - 바이트와 비트의 일을 빠르게 하는 것은 핵이 선 뒤의 일이다(027). 그 과녁은 이제 수치 루프가 아니라 이런 일이다. +## 027의 2a: JSON 검사기 (2026-10-13) + +2a에서 더한 것: +- **Pure.** + - 바이트 자르기, 한 바이트 + - 이름으로 담는 바이트와 text 32칸. 칸 번호가 타입을 정하고, 덧붙이기는 제자리에서 하며, 담은 양은 몫에 센다. + - NUM_TEXT의 형식, CONCAT의 바이트 + - `pure-run`이 메시지의 바이트를 파일에서 읽는 길(`message NAME @PATH`) +- **aup.** + - 형식 `{x:08x}`, `{p:.2f}`, 잇기 `+`, 자르기 `b[a .. c]`, `byte(n)` + - 바이트와 text의 let(`s = s + e`는 덧붙이기), `while` + - `&&`와 `||`의 단락 평가 + +**JSON 검사기.** aup의 `examples/json.aup`(80줄)는 RFC 8259의 문법을 처음부터 한 번 읽는다. 열린 배열과 객체는 스택(i64 리스트)에 +둔다. +- **맞음.** JSONTestSuite(1ef36fa)에서 틀린 것이 없다. + - `y_` 95개를 모두 받고 `n_` 188개를 모두 거절한다. + - `i_` 35개 가운데 21개를 받는다: 범위를 넘는 수, 짝 없는 서로게이트 이스케이프, 500겹. + - 14개는 거절한다: UTF-8이 아닌 입력, BOM, UTF-16. + - 세 실행 길의 출력이 바이트까지 같다. + - 이 대조는 Pure의 `make check`(`module_specs`)에 들어갔다. 케이스는 `tests/specs/json`에 넣었다(MIT). 큰 둘은 검사가 만들고 해시로 + 대조한다. +- **줄 수.** 같은 설계의 파이썬 참조 `json_check.py`가 90줄이고 aup가 80줄이다. 막대를 지난다. +- **시간.** 10만 바이트 문서에서 바이트당 299 ns다. C로 쓴 같은 설계는 2.57 ns(116배), 파이썬은 246 ns(Pure가 1.2배 느림)다. 바이트당 + Pure 명령이 339개다. + +**쓰다가 드러난 뜻의 틈.** +- 처음 돌리자 받을 것이 모두 `limit`으로 실패했다. aup의 `&&`가 양쪽을 다 계산해서, `i < n && space(d[i])`가 끝에서 `d[n]`을 읽었다. +- 범위를 먼저 보고 읽는 꼴은 명세 구현의 기본이라 `&&`와 `||`를 단락 평가로 바꾸었다. 식은 아무것도 바꾸지 않으므로, 달라지는 + 것은 오른쪽이 실패할 수 있을 때뿐이다. +- 그래서 컴파일러는 오른쪽이 실패할 수 없을 때 지금처럼 AND나 OR 하나를 낸다. 실패할 수 없는 것은 비교, 상태와 필드 읽기, 걷는 + 항목의 필드, 작은 상수를 더하는 수의 덧셈, 그리고 왼쪽이 이미 계산한 식이다. +- TPC-C의 `order_status` 필터는 오른쪽의 키 찾기와 곱셈을 왼쪽이 이미 계산한다. 그래서 모듈이 바이트까지 같고, Pure의 키 범위 + 찾기도 그대로다. +- Pure, aup, Vega의 소스 가운데 빌드되는 36개를 전후로 견주었다. 달라진 것은 JSON 검사기 하나다. + +**SHA-256 다시.** +- 형식(`"{h0:08x}…"`)과 바이트 잇기(채움)로 다시 써 42줄(닫는 괄호만인 줄 5)이 됐다. 파이썬은 28줄이다. +- 남은 차이는 리스트를 값으로 짓지 못해 생기는 것(메시지 스케줄의 미리 채움), 낱말 만들기, 선언이다. +- 시간은 바이트당 1,437 ns(C의 159배)다. 블록당 명령이 16,476개로 줄었다. + ## 착수 기준 (다음 일) - **바꿀 결정.** 계산의 핵을 설계한다(027). 위 표의 여덟 후보 가운데 무엇을 어떤 모양으로 받을지 정한다. |