Supporting Appspace limits under the JIT

Discuss development specific to the Pi version of ADFFS
Post Reply
JonAbbott
Posts: 2938
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex
Contact:

Supporting Appspace limits under the JIT

Post by JonAbbott »

Some background points:
  1. The Appspace limit under RISC OS is:
    • RISC OS 3.11, the physical limit of RAM is 16MB. That aside the logical limit for Appspace is 1800000 which is the start of the RMA - 24544KB
    • RISC OS 3.50 - 28640K
  2. For ADFFS to trap chipset memory accesses, memory has to be unmapped between 3200000-4000000
  3. To support VIDC1 video memory, memory must not be mapped between 1F88000-2078000
  4. Exit points back into 32bit land have to be below the 26bit limit of 4000000 (or trapped by CPU Paravirtualization)
  5. Cursor/Sound buffer space must be mapped in at 1F03000-1F08000
  6. The 26bit RMA must be below 4000000
  7. B/BL have a +-32MB limit, so codelets must be within this jump range of the JIT'd code
  8. Appspace and the RMA are duplicated for JIT'd code space
  9. Branches in the hardware vectors must branch to an address above Appspace (code may assume a +ve jump address - Lotus Turbo Challenge 2 for example)
  10. Codelets must be within branch range of all JIT'd code (ie +-32MB / +-2000000)
With the current JIT implementation, the theoretical appspace limit is ~13MB with 2MB for codelets and 1.5MB for the RMA (((1F00000-2MB-1.5MB*2)/2-8000)=CF8000=12.96MB). Everything has to remain below the start of the Cursor/Sound buffer space at 1F03000 (actually 1F00000 as its rounded down to nearest MB). This means Appspace from the host OS perspective has a fixed end address of 1F08000 (sound buffers have to be mapped) regardless of what the app wants - ADFFS tracks Appspace so the guest app sees the correct memory size it allocated via WimpSlot.

To remove the current limit the JIT code/codelets need to move to a DA, with 26bit exit points in Appspace (ie below the 26bit address limit). To support multiple VM's the JIT DA also needs to switch as Appspace is task switched.

Codelets will need modifying so they reference the DA address and the codelets themselves moved within Branch range of the DA. ie at a reserved block at the start of the DA.

Virtualizing pre RISC OS 3.5:
The RMA could remain at it's original location of 1800000, or move lower to 1000000 so it's with branch range of codelets.

Virtualizing RISC OS 3.5 thru RISC OS 4.x
As screen remapping isn't required, the original RMA address of 2100000 could be used. It could also be relocated lower, to the 28640KB Appspace limit. ie. 1C00000

At 1C00000 the RMA would need a dedicated codelet area above the DA, so codelets are within branch range. The codelet areas would also need increasing to cope with the additional codelets that will be created for larger software (~10% of instructions require codelets)

Exit points back into 32bit land
Currently these rely on a block of 32bit code at the top of Appspace. A better solution might be to have a block of 32 bit code in the JIT's Page Zero, where there's no conflict with OS values. (as of 2.71l this has been implemented for 26bit returns. Hardware vector 26bit entries have moved to just above the RMA as they have to be high)

Environment handlers need relocating from codelet space to be below jit_code_start. ie moved to the top of the 26bit RMA.


Memory map in the VM (RO3.11)

Key:
Unmapped memory
PMP memory
Mapped memory
.
00000000-00004000Unmapped
00004000-00008000Scratch space
00008000-01000000Application space
01000000-01800000RMA
01800000-01F0000026bit exit points
01F00000-01F0600026bit SWI dispatch, Cursor
01F06000-01F08000Sound buffers
01F88000-02078000Remapped video memory
03200000-03300000IOC
03400000-03600000VIDC
03600000-03700000MEMC
---------------
DA- 00800000-00000000Codelet space
DA+ 00000000-00004000Page Zero
DA+ 00004000-00008000Scratch space 32bit code
DA+ 00008000-01000000Application space 32bit code
DA+ 01000000-01800000RMA 32bit code
DA+ 01800000-01F0000032bit exit points
DA+ 01F00000-01F0400032bit SWI dispatch
Post Reply