question about role of modules in riscos

Perhaps if the RMEnsure /RMload of a module added the module to a table of Application <—> module we would have a method keeping track of what was using a module – assuming people think it worthwhile keeping track.

Very good idea.

aaaaa

I can’t think of very many modules which track active clients, so how would your average third-party support module know to refuse to die when asked?

I have written two or three modules that keep a client count and will refuse to die (not Basalt). They have some form of start and end SWIs and each has a way to reset the count for emergencies. ;-)

A lot of modules don’t bother with this kind of interface, so there’s no way that they can be killed after use.

It is not a matter of being able to kill them, more a way to protect the module from being accidently killed and leaving a client high and dry.

The documentation asked that any software using it called a SWI to register itself with the module, and to similarly call a SWI to deregister when the app was quitting. All the module itself did was keep a count, and it would remain loaded while the count was greater than zero.

+1

Didn’t Jan Kortink I have such a system of registration for tasks, called Zeri.. something or other?

The thing to remember is that any application that requires a particular module to be loaded simply does a check to see whether it is loaded when it is first run – if not it tries to load it or (if unable) flags an error.

The assumption is that the module will stay loaded until the machine is powered off as there is no tracking mechanism to say that ‘the last application that needed this module has just shut down so the OS can now RMKill this module’. Hence the advice that only certain necessary things should be modules as they stay resident.

aaaaa

It would appear I need to make a public apology for some of my comments, which may have been taken out of context. I possibly should have expanded more on where why line of thought was, as in hindsight, it could easily be misinterpreted. My health has been deteriorating over the past six months and I’ve not slept for the past month for more than an hour or so a day, so I’m probably not thinking clearly. Anyhow – that’s no excuse.

I apologise to anyone I’ve offended with my view that ROOL aren’t active enough here, this is a fairly recent point I’ve picked up on now that I’m looking at getting involved in RISCOS development, where I feel leadership would help progress the OS forward. A point I feel strong about as its my day job, is that I you want to build a good team – you need good leadership and some of the points raised in recent months have highlighted this as an issue that needs some focus. Several queries I’ve made for example have received the response “You need to direct that at ROOL” – but I’ve no idea who they are or how to get hold of them. I appreciate there’s a page that gives individual names and their LinkedIn profiles but that’s far from ideal.

There’s some really skilled programmers around at the moment and some fantastic ideas about how to extend RISCOS into a more modern OS that more applicable to today’s requirements, with coordination and project planning key aspects of the OS could be updated – I feel this is where ROOL should be visible.

I’ll admin, I’m fairly new to the scene so am not aware of the history, politics etc of RO5/6, ROOL/Castle etc. but to be honest from recent discussions I’d say fresh blood and fresh ideas from people outside of RISCOS are probably what’s required.

So, once again, I apologise for any offence made.

Addressing some of the points from Steve, WPB etc:

Jeffrey is the biggest contributor with regard to knowledge and contribution to RISCOS, if he doesn’t know the only other folk are the ROOL team, […]

I’m not sure that’s entirely true: others definitely have knowledge of specific areas, and some of the other ex-Acorn people pop up on the newsgroups from time to time with advice.

I was not saying there aren’t others that aren’t knowledgable in specific areas, clearly there are, but on the whole, Jeffrey has the best overall general knowledge of the RISCOS source.

[…] but as far as I can tell they’re a secretive bunch and don’t really contribute much here. They come up with new builds in the background, Pi2 for example, but it’s all very secretive and not at all an open process, which is a shame. Maybe they all have day jobs and can’t commit the time on here – who knows.

I’m not sure that’s a very helpful comment

I retract the comment, clearly ROOL make a large contribution to RISCOS and put in as many hours as they can, this is evident by how quickly the Pi2 build was made public. Obviously they’re not secretive as in “conspiracy theory”, they just remain behind the scenes and don’t necessarily have the time to be public involved on the forum.

You could, of course, roll up your own sleeves and offer to help out; or you could just complain about things and help foster the impression that the ROOL team could find better ways to spend their spare time than working on RISC OS at all… How about contributing documentation (for the Wiki or into CVS) on the stuff that you’ve found out about the OS while working on ADFFS, for example?

That’s exactly what I have been doing, over the past few months I’ve documented a lot of the sound stack on the Wiki as I’ve implemented it in ADFFS. I’ve also made quite a few corrections to clarify wording in pages that are ambiguous or missing detail. CVS – only installed it yesterday, so haven’t figured out that side of things yet – going to be an uphill struggle here I’m afraid before I can contribute to OS development itself.

