Norcroft: Module task without WimpSlot?

Hi guys,

I have a module task, which I build at the moment with !GCC. I don’t want it to have a wimpslot, but I understand that SharedCLibrary will always use the wimpslot if you do module-runnable: in cmhg, so I wrote my own assemble entry point _my_entermodule to set up an adequate RMA stack before entering C. Cmhg doesn’t appear to have a way to have a custom routine for module enter, so I put my own in as follows:

$(CMHG) cmhg/header -s header.s -d header.h -o header.o
objcopy --redefine-sym _clib_entermodule=_my_entermodule header.o

I’d like to make this project build with the DDE instead. Is there a command I can use to do this, or some other way?

Try

library-enter-code: _my_enter_module

in your CMHG file.

Thanks, that works a treat.

If we’re wanting to replace more modules with C, I guess that CMHG does need extending to have use-RMA as an option rather than the wimpslot.

use-RMA as an option rather than the wimpslot.

Please!
+1 +1 +1 +1

I tried to do this myself, but it’s a complicated process and in the end I gave up because there were too many restrictions (I think stack use was one of the main ones, and it didn’t seem to like malloc either).

It would, arguably, be useful if something like CMHG was open source, so that what it does and how it does it can be examined in a little more clarity than disassembling a module…

If we’re wanting to replace more modules with C rewrite more module in C,

Fixed that.

I guess that CMHG does need extending to have use-RMA as an option rather than the wimpslot.

Yes, but isn’t there an outstanding issue about RMA fragmentation and leakage?

RMA fragmentation and leakage

If replacing module tasks, it should be not much worse in new C than old ASM.

If replacing module tasks, it should be not much worse in new C than old ASM.

I think people would be hoping for / expecting an improvement rather than a small worsening.
Benefits of hindsight regarding the effects of some existing items. That said, I suppose RO developer(s) are no less likely to repeat a mistake/misjudgement than any other. It’s the human condition.

Is there any reason nowadays for any of the standard Desktop module tasks (save for ShellCLI) to be running wimp slot-less? AcornURI is relatively modern and there must have been some motive for it to have been written slot-less.

Things like ADFS will always claim RMA for hot plugging pollwords etc., but it would be a lot simpler if one could just write them as standard app slot tasks, not having to do special assembler setup, and not worrying about whether C library functions are available.

Of course some arrangement would be needed for how this displays in the Task Manager.

I think people would be hoping for / expecting an improvement rather than a small worsening.

How does one assess this kind of thing? I can see loads of free blocks spread about (around eighty blocks of between sixty-four and five hundred and twelve bytes), but how serious is this? When could we look at the RMA and say defragmenting mission accomplished?

I thought about whipping up a histogram, but I wouldn’t know how to interpret the result.

It isn’t possible to defrag the module area (it’s why *RMTidy does nothing). It’s because all those things that claim bits of RMA hold pointers to the things they’ve claimed, and if the blocks move all the pointers will be wrong.

I did write a little program to display what an utter mess the RMA is – https://heyrick.eu/blog/index.php?diary=20160801

Really, to be honest, I think we ought to stick with the RMA until somebody is in a position to introduce something (anything) better. For a start, keeping code and data apart. Being able to compact the heap. Probably split the entire thing at about the time we introduce the idea of modules that don’t actually need to run in a privileged mode (which is probably most of them)……

but I wouldn’t know how to interpret the result.

This block is a module. This block is known to a module (its private word points to it). This is a claim from something. And all these are previous claims, now abandoned, wasting space.

be running wimp slot-less?

I think the main thing is to differentiate between special system tasks and regular user tasks. You’ll notice that there isn’t necessarily an icon, or even a “quit” menu option for the slotless tasks.
It seems to be that if a task is a part of a module (excepting the case where the module is just a wrapper like the built in apps), then it must be treated differently as it may well tie into some sort of background service (as in the case of AcornSSL). There’s a reason, otherwise the app would be written as a normal app to use in the normal way.

Mmm, 4832 blocks totalling 30MB, 11MB of that free in 172 blocks.

Mmm, 4832 blocks totalling 30MB, 11MB of that free in 172 blocks.

What’s the likelihood that the “free” memory was cleared of all data before being declared free?
Not that data security on RO is a thing, but it seems likely that that old data could be a security risk even if other things were locked down.

Not that data security on RO is a thing, but it seems likely that that old data could be a security risk even if other things were locked down.

I agree. We could introduce a Page Laundry into the kernel? Only put clean pages in to make an app slot or other dynamic areas, use abort exceptions for marking them dirty. The RMA could be trickier :-S