question about role of modules in riscos

You have references to 26 bit style module headers. The correct 32 bit header style is what you used in the filer module work and is below

Sorry posted quickly before a meal.

The document you did with the shorter header (without the messages and flag references) was obviously based on the documentation on the riscos.com site. Unfortunately that version is not fully 32 bit safe and various elements don’t work on modern hardware.

The 32bit module header from ROOL’s PRM, File formats: Relocatable Module

That’s the doc that Rick referenced earlier, which he said he hadn’t got round to finishing.
And we wonder why H0bby1 / G0st is complaining about no documentation. Actually we don’t wonder, we know why.

When a module is initially loaded, reloaded, or after a tidy (in other words, following the Run,Enter, ReInit, or Tidy calls) the Initialisation entry is called.

Rick, I thought RMTidy did nothing these days.

PS. Twiddled with your table a bit.

I think that has been true for a while, but I’ve not looked at the module handler code. Once I know I’ll update accordingly…unless somebody beats me to it. ;-)

The hard part in writing the docs is sourcing information in the first place. But, of course, if that was easy then they’d be no need for the docs to be written and…look I’m tired I’ll be embarrassed by such a lame sentence tomorrow I’m only staying up to take medicine at 8 hour intervals which is real soon now good night

I’m only staying up to take medicine at 8 hour intervals which is real soon now good night

Good morning (when you read this)

The hard part in writing the docs is sourcing information in the first place.

I borrowed the basis of the 32 bit flag info from the old Iyonix pages¹. :)
Also added the otherwise missing information that the presence of the flag does not guarantee compatibility.

¹ Might “rescue” some other bits from there too.

There is a small amount about aps-a/m on page 475/476 of the acorn c3 (1989) manual here.

Thanks, rev.2 of the manual may well cover APCS-A / M if rev.3 was revised for RO2 – that’s when it all changed to the current model.

I began this: https://www.riscosopen.org/wiki/documentation/show/File%20formats:%20Relocatable%20Module

Must get around to finishing it, but I wanted to take apart the OS to verify that what the documentation says is indeed what happens. Of specific note is the extended service call method.

Looks good so far. I agree about cross-referencing with the OS source, in the few areas I’ve looked at there were a few gotcha – such as register preservation/corruption that weren’t documented in the PRM. There’s also flag corruption to consider where it’s applicable.

I wonder how many times Jon has stiffed his test machine while working on ADFFS, or how colourful the language was…
Thousands! And a lot of colourful language ;) It’s been 20+ times this morning alone!

I wouldn’t get too hung up on stiffing machines writing Modules – there’s far easier ways to stiff the machine. If you’re programming at this level it implies some sort of competence, otherwise you wouldn’t attempt it in the first place.

Rick’s point about documentation is sound though, I didn’t read it as elitist – we should have full documentation for 26bit and 32bit that you can refer too. It’s all work in progress though, the Wiki will eventually be at the level we require as the community update it. We don’t want to end up in the APCS-A/M scenario where all documentation has been lost – it may seem irrelevant as it’s legacy/deprecated etc – but if you’re in the situation I am, where you’re trying to get them working on RISCOS 5 – you’re kind of limited if there’s nothing to refer too.

The process I use to update the Wiki is essentially to cover RO3 and above:

1. Start with the RO3.1 PRM, which I’ll copy verbatim, expanding or clarifying where appropriate
2. Cross-check against the RO3.5 revised PRM, updating/adding accordinly.
3. Cross-check the current RISCOS 5 source with the oldest source to see what’s changed, updating accordingly
4. Cross-check against RISCOS 6 documentation as this sometimes notes behavioural changes etc.

Where there’s notable changes between RISCOS 5 and previous versions, I’ll note it in the Notes section. It’s very time consuming and I try to do it in parallel with programming additions to ADFFS so I can double-check the behaviour in actual code.

Anyway with the thing i’m cooking, documentation for writing modules will be useless :D

I borrowed the basis of the 32 bit flag info from the old Iyonix pages1. :)