In any case, Jon makes massive contributions to RISC OS – I’d be surprised if he has a lot of time for anything more!

I wouldn’t go that far, my contribution to RISCOS itself has been minimal to date. Besides the usual bug reporting and suggestions around improving/fixing certain areas I’d say I’ve steered clear of actual RISCOS contribution.
As for the RISCOS scene – I quit my full time day job three years ago to devote 100% of my time to JASPP / ADFFS etc. I’ve had to go back and do the odd contract to pay the bills, but where possible I’ve negotiated short weeks or short days so I can spent at least 4-5 hours a day on the project. As mentioned above, my health isn’t that great at the minute, however I’ve used the lack of sleep to put in an average of 20 hours a day for the past three months whilst coding up the next ADFFS release.

Now I’ll be the first to admit, ADFFS being my main contribution to the RISCOS scene isn’t widely used and there’s not really a big requirement for it, who needs a 1772 FDC emulator, ARM JIT or Arc VMM anyway? Its something I’m pretty much coding for myself more than anything as a technical challenge to keep my brain active. If folk get to play their childhood gaming memories on the Pi as a consequence, all well and good, and where people approach me with requests, I will go out of my way to get them running. The JASPP project which was spun off it however does aim to have a lasting impact on RISCOS, in that the aim is to get ALL legacy software running seamlessly on the latest RISCOS and ARM processors. To achieve this though will require some fundamental changes done to RISCOS – such as vectors high and some major changes to the way memory is managed.

From recent conversations with Jeffrey, I may be able to contribute this myself – particularly around high vectors, but I’ll be honest, I’m out of my depth somewhat and feel intimidated about getting involved in actual RISCOS developement.

Although I’ve picked up other projects, such as extASM, CDfaker and 32bitting games where approached by companies etc. these essentially get my spare time and my main focus is ADFFS / JASPP. Spurred on Fred Graute’s recent tweaks to StrongEd to help improve my coding efficiency, I did spend a day rewriting extASM’s throwback handler and will make that public soon. CDfaker I plan to merge into ADFFS at some point and as for 32-bitted games, a public announcement will be made at the appropriate time and the games made available via PackMan provided there’s no legal issues.

I’m a little surprised that he doesn’t seem to understand how things work around here, then. “It’s all very secretive and not at all an open process” (ie. "it’s all a massive conspiracy) isn’t the kind of helpful comment that I’d expect from someone who’s in touch with what remains of the RISC OS community.

I’m afraid I don’t understand how things work here to be honest, for which I apologise. I’m almost certainly not in touch with the community – I would have dropped ADFFS years ago if I was! I have very little contact beyond posts on here, although do respond to any and all eMail / forum posts both on here and the JASPP forum. I’ve posted a lot in recent weeks due to the health issues and no sleep, but am now trying to make a conscious effort to get more involved with other people / project (SPI / Touchscreens / FPEmulator / Vectors High etc) and reduce the time I spend on my own projects.

CLib is not badly designed.

I was referring to Acorns use of a static jump table and the limitations around soft-loading CLib. Before C was widely used it wasn’t an issue – it’s now a major design flaw that essentially fixes CLib to the most recent version in ROM or loaded at pre-boot. We can’t for example run different versions of CLib for software that doesn’t work with the most recent version for one reason or another. I do plan on looking at this issue at some point, as I’m sure it’s resolvable.

Sure, it is biting us on the ass now but it has its origins in the days where 8MHz was a typical processor speed. Even when the ARM got faster, like the ARM3, the memory bus speed still sucked.
Accordingly, you would take quite a hit if calling C functions via SWIs. As you know more about the SWI dispatch than many, I’m sure you will appreciate that two branches is a lot faster than the entire SWI rigamarole. Plus there is no need to deal with changing mode – an application enters and leaves CLib in USR mode the whole time.
It was designed for speed.

Yes, I appreciate that point. On the ARM2 the lack of a cache did hit SWI dispatch. With the discussion Jeffrey and I have been having around opening up ARMops – I wonder if it’s worth considering locking the parts of SWI dispatch into the cache on ARM’s with larger caches.

SWI dispatch isn’t so much of an issue now but it was on an 8MHz processor. Perhaps I should code up a CLib shim module that switches the static jump table to SWI’s to see what the impact on performance is – it would vicariously partially solve the soft-load issue but I’m thinking off the top of my head here without any due diligence into the CLib codebase.

I’m certainly familiar with SWI dispatch and CLib’s tables as ADFFS sits between both and in the case of CLib does on-the-fly conversion between APCS-R and APCS-32. APCS-A is next on the list and I’ve started documenting that as I go. I’ve held off putting it into the Wiki and left it in the forum post as I was seeking peer review – I don’t want to put something in the Wiki that’s not 100% accurate and APCS-A is not documented anywhere as far as I can tell. If someone has a copy of the very first Acorn C – there may be documentation there, but it’s been fairly extensively erased from everywhere to the point Acorn probably wished it never existed!

Perhaps if the RMEnsure /RMload of a module added the module to a table of Application <—> module we would have a method keeping track of what was using a module – assuming people think it worthwhile keeping track.

I’m planning on implementing something along these lines in ADFFS, as it will need to track module dependencies. I don’t know it will work or not, but it’s on the cards. The idea being that each application can use it’s own version of a module and ADFFS will isolate them and track app → module relationships.

- – -

To summarise. I apologise for my misplaced comments and having now hopefully responded to all, can see that perhaps my health is impacting me more that I realise. Some of the comments I’ve made don’t sound like me, I’m not one to moan I’m usually up front and trying to lead people through positive example. I know the drugs I’m on now do impact my mental state and possibly have a bearing here, so feel it’s probably best I sort my health out first and return when I’m back to my normal self. When that will be I don’t know as the Dr’s don’t actually know what wrong with me, I’ve had everything from Cancer to IBS, but I’m somewhat ignoring it all as there’s no point worrying about unknowns.

aaaaa

aaaaa

aaaaa

aaaaa

If someone has a copy of the very first Acorn C – there may be documentation there, but it’s been fairly extensively erased from everywhere to the point Acorn probably wished it never existed!

Never give up :) If you seek, you shall find¹ pre-32 bit versions

