micropack: state of play update, add thoughts on overlays

diff --git a/Kernel/platform-micropack/README b/Kernel/platform-micropack/README
index 2be5760..f0e2aed 100644 (file)
--- a/Kernel/platform-micropack/README
+++ b/Kernel/platform-micropack/README
@@ -6,3 +6,51 @@ Test environment for a very squashed build to see what we can achieve in
 Not a useful target, but memory testing stuff
 
 
+Sizes of target blocks:
+
+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
+
+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.
+
+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)
+