Yup, I noticed that. I have reworded the text slightly; to make the bitfield entry (singular! ;-) ) a table, and to remove all references to this being the “new” way of doing this. This isn’t new, this is correct for RISC OS 5. The other way is “old” (or “legacy”, “vintage”, “mesolithic”, etc).

I have also removed the note regarding RMTidy as that hasn’t been used since “Medusa”. I don’t remember the project names – RiscPC? https://www.riscosopen.org/viewer/view/castle/RiscOS/Sources/Kernel/s/ModHand?rev=4.11.2.13#l753
Interestingly, it looks like it was FSLock wot broke it. I say “interestingly” as the fact that anything can claim pieces of RMA and there’d be no mechanism for reporting when the claim has moved…that might have been a much bigger flaw in the plan!

Just been checking the Init call. (SWI dispatch) → Module_Load → Load_Module → LinkAndInit → Add(Intrinsic)Incarnation → CallInit. Phew!
CallInit says R9 is module pointer, R10 is envstring, R12 is incarnation. It pushes R0-R6, R11, R12, and R14. So it looks, at least, as if that entry matches up (R11 may be trashable too, but I’ll just stick with what the PRM says).

As Jon says, copy-pasting existing documentation is easy. Verifying that it is correct is quite a bit more involved.

Yup, I noticed that.

:P

I have reworded the text slightly; to make the bitfield entry (singular! ;-) )

I think Castle were working on the basis that other flag words could follow, although which side of the end of the next century we are likely to use all the other 31 bits I’m not sure.

and to remove all references to this being the “new” way of doing this. This isn’t new, this is correct for RISC OS 5. The other way is “old” (or “legacy”, “vintage”, “mesolithic”, etc).

Hmm, yes, the change pre-dates RO6 which doesn’t do it. That’s old.

Perhaps the document should be referencing the old, deprecated way, and emphasising that properly coded a module works on both so the old is just wrong.

I have also removed the note regarding RMTidy as that hasn’t been used since “Medusa”. I don’t remember the project names – RiscPC?

I believe so. I think the reference is to multiple processors (multiple headed beast) and the Acorn boys liked Romano-Greek mythology.

As Jon says, copy-pasting existing documentation is easy. Verifying that it is correct is quite a bit more involved.

There was a reason I didn’t pull lots of other stuff in to fill the gaps.
The 32 bit flag was something I knew, including the fact that contrary to intimations in various documentation the system simply doesn’t check the module content to ensure it is all compatible. At least not not enough to matter.

I think Castle were working on the basis that other flag words could follow,

Didn’t Justin have an idea regarding module priorities or something? I wonder if another bit will be pressed into service when multicore is supported and modules can say “we’re aware of this”? ;-)
I suppose it’s a good thing that stuff doesn’t change around much.

Hmm, yes, the change pre-dates RO6 which doesn’t do it.

I’m going to completely ignore RISC OS 6 until I have worked out a sensible way to explain the bizarre numbering scheme to newbies. Actually, I tend to just refer to this branch as RISC OS 5. We might need to increment if we run out of version numbers, but given we’re still in the low ‘20s, I don’t think it’ll be me updating the documentation regarding this.

emphasising that properly coded a module works on both so the old is just wrong.

The old isn’t wrong, it is just old. Kind of like how I dipped my fingers into mercury and pinged it around the table in chemistry. I enjoy telling that to modern younger teachers who look like they’d have a heart attack – especially if they around around 5 years or more younger than me so likely never will have touched the stuff. In light of modern information, it was wrong. But back then it was “normal”. Kind of like writing modules on a 26 bit only system would not have even had a need for a 32 bit flag. ;-)

the Acorn boys liked Romano-Greek mythology.

So, hand up who was responsible for the TaskWindow message naming!

There was a reason I didn’t pull lots of other stuff in to fill the gaps.

Didn’t feel like correlating information from the PRMs and the actual source? Well, I don’t blame you…