http://www.4corn.co.uk/articles/acornc5/
Specifically the C manual

Or is that not old enough?

¹ Can’t put my finger on why but it seems to work out for me more often than others.

aaaaa

aaaaa

I don’t want to put something in the Wiki that’s not 100% accurate and APCS-A is not documented anywhere as far as I can tell. If someone has a copy of the very first Acorn C – there may be documentation there, but it’s been fairly extensively erased from everywhere to the point Acorn probably wished it never existed!

The Google-fu is not strong in this one…

From http://www.riscos.com/support/developers/prm/procstd.html :

APCS-A: The obsolete Arthur application PCS

This obsolete binding of the procedure-call standard is used by Arthur applications running in ARM user-mode. The applicable call-frame register bindings are as follows:

sl RN 13 ; stack limit/stack chunk handle
fp RN 10 ; frame pointer
ip RN 11 ; used as temporary workspace
sp RN 12 ; lower end of current stack frame

(Use of r12 as sp, rather than the architecturally more natural r13, is historical and predates both Arthur and RISC OS.)

In this binding of the APCS, the stack is segmented and is extended on demand. Acorn’s language-independent run-time kernel allows language run-time systems to implement stack extension in a manner which is compatible with other Acorn languages.

The stack limit register, sl, points 512 bytes above a stack-chunk descriptor, itself located at the low-address end of a stack chunk. In other words:

sl = SL_LWM + 512.

The value of sl must be valid immediately before each external call and each return from an external call.

Although not formally required by this standard, it is considered good taste for compiled code to preserve the value of sl everywhere.

There is also APCS-M (sl=r12, fp=r10, ip=r11, sp=r13) which is unlikely to be seen “in the wild”.

There is a lot of really useful info here too: http://www.chiark.greenend.org.uk/~theom/riscos/docs/CodeStds/APCS.txt

If we’re doing bad-ass French guys looking after young girls, here’s my contribution:

aaaaa

aaaaa

aaaaa

Anyhow – that’s no excuse.

That’s a very good one for me.

You make great work and I hope you take some pleasure to do it. I take some to see the results :)

who needs a 1772 FDC emulator, ARM JIT or Arc VMM anyway?

A lot of people. And when old Wimp applications will use it… everyone.

The only ‘problem’ is that a lot of people don’t use a Pi, but other computers, with problems of sound, fullscreen modes, etc.

Not a big deal.

My health has been deteriorating over the past six months and I’ve not slept for the past month for more than an hour or so a day, so I’m probably not thinking clearly.

Be careful not to burn yourself out.

I apologise to anyone I’ve offended with my view that ROOL aren’t active enough here,

There is a big difference between not being visible and being some kind of conspiracy. While I can understand the desire to keep the Pi2 a secret (so that RISC OS was ready for the launch instead of turning up a random time later), it did concern me that Jeffrey didn’t appear to have been in the loop regarding this, as he appears to be one of the more visible contributors both to the forums and the codebase (despite not being a part of ROOL itself).

