OS_Module 19 behaviout
Michael Foot (522) 26 posts |
I was looking at some old code that uses OS_Module 19 to enumerate the ROM modules.
Is this a known change to functionality? If so, what is the correct way to enumerate ROM modules now? Thanks, Michael. |
Rick Murray (539) 13870 posts |
Are you sure it wasn’t calling XOS_Module? That old code shouldn’t have worked… PRM 1-253 (DDE PDF version) states:
|
Michael Foot (522) 26 posts |
The existing code is assembler and I’ve noticed that the compare was only doing a < and not <= which is why it was going into an infinite loop. Didn’t spot that before but I can change that to fix it. Yes, the old code was calling XOS_Module, but because the behaviour has changed between RO4 and RO5, it highlighted the issue. The example above still produces different results between RO4 and RO5. Using XOS_Module on RO5 causes R0 to become corrupted and R1 stays the same (ie. does not get incremented) when the end of the module list is hit. Under RISC OS 3 and 4, R0 would stay at 19 and R1 would reset and return a value less than the current module number (usually 0 or 1). https://www.riscosopen.org/wiki/documentation/show/OS_Module%2019 states:
indicating that when the module id hits the end of the list, the section is incremented and the module id should be reset to 0 but maybe because there are no more sections and no more modules, it does not do this now? |
Jeffrey Lee (213) 6048 posts |
I think the source of your problems is a bug in your code, rather than a change in the OS (CVS doesn’t show our implementation of OS_Module 19 as having any significant changes made to it since RISC OS 3.6 – which is as far back as the history goes for the kernel). OS_Module 19 essentially enumerates modules in the following way: while(true) { find module section R2 if (R1 < number of modules in section) then { get details of module R1 R1 += 1 return } if (R2 was the last section containing any modules) then return R2 = next section R1 = 0 } I’m guessing your RISC OS 3/4 machines have podules or network cards fitted. In which case your loop will enumerate all the main ROM modules, enumerate the first podule/NIC module, and then terminate (with R1=1). But on a machine without podules (traditional RO 5) R1 will never get reset and so you’ll hit the ‘no more modules’ error instead.
Are you sure the “corrupted” R0 isn’t actually a pointer to the error block? (i.e. V flag should be set) |
Michael Foot (522) 26 posts |
Hi Jeffrey, Thanks for the clarification. You are right on both counts. On RO 3/4 machines it does skip to the podule sections, but these don’t exist on the RO5 machine, so it terminates. The “corrupted” R0 is in fact a pointer to the error block so my bad for not spotting that. Cheers, Mike. |