including the fact that contrary to intimations in various documentation the system simply doesn’t check the module content to ensure it is all compatible. At least not not enough to matter.

Huh? It doesn’t check it at all. It simply checks that the 32 bit word is there. If it is, the result will be loaded and executed – even if it immediately blows up…
Any documentation that intimates otherwise is deluded – unless maybe it is the JSAPP or Aemulor help file.

You cannot even hook to Service_ModulePreInit to scan through the module (R0=address, R2=length) and reject the module if it contained non 32 bit safe code. Why? Because the module loader doesn’t bother to check to see if the service call was claimed (https://www.riscosopen.org/viewer/view/castle/RiscOS/Sources/Kernel/s/ModHand?rev=4.11.2.13#l2096). Bad! Bad! Bad! So such a check would need to patch all of the module header words to be zero, then set up a callback to issue an RMKill on it. That’s such a horrid hack. :-(

Sorry if slightly off topic, but reply to Ricks’ reset switch thingy.
I still consider myself an (ab)user, not a programmer. Only just got my head around WIMP apps in BASIC since RPi came out. (Dr WIMP was a breakthrough stepping stone for me.)
When I had my first RISC OS machine, a RISC PC600, Jan 95, I ended up jumping some wires from the reset switch at the back to one I mounted just below the floppy drive eject button. Much software failed at the time. Don’t even mention the StrongARM! Still running as I type this. :)
My RPii, (damned if I know what the plural should be,) all have a reset button too.

I’m going to completely ignore RISC OS 6

RO4.39 :)

Huh? It doesn’t check it at all. It simply checks that the 32 bit word is there. If it is, the result will be loaded and executed – even if it immediately blows up…

Like I said the other week, you can hack a 32 bit header onto any old module. Until you try and do something with it like shut it down or access a feature it sits quietly and you’re OK, mostly, -ish.

Any documentation that intimates otherwise is deluded.

Must be some checking going on according to the PRM¹ modules chapter: (module header format info)

“All code entries must be word aligned and inside the module code area, otherwise the checking performed by RISC OS will consider it invalid.”

¹ On line at riscos.com or in the DDE documents, take your pick

I’m going to completely ignore RISC OS 6

RO4.39 :)

That pretty much makes the point for me. ;-)

Must be some checking going on according to the PRM

As you will see from my other post, RISC OS performs some basic validation on the addresses given in the header to ensure that nothing crazy happens when RISC OS attempts to jump to the address provided.
It is about a screenful of code (which isn’t a lot when it is assembler). It simply validates the headers, not the code itself…

As you will see from my other post (the incorrect message report in Bugs)

Yeah, read that after. That’s after this thread and after organising the content of food bowls for three furries.

It validates the headers not the code itself…

As per the bug report it really ought to do a proper job of reporting where it found the error in the header.
I suppose checking the actual code for 26-bitisms is probably more in Jons’ field of expertise as well as being a touch¹ more complex.

¹ Looking to master the art of understatement here.

You cannot even hook to Service_ModulePreInit to scan through the module (R0=address, R2=length) and reject the module if it contained non 32 bit safe code. Why? Because the module loader doesn’t bother to check to see if the service call was claimed (https://www.riscosopen.org/viewer/view/castle/RiscOS/Sources/Kernel/s/ModHand?rev=4.11.2.13#l2096). Bad! Bad! Bad! So such a check would need to patch all of the module header words to be zero, then set up a callback to issue an RMKill on it. That’s such a horrid hack. :-(

Even if that’s fixed, you can’t use the service call on a 32bit OS as its called after the 32bit check

It would be useful it’s original purpose of patching Modules was re-instated, irrespective of the Modules being 26bit or 32bit. The patching Module can perform the 32bit check and reject if it doesn’t support 26bit Modules.

Small update – I’ve documented all of the “easy” stuff. Now have the more complicated entry points to deal with. ;-)

https://www.riscosopen.org/wiki/documentation/show/File%20formats:%20Relocatable%20Module