Overlays are unsupported (JIT) or uninitialized = ?

[Jonne Valola]

Hello All

I ran across Pawn and this forum this weekend and decided to try it out.

So far I have a chinese Haoyu (from ebay) LPC1768 dev board reading an AMX file from an sd-card, amx file headers etc seem to work.

But: I get result "Overlays are unsupported (JIT) or uninitialized." (error 22) for aux_LoadProgram.

Could someone please elaborate the meaning of this ?

I've been looking at JPA's QuadPawn and Tylers' version for the mbed, but I've had to modify the code quite a bit because I'm working with Keil (no variable declarations after executable code in functions and other Keil funkiness)

Cheers !
 

[petteri...@gmail.com]

Hi,

> But: I get result "Overlays are unsupported (JIT) or uninitialized." (error
> 22) for aux_LoadProgram.
>
> Could someone please elaborate the meaning of this ?

This means that the .amx file uses overlays (code swapping), but the
interpreter you have compiled does not support it. Try disabling the
overlays in the compiler (remove any -V switch).

--
Petteri

[Jonne Valola]

Hi Petteri, and thank you for the reply.

I'd like to ask a few more q's but before that a bit about what I'm aiming at:

I was making UI's in C (for my own projects) but it was slow to change C code and then recompile every time the UI design changed. Then I used XML files to decribe the UI flow, but that was too restrictive: any time there was a need for special functionality, I had to change the C-code again. Then I looked at Lua, but its (funny to say this) a bit too heavy. And finally I ran across the Pawn language - of which I knew nothing about before this. Really like the C-like syntax and its suitability for a FSM-kind of application.

I'm struggling to understand this overlay business, and the documentation on the subject is a bit bare. Is it so that the interpreter must be compiled specifically for either overlay or non-overlay compatibility ? I.e. is it not possible to compile an interpreter that understands both ?

Might be a bit dumb question, but I only started looking at this on saturday.

By the way, I really like the software you've written for the QuadDSO ... almost makes me want to buy one ! ;-)



 

[petteri...@gmail.com]

Hi,

> Then I looked at Lua, but its (funny to say this) a bit too heavy.

Indeed, it is. I wouldn't use it with less than 100 kB of RAM. Squirrel
is marginally lighter than Lua, but not by much.

> Really like the C-like syntax and its suitability for a FSM-kind of
> application.

These are really nice features. The biggest limitation for me has been
the lack of function pointers, which makes it difficult to do some
callback style things.

> I'm struggling to understand this overlay business, and the documentation
> on the subject is a bit bare. Is it so that the interpreter must be
> compiled specifically for either overlay or non-overlay compatibility ?
> I.e. is it not possible to compile an interpreter that understands both ?

If the interpreter has overlay support, it will understand also
non-overlay files. The thing is just that you need to provide a few more
callback functions to handle overlays. I think the Pawn implementers
manual has information on it, also you can find my implementation in
QuadPawn.

I suggest getting non-overlay case working first and then moving on to
add overlay support if you are very short on RAM.

> By the way, I really like the software you've written for the QuadDSO ...
> almost makes me want to buy one ! ;-)

Go ahead, then I can offload some development to you :)

--
Petteri

[Jonne Valola]

It works !

Couldn't get the QuadDSO code to work though => too many hw-specific features, would have had to go through the whole thing. Wrote from scratch using the mbed version and the implementers guide.

My dev board has a 320x240 tft screen. Maybe I'll make my gfx lib compatible with the DSO libs, so that you'll get some proper software to run = tetris !

But, all in all, looks very promising.

[mat henshall]

These are really nice features. The biggest limitation for me has been
the lack of function pointers, which makes it difficult to do some
callback style things.

I second that - Anyone interested in forking pawn and adding that as a feature?

m

--

Mat Henshall
Founder and CEO, Square Connect, Inc.
San Jose, CA
www.squareconnect.com
cell: 650.814.7585

[Bach Le]

I just checked Pawn out recently. I think this is a very important feature. Currently, the closest Pawn has to a function pointer is public function. It's possible to grab the function index by name and call it.
I think it is possible to implement it without changing the VM. Some compile-time code generation may be required.