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

Reply to thread

> the build of RISC OS has to be different to cope with difference within the CPU itself?

Correct. The differences are as follows (note: may not be a complete list!) * The MMU and cache handling code in the kernel needed updating to handle the new MMU & cache type used by the Cortex. The MMU and cache differences shouldn't affect any well-behaved programs. * Changes in the way LDR/LDM/STR/STM handle non-word aligned data loads/stores has the potential to affect many programs. So far a few OS modules have been changed, but I suspect 90% of software (espeically that written in C) will continue to work as normal. * Finally there's VFPU support. If a program wants to make use of the hardware floating point, the easiest/best way of doing that is likely to be to recompile it (once the relevant compiler gains support for the VFP instruction set). There's the other non-easy way of modifying the FPEmulator to map old FPU instructions to new VFPU instructions, but that will be a hard (if not impossible) task and won't provide as good performance as a recompiled program would provide. * There have also been a couple of non-32bit compatible pieces of assembler I've found in the OS that previously used to work fine but have now started to fall over. I'm not sure of the exact reason for this, but I doubt it's going to affect any other software (due to the size of the OS it was inevitable that a few bits here and there would fall through the cracks)

So although I haven't actually tried any 3rd party software yet, I believe that most, if not all well-behaved 32bit compatible software will continue to run without a hitch. Then once compiler support for VFP is available, software authors can begin to recompile their code to take advantage of the speed benefit.

Of course there's also the issue of backwards-compatability with machines that lack VFP - this will likely be handled with a new FPEmulator, or just having two different executables (which could be quite attractive now that GCC has software floating point, giving much better performance than FPEmulator on non-FP hardware)

> Which compiler is being used? Acorn C/C++ or GCC I thought the RISC OS sources required Acorn C/C++ I didn't think it had been updated for Cortex-A8 support!

The ROOL sources are still tied to Acorn C/C++, but I believe efforts are underway to improve the source (mainly in the build system and makefiles) to allow GCC to be used (either natively or with the cross-compiler). And I'm sure that both ROOL and the GCCSDK team will welcome any help that people can provide to update the Acorn/GCC compilers to support the new CPU instructions!

 is a RISC OS UserPhlamethrower on 12/5/09 1:32PM
[ 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

  • A9home DIY laptop: first pictures
    And other odds and sods from the Christmas 2007 show
     22 comments, latest by sa110 on 1/6/08 4:47PM. Published: 1 Dec 2007

  • Random article

  • LCC update
    C compiler tweaks and a RISC OS state-of-affairs diary
     4 comments, latest by ian on 14/6/02 8:36AM. Published: 4 Jun 2002

  • 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
    ""
    Page generated in 0.0698 seconds.