Writing a new co-pro that is a JIT

[zolbatar]

If I want to write a new co-pro (in this case to run WASM) and want to JIT some code, then I need to write the machine code to an area of memory that has the execute bit set.

Looking at the code for the 6502 JIT, it seems if I write to 0x0C100000 onwards (JITTEDTABLE16), then that is remapped already to allow executing.

BUT...it just locks and doesn't run. Do I need to do some other sort of magic to get this to work?

[dp111]

You shouldn't have to do anything special. Show us your code.

On Wed, 19 Oct 2022 at 16:33, Daryl Dudey @.***> wrote:

If I want to write a new co-pro (in this case to run WASM) and want to JIT some code, then I need to write the machine code to an area of memory that has the execute bit set.

Looking at the code for the 6502 JIT, it seems if I write to 0x0C100000 onwards (JITTEDTABLE16), then that is remapped already to allow executing.

BUT...it just locks and doesn't run. Do I need to do some other sort of magic to get this to work?

— Reply to this email directly, view it on GitHub https://github.com/hoglet67/PiTubeDirect/issues/164, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEVVFIVH5ZJ5PX3GMJ77H4DWEAIEPANCNFSM6AAAAAARJIBJRM . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[zolbatar]

My code works when I create it as an executable to run under the Native ARM co-pro, but not when I create this new co-pro. I wonder if some initialisation is occurring in the native co-pro, I'll take a look at that first.

Happy to share any and all code.

I use GNU Lightning to generate the ARM code, and I have an embedded disassembler which show sensible code as well.

[dp111]

Mostly likely an exception is being raised. If you have a debug build and the UART connected it will dump the the registers if an exception is raised. Also if this is self modifying code ie you have just created it at runtime, don't forget to flush the caches.

On Wed, 19 Oct 2022, 17:18 Daryl Dudey, @.***> wrote:

My code works when I create it as an executable to run under the Native ARM co-pro, but not when I create this new co-pro. I wonder if some initialisation is occurring in the native co-pro, I'll take a look at that first.

Happy to share any and all code.

— Reply to this email directly, view it on GitHub https://github.com/hoglet67/PiTubeDirect/issues/164#issuecomment-1284265254, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEVVFIVXARMA5JKXEXGXJMLWEANLTANCNFSM6AAAAAARJIBJRM . You are receiving this because you commented.Message ID: @.***>

[zolbatar]

A flush of the caches does something, but it's still not working correctly and locks up.

I think a better approach might be to create my "Arm native" executable and compile it in in the same way that ARMBASIC is. I can add an additional *command to execute it. This avoids me having to worry about setting things up properly.

[hoglet67]

When you execute your code using a star command several things happen (in _user_exec in copro-armnativeasm.S)

• the entire data cache is flushed and invalidated
• the entire instruction cache is invalidated
• FIQ and IRQ interrupts are enabled
• the ARM processor state is changed to user mode

So depending on what your code does, it may be directly or indirectly relying on one of these things.

[zolbatar]

Thanks guys, the advice was useful. What I've decided to do instead is copy the same process as is done for ARMBASIC. I compile my executable to run at 0x0C400000 (just below BASIC), and then copy into ram and jump into on a *DARIC when using the ARM Native co-pro.

It runs almost immediately and successfully JIT compiles some WASM to ARM machine code.

I suspect I was needing one of the things above, but rather than muddy the waters with another co-pro, this approach is cleaner and achieves the same result.

[zolbatar]

Can I force:

• the entire data cache is flushed and invalidated
• the entire instruction cache is invalidated

From a program loaded and run inside the ARM native co-pro? Some odd behaviour makes me think it's trying to read/execute some previous values.

Maybe an SWI I can call? I appreciate what I'm doing here is a bit hardcore...

[hoglet67]

Maybe an SWI I can call? I appreciate what I'm doing here is a bit hardcore...

Yes there is:

SWI OS_SynchroniseCodeAreas (&6E) does exactly this (same as in RISCOS).

Dave

[zolbatar]

Of course! I totally forgot and I should really have searched that up.

Works perfectly now, thank you!

Daryl.