Drobe :: The archives
About Drobe | Contact | RSS | Twitter | Webspace | Tech docs | Downloads | BBC Micro

Profile for Viking

ContactAbout me
Username: Viking
Realname: Les Dundon
About me:
Comments posted:18 (show all)

Recent comments

On First screenshot: Beagleboard runs RISC OS 5 desktop:

Thanks, Druck. As I said I don’t have the wherewithal to quantify this sort of thing. I’m not sure it needs to be a bodge, though. The API Layer as I describe it, or something very close to it, already exists; it’s just that there is only one instance of it, and it’s not defined as such. Creating a new instance of it for each application would resolve many compatibility issues, such as the CSD problem, but I couldn’t quantify the issues it would not resolve (those that would need pre or post filtering; ie bodging).

I accept your view that we should not be writing software which doesn’t do things properly. But I think creating a new instance of the environment that supports an application for each application is doing it properly.

In my view, the real issue, the reason for contemplating this, is that multi-core hardware is going to be available in the foreseeable future, and if RO is to progress, it will have to be developed to take advantage of that new hardware. In doing so, it will have to maintain backwards compatibility for old software for some time. This is, I think, one way of doing it, but if this solution is too complex, a different solution should be sought.

Like the one just proposed by bhtooefr. Would that allow RO to run on more than one core?

 is a RISC OS UserViking on 31/5/09 7:06AM
[ Reply | Permalink | Report ]

On First screenshot: Beagleboard runs RISC OS 5 desktop:

Killermike, the “API Layer” I propose IS a Virtual Machine. Some people spotted a couple of technical problems with your proposal, and this is intended to overcome those problems. My proposal is a fairly simple concept: Any program making a call to the OS uses an SWI instruction. The OS contains a decoding routine which generates an address from the SWI number. Changing that decode process to intercept calls that will cause compatibility problems and deal with the incompatibility, solves the problem. As far as the application is concerned, it is running on standard RISC OS, but the software on the other side of the API layer could be anything. There are some modules, such as BASIC and CLI which would have to be thought of as part of the API layer because applications are able to interface to them without SWIs. I don’t “think” there’s that much work to my proposal, but I can’t quantify it.

Like you, I don’t think a fully “multithreaded” OS is on the cards at this point, so the idea is to find a way to run two or more apps on additional cores. The software that sits under the API Layer can’t be RISC OS as we know it because it must include some multithreading just to schedule two or more cores.

I think you’re right about taking advantage of new graphics hardware, but if TI, Qualcomm and Freescale are all including graphics hardware on the chip, which one do you support?

 is a RISC OS UserViking on 30/5/09 2:35PM
[ Reply | Permalink | Report ]

On First screenshot: Beagleboard runs RISC OS 5 desktop:

Sorry, rjek.

How about you, Druck? Killermike’s idea is clearly technically possible, but is it just a pipedream? Is there just too much work in it? I’m not really bothered about the “Wimp_Poll” idea.

 is a RISC OS UserViking on 30/5/09 5:25AM
[ Reply | Permalink | Report ]

On First screenshot: Beagleboard runs RISC OS 5 desktop:

Rejk, I apologise for making you boggle. I am looking at this from a “computer science” point of view and I think you are looking at it from a C/C++ programming point of view. I wasn’t trying to teach you to suck eggs, I was pointing out that “fork” and “copy on write” are not synonymous. RISC OS does not need to do copy on write in order to fork, it just means that the memory will always be allocated, even if the child does nothing. I think you are looking at fork() as a C function, I am suggesting the CONCEPT can be applied to other problems. Similarly, I think you are looking at threads in terms of C/C++ library functions, so their implementation is invisible to you as a programmer. But for two threads to run on two processor cores, the kernel needs to be have allocated the cores to those threads.

Druck, I would have to dig out my old PRMs from the loft to answer your questions properly, but I’ll try to explain what I have in mind for now. There are two different concepts here. The first, forking, is a suggestion for a methodology to allow the OS to run existing application simultaneously by allocating separate applications to separate cores. The second, “Wimp_Poll idea” is a suggestion for 1:1 multithreading of an application.

With regard to the question, “how can you split the API from the OS?” Would it make any difference if I used the term “API layer”, meaning a layer of software which began at the API and reached to various extents within the OS? Depending on the modularity of the OS, this could simply mean putting one module in the API layer, and another outside. It might be possible to implement some features using pre and post filtering, and some features will have to be completely rewritten.

So, for example, if we were able to intercept the calls to enumerate a directory, and store the context within the API layer, we can work around the problem. If an SWI causes only the core it was issued on to switch context (and I think that must be so), then we can intercept any call we choose within the API layer.

As for the Wimp_Poll idea, getting one task to run on multiple cores would require some rewriting of applications. Given that much of the available software is no longer maintained by original authors, I think it might be worthwhile concentrating on a single, well understood, part of the application; the Wimp_Poll loop, and its associated data. In 1:1 multithreading, the OS is aware of all a task’s threads and schedules them directly. I can see that allowing two threads to simultaneously access the same object (a window, for example) could cause problems, but there are ways around that. You have already mentioned semaphores and mutexes. Semaphores could be implemented as global task data. Mutexes are a little more complicated, but perhaps event handlers which were related to a single object (eg codes 1-6 etc) could call some sort of locking routine before dropping into the existing code.

I’m not going to claim that either of these suggestions is the best way forward; It may be necessary to intercept every call to the OS in order to have a forked API layer (too costly). But if there is a shortage of resources to rewrite all the applications and all of the OS, I think any methodology would be worth considering.

 is a RISC OS UserViking on 29/5/09 4:30PM
[ Reply | Permalink | Report ]

On First screenshot: Beagleboard runs RISC OS 5 desktop:

rejk: "Other systems simply have a job dispatch thread; it would listen to Wimp_Poll, and dispatch jobs to handler threads. This is both simple, and good enough. "

Lovely! I assume you're talking about modifying the Wimp_Poll loop so that it schedules jobs with the kernel (rather than execute the event handler code directly), using semiphores to avoid races and deadlocks. In fact, in an object oriented environment, it seems a more elegant solution.

 is a RISC OS UserViking on 29/5/09 7:53AM
[ Reply | Permalink | Report ]

Search the archives

Today's featured article

  • Archive magazine reviewed
    A media watch special
     10 comments, latest by diomus on 27/10/07 12:01PM. Published: 23 Oct 2007

  • Random article

  • RISC OS for Linux Update: ROX-Filer 1.1.2 released

     Discuss this. Published: 2 Apr 2001

  • Useful links

    News and media:

    Top developers:
    RISCOS LtdRISC OS OpenMW SoftwareR-CompAdvantage SixVirtualAcorn

    CJE MicrosAPDLCastlea4X-AmpleLiquid SiliconWebmonster


    RISCOS.org.ukRISCOS.orgRISCOS.infoFilebaseChris Why's Acorn/RISC OS collectionNetSurf

    Non-RISC OS:
    The RegisterThe InquirerApple InsiderBBC NewsSky NewsGoogle Newsxkcddiodesign

    © 1999-2009 The Drobe Team. Some rights reserved, click here for more information
    Powered by MiniDrobeCMS, based on J4U | Statistics
    "I was going to say something then but I remembered you're a reporter. So I won't"
    Page generated in 0.1644 seconds.