where I feel leadership would help progress the OS forward.

Well, yes and no.

Yes – it would be nice to see some more evident leadership with regards to future directions (for example, the iMX6 board. I presume work is going on in the background to maximise the features of that board. Well, think hypothetically: if multicore support is being added, in what context (SMP, AMP, etc) and will these changes be fed back into the open ROOL versions of RISC OS? The reason I ask is because we now have an affordable multicore processor so sooner or later this very question is going to be tackled in the open build because, well, we’re only using 1/4 of the available processing power of the Pi2.
Is there going to be some kind of synchronisation here, if this does happen, or are the two different builds are going to go in different directions? Because, um, that worked so well the last time. :-P
This is, of course, hypothetical, but it is a bit silly to imagine somebody is designing a new board with a lot of power and not considering ways in which to make use of that power.

The No? Well, I think the last thing a company that wants to get stuff done is going to do is throw the question to us lot. How long has the multicore thread been running? About as long as ARM has had multiple cores. And has any sort of concensus been reached? ;-)

Several queries I’ve made for example have received the response “You need to direct that at ROOL” – but I’ve no idea who they are or how to get hold of them.

https://www.riscosopen.org/content/contact

It isn’t exactly ideal, but it is a lot better than trying to talk to anybody at Google. I while back I noticed Google Maps was taking you down an on ramp and asking you to turn literally a U turn into oncoming high speed traffic (instead of going to the roundabout on the correct side of the flyover and using the correct on ramp). I reported this, but since you can’t actually speak to a real Google person, and there is no emergency “flag this as potentially dangerous”, it took a couple of months for a map builder volunteer to make small modifications which were “approved” (how?) before more modifications could be made. The road had to be split in two lanes (and approved) then given unique sense (and approved) then the ramps modified to fit the sense (and approved). I think it took about three months in total. I took a photo at the time and any competent outfit ought to have looked at the photo and thought “oh, right…”.

So, if Google with all their money and power can’t get user interaction sorted, don’t complain too much that ROOL isn’t exactly a strong presence in the forums. ;-)

with coordination and project planning key aspects of the OS could be updated – I feel this is where ROOL should be visible.

Certainly, that makes sense. But some people are going to be vocal about not seeing it that way. After all, some people are intent on running a mostly-dead branch of the OS on mesolithic hardware for reasons that are emotional rather than logical.

I’ll admin, I’m fairly new to the scene so am not aware of the history, politics etc of RO5/6, ROOL/Castle etc.

In a nutshell: Some really stupid stuff happened. A lot of hate was created. Some people still haven’t gotten over it. The end.

I should have been a bit clearer here as I was referring to forum contribution, if you want to know something, Jeffrey is your best first port of call as he’s active here most of the day and always goes out of his way to assist – I certainly wouldn’t be here today if it wasn’t for Jeffrey, I would have given up in frustration long ago.

Hear! Hear!
I used to participate in the newsgroups but orange dropped all support for them (probably a cut-cutting measure in the guise of dropping support for piracy (how hard is it to filter out the .bin groups?)). At that point, I used Google Groups for a while but it kept getting slower and more bloated and since finding a working open news server was not exactly easy, I decided to just give it up. I get a lot more out of this than I do out of the newsgroups, and personally I think that if anybody is serious about developing or developing for RISC OS, they’d probably be here in some capacity anyway.

It is just a shame that people come and go. For example, nemo’s last post was last July. It’s a shame, I think his UTF-8 command line would have been a good extension to RISC OS.

Now I’ll be the first to admit, ADFFS being my main contribution to the RISCOS scene isn’t widely used and there’s not really a big requirement for it, who needs a 1772 FDC emulator, ARM JIT or Arc VMM anyway?

I’m not sure about the FDC emulation ;-) but there is a desire to be able to run older software that never made the 32 bit transition.

If folk get to play their childhood gaming memories on the Pi as a consequence, all well and good,

Err… I had a Sega Master system. :-p

I have very little contact beyond posts on here, although do respond to any and all eMail / forum posts both on here and the JASPP forum.

It’s the same for me (if you swap forum for half-assed blog). I had no qualms about dropping the newsgroups. More time for coding/watching animé.

but am now trying to make a conscious effort to get more involved with other people / project (SPI / Touchscreens / FPEmulator / Vectors High etc) and reduce the time I spend on my own projects.

I am interested in following the development of the touchscreen driver. I think the really interesting thing will be how to adapt the RISC OS API (which pretty much requires two different types of click (Select and Menu)) to a device that… responds to taps.
There are two technical challenges here. The first is getting the hardware working, the second is getting it working with RISC OS.
Once that has been done, I could see a larger Pi case with a big LiPo battery and VREG to make a unique portable device. Not exactly a tablet, not exactly a computer. Something in between.

