'Next' WimpSlot - optimum size?

Now that we have hardware with relatively fast memory (compared with earlier RISC OS machines), is there any advantage in increasing the Next WimpSlot size from the 640k default? I can see no measurable real-world performance difference between 640k and 12800k on this Pi (RO 5.21 dated 21 Feb 2014, running at 900MHz); if anything, the woefully slow network upload speed via LanMan98 seems marginally better under the small slot size.

Very good idea. Low WimpSlot size caused me sometimes a few problems (especially with DDE). 1 MB should be OK.

Shouldn’t any reasonable program set it’s own WimpSlot? ;-)

I would agree that 640K is a bit low when you have quarter/half gigabyte on board. Should maybe be 1-4Mb (primarily for TaskWindows and such that start up without adjusting their slot).

It may be that LanMan98 performs slightly better with a smaller slot because tasks are paged in and out. For every poll cycle (and there can be hundreds in a second), the memory from the old task is mapped out of the way and the new task is mapped in, then after use, this task is mapped out and the next task mapped in….because, remember, all tasks believe their base address is &8000 and this is done by clever manipulation of the memory logical addressing. However, the more memory a task lays claim to, the more work needs to be done. This is why it is good to try to keep a WimpSlot appropriate, instead of just picking “a big number”.
The bigger the WimpSlot, the more work needing to be done, the slower things will run…

AIUI modern RO versions simply flex the wimpslot to suit anyway. This caught me out a while ago as programs I’d written worked fine here on my ARMiniX with no wimpslot declaration, but needed thousands of k on older OS versions.

IIRC I think Jeffrey commented this was a change he’d made, but hadn’t been announced.

Jim

Yes, a year or two ago I tweaked FileSwitch so that it will automatically grow (but not shrink) the wimpslot as needed when loading standard AIF/Absolute files. Once the program is loaded it’s still the program’s responsibility to grow the wimpslot as needed to cope with any runtime memory allocations, but it gets rid of the common problem of programs failing to start in the first place due to the wimpslot being too small.

Unfortunately one area which this change won’t help with is things like the DDE, GCC, makefiles, etc. which try to launch child processes within the same task. The parent task gets copied to the top end of the wimpslot, leaving the bottom end free for the child task to use. But the only way the parent can protect itself from being unintentionally overwritten by the child is for it to artificially limit the wimpslot size (essentially hiding the parent from view), and to prevent any further changes being made to the wimpslot size. So you still need to manually set the wimpslot to a sufficiently large value before you run anything which needs to run child tasks.

Then there’s another big limitation, which is that BASIC is basically incapable of adjusting its wimpslot size. You can manually manage a heap which is located above HIMEM, but that won’t help if your program falls over during initialisation because there wasn’t enough memory for a BASIC variable to be created.

I take this to mean that, subject to the exceptions noted in your para.s 2 and 3, it’s fine to leave the default wimpslot (640k) alone. I’m sure I’m not alone in recording my gratitude for yet another helpful ‘under the bonnet’ tweak!

As Jeffrey says, you’re generally OK with the WimpSlot being 640K, but if you try to use the build system in particular, you’ll tend to find that’s way too small. I normally have mine set at 4096K. GCC is a real bloater so that might need an even larger slot.

GCC and programs written using it normally need 7200K.

GCC and programs written using it normally need 7200K.

Is this really the case? I’ve been compiling some code today with GCC (statically linked with UnixLib) and it’s all been >200K?

Just curious if there is something I should consider since I’m planning on targeting my Acorn A440/1 at some point.

GCC and programs written using it normally need 7200K.

Is this really the case?

Kinda.

For programs which use UnixLib, I believe the default is to use a dynamic area for the runtime heap (in order to work around the 28MB wimpslot limit of 26bit OS versions). The only thing application space will be used for will be the application binary (since dynamic areas are located above the 26bit executable address space limit). So for ‘make’ you need a wimpslot of around 7-8MB, as that’s the size of the make binary plus the GCC binaries.

For code compiled using GCC, the wimpslot size you’ll need will obviously depend on the program in question – i.e. whether it’s using UnixLib or the shared C library, and whether it’s using dynamic areas or not. So a simple program which uses application space won’t need the wimpslot to be much larger than the binary size. Also remember that if you’re running on pre OS 3.5 then UnixLib will be forced to use application space anyway (since OS_DynamicArea was only introduced in 3.5).

Also it might be worth checking what the official line is re: ARM2/3 and pre-OS 3.5 compatibility, as I can’t remember if they’ve officially dropped support for it (or maybe they aren’t actively testing support for old systems anymore?)