The host node starts in its ROM (entry 12), and the boot feeds it the system's source through the console: capsules/v4/sys/map-64.f18, the fourteen .f18 blobs and end.f18, each found, hash-checked and signature-checked as any capsule, then EOT. The ROM assembles the system and starts it at (IDLE); the host reads the image record (v4_image_from_node) for what only the assembled system knows. A ROM error is reported with its blob, line and meaning, then PARITY:FAIL. Deleted: v4/tools/mkimage.c, capsules/v4/nucleus-64.f18, v4/capsule/*.v4, v4/tools/v4tof18.py. The .f18 files are the source now. - text.c speaks the rest of the ROM's language (set, here, store, start; v4_text_value, v4_text_start), so the oracle reads the same source: test_host_rom_nucleus compares the ROM against text.c on the .f18 files, word for word, image record included. Host tests load the .f18 files. - mkmap image writes v4_map_image (the map's description of the system); hosted and the kernel link the ROM and the map instead of v4_image_64.c. - Hera (Captain Bob's ruling, option 1): births stream the system the ROM assembled, as assembled code; hera.4th is unchanged. test_host_unit's host builds the system with the ROM. - New parity lines: PARITY:V4_F18 per blob, PARITY:V4_ROM words=2049 rom_hash=0xa6c792b5821010b7 instructions=60725216. Acceptance: amd64, aarch64, riscv64 boot to ok> with PARITY:V4_POST tests=538 pass=538 fail=0, POST: PASSED, and PARITY:V4_SYSTEM word_count=317 dict_hash=0xe5a57f3eb72ff94a on all three -- the same hash as the prebuilt nucleus gave. make -C v4 test test-32 hosted-check: all pass. Logs: logs/20261015-141648, -141938, -142350. Startup cost under QEMU TCG, the ROM's assembly (last V4_F18 line to V4_ROM): amd64 26.7 s of 132 s to ok>; aarch64 41.0 s of 195 s; riscv64 20.5 s of 101 s. Hosted native: +0.85 s. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
38 lines
1.5 KiB
C
38 lines
1.5 KiB
C
/* capsule.h -- a capsule of F18 code: what a neighbour writes to a node's
|
|
* port to put a programme into it and start it. docs/v4.0.0/MESH.md
|
|
* section 5.
|
|
*
|
|
* A node newly born has nothing in it and executes what arrives at its port
|
|
* (node.h). So a capsule of F18 code is not a format a node has to
|
|
* understand: it is the words themselves, in the order they are sent. For
|
|
* each stretch of memory that is not zero,
|
|
*
|
|
* @p a! @p push the node executes this from its port,
|
|
* address takes these two as its literals,
|
|
* count - 1
|
|
* @p !+ unext and then this: each word that follows is fetched
|
|
* the words ... from the port and stored
|
|
*
|
|
* and at the end
|
|
*
|
|
* jump start
|
|
*
|
|
* This is the F18's own way of loading a node through a port. Nothing here
|
|
* knows what the programme is: StarForth's system, as the machine's ROM
|
|
* assembled it, is one such capsule (what a node that is born is sent:
|
|
* tests/test_host_unit.c), and anything written for the node is another.
|
|
*/
|
|
#ifndef V4_CAPSULE_H
|
|
#define V4_CAPSULE_H
|
|
|
|
#include "v4/node.h"
|
|
|
|
/* Write the capsule that makes a node's memory what `n`'s is, and starts it
|
|
* at `start`: `out` is called with each word in turn. Words of `n` that
|
|
* are zero are not sent -- a node is born with its memory zero. Returns
|
|
* how many words were written. */
|
|
unsigned v4_capsule_write(const v4_node *n, v4_cell start,
|
|
void (*out)(void *self, v4_cell word), void *self);
|
|
|
|
#endif /* V4_CAPSULE_H */
|