it’s now a major design flaw

It is a major flaw, but given the reasons why it was done, it does make sense.

We can’t for example run different versions of CLib for software that doesn’t work with the most recent version for one reason or another.

Examples? Unlike libraries on some other platforms, we do try hard for some degree of backwards compatibility; to the point where the 26/32 neutral CLib would work with older (APCS-R) and newer (APCS-32) software even though the jump table stuff is different between the two. Back in the RiscPC days when Castle seemed to be throwing out a new version of CLib every month, I never experienced problems. I just dropped the latest CLib in and rebooted and there it was.

Things, of course, will be more complicated for you as our (32 bit) CLib doesn’t need to pay any attention to APCS-R as such software technically won’t work on the platform; so I can understand a need for you to intervene as CLib sets itself up, though this isn’t so much a fault of CLib’s compatibility as it is you successfully pulling off “the impossible”.

Yes, I appreciate that point. […] SWI dispatch isn’t so much of an issue now but it was on an 8MHz processor. Perhaps I should code up a CLib shim module that switches the static jump table to SWI’s to see what the impact on performance is – it would vicariously partially solve the soft-load issue but I’m thinking off the top of my head here without any due diligence into the CLib codebase.

I would be interested in seeing what effect such a thing has, for the sake of knowing; however I do want to point out that Linux discarded SWI numbers when EABI was introduced:

Since this already causes an incompatible change in the system call interface, the opportunity has been taken to slip in a more efficient, totally incompatible way of doing system calls: instead of using the swi __NR_SYSCALL_BASE(==0x900000)+N instruction, where N is the number of the system call, swi 0 is always used with the system call number stashed in register r7. This is more efficient because the kernel no longer has to go and fish N out of the instruction stream(*), which used to have a negative impact on the efficiency of processors with separate text and data caches (i.e. most ARMs).

The problem with SWI <number> is that not only are you performing a lot of code on the SWI dispatch itself (which may or may not be able to live within the cache, as you postulate), you are also polluting the data cache with code in order to be able to read what SWI was wanted.
Of course, a lot of this can be masked by the high speeds of modern ARM processors; that doesn’t mean it isn’t wasteful, it just means is it wasteful more quickly. :-)

and APCS-A is not documented anywhere as far as I can tell.

Described above.

When that will be I don’t know as the Dr’s don’t actually know what wrong with me,

Oh. Wow. That’s useful.
There’s nothing more aggravating than you knowing something is wrong and the medical profession shrugging and saying either “no there isn’t” or “dunno”.
I have a lesser problem. Dry eyes. But not during the day, only while I sleep. Accordingly, I only manage to sleep for around 2 hours or so before it wakes me up. I need to thing of sad things to make me cry (sometimes this isn’t easy) so I can go back to sleep for a while.
This happens every night. Eye drops don’t really help.
My optician? She told me that this wasn’t possible. Dry eyes are dry all the time.
She doesn’t live with it. I do. WTF does she know?
Grrr….

Snow Crash → well, that’s just about every post-cyberpunk trope rolled into one picture.

Is it a film? I’m not familiar with it. But let me guess. He’s a hacker who sidelines in working out his rather prominent katana. One of them will be a skateboarder, possibly the chick, and her job will be delivering pizza while working with katana-dude to take down some huge overtly-powerful AI system that threatens the world in some really disturbing way (that possibly means augmented reality going astray, exploding brains, etc).

Am I close?

aaaaa

aaaaa

aaaaa

The Google-fu is not strong in this one…

From http://www.riscos.com/support/developers/prm/procstd.html

I totally ignored the old ROL as I assumed they’d be covering halfway modern stuff. You know what they say – never assume.
Anyway, I think I might have a copy of the ANSI C (v3) info around if I dig enough.

Well, think hypothetically: if multicore support is being added, in what context (SMP, AMP, etc) and will these changes be fed back into the open ROOL versions of RISC OS? The reason I ask is because we now have an affordable multicore processor so sooner or later this very question is going to be tackled in the open build because, well, we’re only using 1/4 of the available processing power of the Pi2.

Interesting question. The OS source is open, the commercial license requires feedback of the externally developed code. The question is does that also mean the code fed back is open source?

Is there going to be some kind of synchronisation here, if this does happen, or are the two different builds are going to go in different directions? Because, um, that worked so well the last time. :-P

I’d assume it has to really, simply because the limited number of contributors round here would probably all “fork off” so to speak.