AnachronautandClaude Opus 5
fb7b224bbb
The output image is gone. It was eighteen kilobytes and it is now one block of window, because the file was always produced in order and only ever needed to be written that way. Everything works in FILE OFFSETS now. A cursor is a two byte number counting from the front of the file, and since a block is two hundred and fifty six bytes, the block it lands in is the offset's high byte and the place within that block is its low one - so there is no division anywhere, and ImgWalk, ProgPut and DataPut needed no change but where they start. ONE WINDOW RATHER THAN THREE. The plan said three: one per segment, and a third for the block where the program ends and the data begins, which belongs to both. Fetching a block back instead makes all of that one case. The header is patched after every byte is out, the boundary block is written by both cursors, and both are simply revisits - a revisit is what fetching handles. osFileFetch is the service that allows it, and is the read side of the write. A run of bytes in one segment costs nothing extra; a switch between segments costs two block operations, and a source file has a few dozen switches and several thousand bytes. Two bugs, both a pointer meaning two things: putAt took the cursor to advance in DP2 and then wanted DP2 for the window's address. A call puts DP2 back the way it was AT THE CALL, so the step at the end moved whatever the last call had left there - the window walked off across memory while the cursor stood still. It goes in memory now, like the block did in S1, and for the same reason. The size the file is created at could not be right. How many vectors are actually installed is not known until the second pass has resolved their handlers, and by then the file must already exist to be written into - so Keys, which brings one vector, came out four bytes short. Teaching the first pass to count them meant teaching it about devices, and about a Boot line in a loadable program not being installed at all, which is two ways to disagree with the second pass about what a file contains. So osFileDone is told the size instead. A writer asks for as much as the file could possibly come to - the whole of it plus four bytes for every vector DECLARED, which no file can exceed - and says what it really came to at the end. The blocks it did not use go back to the free count. Asking for too much costs a moment; asking for too little writes off the end of a file. That is a better service for it, not a workaround. A writer that cannot know its size until the last byte is the ordinary case, and it is exactly the case this whole rung exists for. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01E2JrLzFvuFX9fgi1LDRjrW
83 lines
4.3 KiB
NASM
83 lines
4.3 KiB
NASM
; Where the assembler's big buffers live.
|
|
;
|
|
; A map rather than a set of declarations, and it has a file of its own because the reader
|
|
; and the label table both need addresses out of it while neither includes the other.
|
|
;
|
|
#Data
|
|
|
|
; NOT #Reserve, AND THAT IS THE WHOLE POINT. Reserved space in a segment is written into
|
|
; the file as zeroes and copied at load, so 22K of scratch made a 34K file - and a loaded
|
|
; program is staged at 0x8000 before being put in place, which leaves exactly 32,768 bytes
|
|
; for the whole of it. The assembler could not load itself.
|
|
;
|
|
; None of this is initialised data. It is scratch, wanted only while the assembler is
|
|
; running, and while it is running everything above its own data is free: the system keeps
|
|
; below 0x1000, the staging area is only in use during a load, and the Stack comes down
|
|
; from the top. So the addresses are written down here and the file carries none of it.
|
|
;
|
|
; 0x4000 6144 the label index, 1536 entries of four
|
|
; 0x5800 16384 the label names, packed end to end
|
|
; 0x9800 256 one block of the output file, on its way to the disk
|
|
; 0x9900 18176 free
|
|
; 0xE000 1792 the vector names, 64 entries of twenty eight
|
|
; 0xE700 2048 the reader's stack, six levels of 301
|
|
; 0xEF00 368 which files have been included, sixteen names of 23
|
|
;
|
|
; IT USED TO START AT 0x8000, and the reason given was that everything above the
|
|
; assembler's own data is free. That was true when it was written and stopped being true
|
|
; without anything noticing: the system kept below 0x1000 then, and its data now reaches
|
|
; 0x1FFF, and the assembler's own moved from 0x1000 to 0x2000 with it. The floor came up
|
|
; and the map stayed where it was, leaving sixteen kilobytes between the two that nothing
|
|
; touched.
|
|
;
|
|
; Starting at 0x4000 takes that back. The assembler's data is 4,114 bytes from 0x2000, so
|
|
; there is still nearly four kilobytes of slack in front of this - and room for its data to
|
|
; double before the two would meet.
|
|
;
|
|
; THE ROOM WENT TO ALL THREE OF THE BUFFERS THAT WERE FULL, and there turned out to be
|
|
; three rather than one. The output was the obvious wall - cosmos.bin was 13,245 bytes
|
|
; against 13,312, which is sixty seven - so it was given the lot, and the very next thing
|
|
; added to the system ran out of LABEL NAMES instead, at 8,081 of 8,192. Two ceilings a
|
|
; hundred bytes apart look like one ceiling until the first is lifted.
|
|
;
|
|
; The index was a hundred and eighteen entries from the same place. So: names doubled,
|
|
; index doubled, and the output given what is left, which is still four and a half thousand
|
|
; bytes more than CosmOS needs today.
|
|
;
|
|
; THE OUTPUT IS NO LONGER HELD AT ALL. It used to be built whole in memory and handed over
|
|
; at the end, which is what made a buffer of eighteen kilobytes the largest thing this
|
|
; machine could assemble. The file is produced in order, so it is written as it is made,
|
|
; through one block of window - and the eighteen kilobytes that were its share are free.
|
|
;
|
|
; What to do with them is not obvious and does not have to be decided today. Nothing here
|
|
; is close to full: the names are at half, the index at a third, and the output has no
|
|
; ceiling of its own any more. Leaving the room unclaimed is better than sharing it out
|
|
; among buffers that do not need it, because an unclaimed page is available to whichever
|
|
; one turns out to want it.
|
|
;
|
|
; That ends at 0xF070, with the Stack coming down from 0xFFFF above it - nearly four
|
|
; kilobytes, against the tens of bytes of CALL frames this ever nests.
|
|
;
|
|
; The reader's levels went from 293 to 301 when an include gained somewhere to be looked
|
|
; for: the name in each level is a PATH now, and "/Lib/" is five characters of it. Six
|
|
; levels of 301 is 1806, so the room here has to stay above that - which is why the include
|
|
; list moved up rather than the stack simply being asked to fit.
|
|
;
|
|
; THE TWO THINGS THAT DECIDE THESE SIZES are the largest program it will be asked to build
|
|
; and the largest one it will be asked to read. CosmOS is 475 labels and 9,564 bytes of
|
|
; output; the assembler itself is 555 labels, about 6,800 bytes of name and 11,648 of output. The
|
|
; second is bigger than the first, which is worth knowing: the hardest thing this assembles
|
|
; is not the operating system, it is itself.
|
|
ScratchLabIndex:
|
|
0x40 0x00
|
|
ScratchLabArena:
|
|
0x58 0x00
|
|
ScratchWindow:
|
|
0x98 0x00
|
|
ScratchVecNames:
|
|
0xE0 0x00
|
|
ScratchSrcStack:
|
|
0xE7 0x00
|
|
ScratchIncNames:
|
|
0xEF 0x00
|