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

Profile for dfeugey

ContactAbout me
Username: dfeugey
Realname: Feugey David
About me:
Comments posted:22 (show all)

Recent comments

On Imagining RISC OS and PMT:

> Errr, I'm quite sure you're mad. Real Time operating systems are *all* > about being predictable. If you think they're not predictable, that QNX > installation at your local nuclear power plant, or WindRiver VxWorks > in that cruise missile are in deep s***.

Not in the way you think... Soft RT will try to execute the task in the given time "else" it will finish the execution later. Hard RT will try to execute the task in the given time "else" it will simply refuse to make it run.

Of course if you have a small (10 ms average execution time) task to execute in a quite long time (1 s), you don't need such predicatable features : with a simple PMT system (and only a few tasks running), your small task will ever be able to run in the given time.

But I really dont call this a fully predicatable system :) So perhaps I'm not mad... after all...

 is a RISC OS Userdfeugey on 02/08/03 10:04AM
[ Reply | Permalink | Report ]

On Imagining RISC OS and PMT:

> Acorn clearly wanted PMT on their earlier machines, but kept failing trying.

Ah, but in kernel land we have preemption and reentrency (just to prove it, even with a fully frozen desktop, network and disc drive still work). So Acorn manage to make kernel level things with PMT, but not user applications ? They manage to make RISC iX with PMt but not ROS ?

Perhaps after all...

> The multiple model of which you speak is a little pointless - that's > exactly what priorities are for under PMT systems. (Or even > dynamically adapting priorities, like Linux's)

Ah no, you cannot make a predictable system with PMT. At the best you'll make a soft or a hard RT system... That's not 100% predicatable. Why do you think Montavista tried to put different schedulers inside Linux kernel ? :)

 is a RISC OS Userdfeugey on 30/07/03 5:08PM
[ Reply | Permalink | Report ]

On Imagining RISC OS and PMT:

>Please, stop the PMT FUD. For almost all purposes, it's a far superior > system, which most RISC OS users don't appear to fully understand. :(

I think, no offence, that you misunderstood my point. I just wanted to say that if Acorn did not choose this model it was probably because of the processing power overhead (too much probably to get the best of an ARM2).

Now if you want me to give my opinion for the future, that's clearly different. I don't want a "PMT only model" but a "multiple model". For example a PMT model for "desktop use" that can be blocked on the fly when you need more power for the only application you really use at that time (PAO, games, video). You can block it entirelly (fullscreen application) or just switch to CMT model (desktop application)... Of course for a multimedia API you could need also to have a RT model.

So keep and improve Wimp2 (for example with a function to stop all tasks, when a game is launched), rewrite desktop applications for it, integrate it in standard RISC OS Select or 5.0, but do not drop the CMT model. Just keep it for these specific applications (Ashiv or Pace ones). There is no overhead to have a an unused model inside the system. See the operating system as what it is : a toolbox, a massive API for applications. don't think, as Apple, that you can force people to adopt technologies... Just give choice.

Wimp2 is really the perfect idea IMHO (and I really wanted to have it by myself)... Don't make the Apple error : too much new technologies, too much processing power overhead and only 50% of users (and so developers) that switched to the new system (with 99% of them that switched back to MacOS 9 for games or emulation).

 is a RISC OS Userdfeugey on 30/07/03 09:17AM
[ Reply | Permalink | Report ]

On Future ARM based processors for RISC OS?:

I don't think the use of an embedded processor is a problem... There are many solutions to avoid the lack of performances : better software optimisation, assymetric multiprocessing support (check the 4 * ARM233 Simtec PCI card), good sales that mean that Castle could ask for a production line of ARM with "speed oriented transistors", etc.

Main problem is not to loose the focus : flexibility and optimisation. We see today that an R7500 has good performances, but we could make a better draw for it by using the FPU. In the PC world this idea cannot be applied but here people keep their computer a lot of years, so optimisation is really the way to get more performances.

a 20% speed up on Wimp is really better than to switch from a P4 2.0 GHz to a 2,4 GHz one... Other example : my PC card was really faster than my current (and as much pricey) VPC on Mac. thanks to the excellent PCPro driver. ARM computers has a strenght : best performances for the power. More power would be good, but never forget our performance/power advantage. If you do so, ARM computers will become a PC or a Mac and will - IMHO - die.

 is a RISC OS Userdfeugey on 29/07/03 10:19AM
[ Reply | Permalink | Report ]

Search the archives

Today's featured article

  • South East 2007 show report
    News, views, gossip and photos
     35 comments, latest by Pete on 06/10/08 10:51AM. Published: 20 Oct 2007

  • Random article

  • Got Omega?
    Will the real deposit holders please stand up
     15 comments, latest by sandt on 15/6/03 11:53AM. Published: 29 May 2003

  • 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
    "Well, if you will use these complicated words, how can you expect us lowly RISC OS users to follow?"
    Page generated in 0.1448 seconds.