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

Reply to thread

OK, thanks Julian. Just the way you said it made me think there were much faster chips we just couldn't use.

Personally I'd rather not go the emulation->multicompiled->x86 route. Perhaps it is just because of the legacy instruction set. A system-independent OS is another matter, and perhaps that is the best route to getting there, but I'd prefer an efficient chip for my own use, at least.

Perhaps I can suggest an alternative path to fast ROS on ARM, in the absence of faster chips? ROS has the advantage that it doesn't actually need that much power for its own use - we really only need more for power-hungry apps and funky stuff. I mentioned at the end of the article-proper comments that multiple chips could be used, and Gulli correctly pointed out that ROS as it stands would need a lot of re-writing before it would work on them. But why do that? You don't have to initially. Have ROS running on one. Then have each of the others receive tasks which need a lot of processing. I'm not well-up on parallel processing architectures, but since I'm assuming they will get dedicated to particular tasks, suppose each one had its own private memory. They also need to be able to communicate. I know even less about this, but since the Iyonix has a GPU it is obviously possible somehow. So what software would we need? I don't think it is that much (compared to rewriting ROS as pre-emptive). As I see it, you'd want SWI calls for the main system to send blocks of data to and from the 'fingers', and perhaps make them able to create interrupts in each other. You'd also need a system for apps to find out what resources were available Each finger would need a BIOS so it could collect the initial data, and twiddle itself while it was waiting for something to do.

The big advantage of this is that (besides the hardware engineering and boot-straps), it doesn't have to all be done at once. As ROS evolves, it can delegate parts of itself to the fingers. But any apps with intensive calculations would be developed in parallel, and could then of-load the bulk of the processing to one or more fingers. Creating an archive, for example, needn't put up the hourglass. Artworks2 could spread the rendering load over as many fingers as were present.

Of course the fingers don't have to be perfectly symmetrical. For example, one could hold the frame-buffer, essentially replacing the GPU. (Yes, I know, support chips would be needed). This would have several advantages. There would probably be a cost saving, and all the power of the chip could be used since there wouldn't be a proprietary driver. Also, programmers could use the base of knowledge they already have.

 is a RISC OS UserLoris on 04/04/06 12:30AM
[ Reply | Permalink | Report ]

Please login before posting a comment. Use the form on the right to do so or create a free account.

Search the archives

Today's featured article

  • An introduction to IP networks
    Part one of masking the 'net
     10 comments, latest by Umair on 9/9/04 10:11PM. Published: 4 Sep 2004

  • Random article

  • Software news
    Playback controls in KinoAmp, DigitalCD updates plus more [Updated 08:16 2/4/2003] And even more
     6 comments, latest by ribbit on 1/4/03 10:11PM. Published: 31 Mar 2003

  • Useful links

    News and media:
    IconbarMyRISCOSArcSiteRISCOScodeANSC.S.A.AnnounceArchiveQercusRiscWorldDrag'n'DropGAG-News

    Top developers:
    RISCOS LtdRISC OS OpenMW SoftwareR-CompAdvantage SixVirtualAcorn

    Dealers:
    CJE MicrosAPDLCastlea4X-AmpleLiquid SiliconWebmonster

    Usergroups:
    WROCCRONENKACCIRUGSASAUGROUGOLRONWUGMUGWAUGGAGRISCOS.be

    Useful:
    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 made the assumption, though I should have known better in view of previous experience, that the article was factual"
    Page generated in 0.069 seconds.