Upgrade for RiscLua 5.70 on the RPi2

You can download an upgrade for RiscLua 5.70, on the Raspberry Pi 2 only, from http://www.wra1th.plus.com/lua/risclua.html .
It provides integer division (/) and remainder (%)
using the Cortex-A7’s SDIV and UDIV instructions. This reduces the time taken by these operations in RiscLua by 56%.

Drag the upgrade over a copy of !lua to get an RPi2-optimized version, but be careful not to use it on systems that do not use the Cortex-A7, such as the earlier Raspberry Pi.

Hmm, perhaps we could do with a tutorial (or library?) on how to correctly detect CPU/FPU features. Then at the least it should be able to pop up an error saying “sorry, I don’t run on this CPU”.

sorry I don’t run on this CPU.

Here is a little BASIC program that will tell you if your computer is OK for the upgrade for RiscLua. It is very specialized. A general feature-detector would be a much bigger beast.

ON ERROR PRINT REPORT$;" at line ";ERL:END
DIM code% 31
FOR pass%=16 TO 18 STEP2
 P%=code%
 [ OPTpass%
 .code
 MRS R12,CPSR
 SWI "OS_EnterOS"
 MRC CP15,0,R0,C0,C2,0
 STR R0,q
 MSR CPSR_c,R12
 MOV R0,R0
 MOV PC,R14
 .q
 EQUD 0
 ]
NEXT
CALL code
IF ((!q>>24)AND&F) = 2 THEN
 PRINT "OK to upgrade"
ELSE
 PRINT "Your CPU does not support SDIV and UDIV."
ENDIF
END 

As an alternative, you could ask the HAL? After determining the CPU type, the Pi revisions field is thus.

