From daf690c9a811f802846022e646b7d3bfeb18511d Mon Sep 17 00:00:00 2001 From: Alan Cox Date: Tue, 27 Oct 2015 19:32:25 +0000 Subject: [PATCH] micropack: update documentation --- Kernel/platform-micropack/README | 45 ++++++++------------------------ 1 file changed, 11 insertions(+), 34 deletions(-) diff --git a/Kernel/platform-micropack/README b/Kernel/platform-micropack/README index f0e2aedc..880c583b 100644 --- a/Kernel/platform-micropack/README +++ b/Kernel/platform-micropack/README @@ -5,52 +5,29 @@ Test environment for a very squashed build to see what we can achieve in Not a useful target, but memory testing stuff +File system code is paged with the banks being 4K spaced 0xE00 length copies +of the bank and any fixed data that dribbles over the end. -Sizes of target blocks: +TODO: +Turn memory images into a loadable binary and a block for the disk +Preload the exec syscall bank into the main binary so startup works -syscall_exec16: - ~= 1300 bytes -syscall_other: - ~= 2031 bytes - -syscall_fs2 - 3386 - but includes open (821) and flock(381) which can sleep - leaves 2184 - - -So overlaying syscalL_fs2/syscall_other/syscall_exec16 would save about 2K -and take us to 6800, still 5K short - -Overlaying them all onto syscall_fs would save about 5400 bytes total but -does mean we need to be smart about overlay restores on wakeup. That also -fixes open which would give us a total save of about 6.5K or close to the -6912 or so needed. The single tty hack would probably push us to the needed -size. - -However syscall_fs is only 1.9K so would need to split syscall_fs2 two ways - -Would give us - - syscall_fs - syscall_exec16 - syscall_other - syscall_fs2_a - syscall_fs2_b +Savings: Other candidates for the bot which are big are waitpid at 380 bytes and signal + sigdisp at 621 bytes the pair. signal/sigdisp normally occur only at startup and signal handling so would be acceptable-ish, waitpid always involves a task switch anyway. Neither are ideal but they might work. +Some inline tricks with tty might also save a tiny bit of RAM +Put the swap stack at 0x80-0xFF as we can't realistically run CP/M +emulation. + Other thoughts. When working with small app have a version of some of the overlays that can be loaded in the top of app space - how to do relocations and patches ? Do we want to keep the overlays in the swap space gapped between each swapped app. Disk swap is usually cheap spacewise and it would speed up -their fetching (especially as most IDE drives cache at least a track!). -Would in a sense become a sneaky way to use the IDE cache as a secondary -memory 8) - +their fetching. -- 2.34.1