Thank you all for your great advices. Since you all vote for the same option, I now know that I have a huge and long work ahead of me! And this, for peanuts as I will never make a living thanks to my iziBasic sales...

Here are a few additional thoughts (It's always better to think a lot before starting anything too fast!).


Development length

Indeed, moving iziBasic to the brand new NaPP, which was just released and therefore is in high debug phase, will be long taking.
The initial work on iziBasic took me almost one year... this gives you an idea of how long you would have to wait before getting some operating iziBasic/ARM for your use.

=> Would you wait so long?


Compatibility with older devices

Would the arm only version of iziBasic be able to produce apps that are targeted at non-arm devices?

This is a very good question dear bh77a.
And the answer is yes, potentially.

As iziBasic compiles into a p-code which is then interpreted in a runtime engine, the two stages could very well be separated:
1. compile into a p-code
2. package a 68k runtime or an ARM runtime in the application, according to a developer's choice (some compiling directive would make it)

The difficulty here is that it wouldn't be just compiling iziBasic's runtime with PP/68k and then with NaPP/ARM and getting quickly the 2 runtimes. Because of the 68k limitations and the great capabilities of the ARM mode of NaPP, I would still have to maintain 2 versions of the runtime engine.

=> Then, would you believe that delivering a 68k runtime that would work for up to a version 6.x of iziBasic and an ARM runtime that would for >=7.x versions could be an acceptable option?


Working on iziBasic's current limitations

As iziBasic was my first real attempt to develop such kind of a p-code compiler, there are some limitations which appear to be annoying due to my lack of knowledge when I wrote the Basic syntax parser.
The main one, for sure, being that one needs to write code like:
A=3*B : IF A>6 THEN (do something)
when someone would most probably want to write:
IF 3*B>6 THEN (do something)
Same thing (for the same reason) with things like:
A=3*B : A=COS(A)
instead of:
A=COS(3*B)

=> As from your experience, are there other real blocking points? (even though the one I mentioned above is not blocking, it just requires to split some pieces of code to single operations, I personally like it, others don't...)


iziBasic functional extension

PP applets are a great offer in the current iziBasic, to extend its usability in the areas it does not cover, since, by design (a runtime engine and not a real compilation) it does not offer access to the Palm OS APIs.
My current understanding is that we would not get this possibility with NaPP.

=> So, the question is: would you go for a features closed iziBasic (without PP applets)? ... even though I think that you will agree that its features' set is quite close to 100% of any standard functional coverage.

On my side, the answer is that I won't start coding the new iziBasic/ARM until I find a way to give access to all Palm OS APIs.
So, this is a topic I have to address with Philippe Guillot (PP and NaPP's developer) before going ahead.


Other thoughts

Any other idea on your side will be more than welcome!


Cheers,
aldweb