Here is some code I have to detect running on a Pi, as a certain API feature gets messed up in interesting ways on the Pi (and only the Pi) if probing is attempted. So, I detect this.

        ; We need a Platform class of 5 (HAL) at least.
        MOV      R0, #8
        SWI      XOS_ReadSysInfo
        BVS      do_hardware_error           ; code 8 failed? Give up
        CMP      R0, #5
        BNE      do_hardware_error           ; not HAL version of RISC OS? Give up

        ; Now ask the OS (via HAL) to confirm what sort of platform this is
        MOV      R0, #1024                   ; HALDeviceType_Comms
        ADD      R0, R0, #3                  ; HALDeviceComms_GPIO
        MOV      R1, #0                      ; is our first call (to enum)
        MOV      R8, #4
        SWI      XOS_Hardware                ; OS_Hardware 4 - enumerate devices
        BVS      do_hardware_error           ; Failed? Give up!

        CMP      R1, #-1                     ; No match for this device type?
        BEQ      do_hardware_error           ; If no match, give up!

        ; *BAD* things happen if we probe on a Pi. So don't do it!
        LDRB     R0, [R2, #2]                ; processor type
        CMP      R0, #2                      ; 0=OMAP3, 1=OMAP4, 2=BCM283x(Pi)
        STREQ    R0, [R12, #THIS_IS_A_PI]    ; If it looks like a Pi, flag it's a Pi.

This works by looking to see if the processor type is ‘2’ (BCM blah blah). If so, you’ll need to probe the board type (returned in offset +64 or +68 (I forget which) – do LDR R0,[R2,#64] at the end to load the first word) to determine the board features.

This stuff really really ought to be a simple OS_ReadSysInfo call…

Hmm, perhaps I should have said “how to properly detect” instead of “correctly”. Or made it 40pt bold flashing text.

Gavin’s on the right track (check the CP15 instruction set feature registers), but falls a bit short because it doesn’t check to make sure the feature registers exist.

However Rick’s method is much worse because it checks against a hardcoded list of known hardware, meaning that it’s guaranteed to fail on all new machines.

I am in awe of those who can mess with this stuff. I formulated the BASIC program above by looking at http://infocenter.arm.com/help/topic/com.arm.doc.ddi0464f/BABCIIJC.html .
These ARM manuals, full of impenetrable acronyms, might as well be written in Akkadian cuneiform to me. I need not just manuals but gentle tutorials, or, better yet, somebody of whom I can ask naive questions.

I suppose it is a question of experience. But it would be nice to be able to ask why? occasionally. I wonder if there is any mileage in hearing a manual spoken aloud? set to music? interpreted in dance? Dame Millicent will now sing excerpts from the chapter on the Window Manager from Vol III of the RISC OS PRMs, accompanied by the massed choirs of several notable usergroups .

Or made it 40pt bold flashing text.

That can be done. Use styles. ;-)

Gavin’s on the right track (check the CP15 instruction set feature registers),

For his needs, yes. He requires a specific processor feature.

However Rick’s method is much worse because it checks against a hardcoded list of known hardware,

Given that the Pi IIC breaks if you try sending requests to invalid IIC buses (result: system configuration reverts to defaults and cannot be altered (until system rebooted)), all I needed to know was “it’s a Pi”. I use the processor type for this as when I wrote the code we already had four different types (old B, new B, A, module).

The alternative is what, exactly? Poke around looking for certain modules like BCMVideo? Can you say that will never change?

meaning that it’s guaranteed to fail on all new machines.

Because Acorn made their own machines and their own OS, the system is actually rather bad at identifying itself. OS_ReadSysInfo should be able to tell you the machine type; and Gavin’s information should be somewhere in OS_PlatformFeatures (if I remembered the name correctly).

Machine type and processor capabilities ought to be a SWI call away, not this complicated.

This stuff really really ought to be a simple OS_ReadSysInfo call…

Totally agree, there should be an agreed CPUID list and an OS_ReadSysInfo call to retrieve the current CPUID.

The code I use in ADFFS is as follows (untested on OMAP, Pi2 etc). PXA and Iyonix complicate things somewhat as their ID’s are lower, so I add &1000 so <>StrongARM comparisons still work.

CPUID – CPU type
3 – ARM3
610-810 – ARMxxx
A10 – SA-110
A11 – SA-1100
12C3 – Intel 80321
1411 – Intel PXA270/272
1B76 – Pi ARM11

 STMFD   R13!, {R0-R6, R14}

 MRC     P15, 0, R0, C0, C0

 AND     R1, R0, #&FF00
 TEQ     R1, #&300			;ARM3
 MOVEQ   R2, #3
 BEQ     _exit

 AND     R3, R0, #&00F0			;Add extra bits in for higher processors
 ORR     R1, R1, R3

 TEQ     R1, #&600			;ARM600
 TEQNE   R1, #&610			;ARM610
 TEQNE   R1, #&620			;ARM620
 MOVEQ   R2, R1
 BEQ     _exit

 TEQ     R1, #&7000			;ARM700
 TEQNE   R1, #&7100			;ARM710
 TEQNE   R1, #&8100			;ARM810
 TEQNE   R1, #&A100			;SA-110
 MOVNE   R6, #&A110			;SA-1100
 TEQNE   R1, R6
 MOV     R2, R1, LSR #4
 ADDNE   R2, R2, #&1000

 ._exit
 STR     R2, cpu_id			;store the cpu id
LDMFD   R13!, {R0-R6, PC}

.cpuid DCD 0

Given that the Pi IIC breaks if you try sending requests to invalid IIC buses (result: system configuration reverts to defaults and cannot be altered (until system rebooted)), all I needed to know was “it’s a Pi”. I use the processor type for this as when I wrote the code we already had four different types (old B, new B, A, module).

The alternative is what, exactly? Poke around looking for certain modules like BCMVideo? Can you say that will never change?

The alternative would have been to realise that providing example code for detecting buggy OS versions is somewhat off-topic from a discussion about detecting CPU features, and to have kept your trap shut ;-)

More seriously though, have you submitted a bug report for that IIC issue? It sounds like a pretty serious bug, and one that should be pretty easy to fix. Remember that we can’t be relied upon to fix bugs if we don’t know that they exist!