|
 - Forum
 - iziBasic
Warning: A non-numeric value encountered in /web5/aldweb/www/aldweb_com/www/thread.php on line 257
 Topic # 1483 |
Recompiling iziBasic with new PP compiler? |
18/11/2006 @ 11:52
by Dave O\'Brien
|
aldweb,
Just noticed over at ppcompiler.org that the much-anticipated native version of the PP compiler (NaPP) has been released.
Just in case you didn't have enough demands from us ;^D, would it be worthwhile to port iziBasic to the new compiler?
I assume this would mean that the ported iziBasic would only work on PalmOS 5 devices. On the other hand, might yield a good speed bump.
Have you had a chance to play with it yet? |
|
|
|
Warning: A non-numeric value encountered in /web5/aldweb/www/aldweb_com/www/thread.php on line 497
Answer n° 1
--------
19/11/2006 @ 18:25
by aldweb
visitor
|
Hello Dave,
Yes, I am well aware of the new NaPP release. I even played with it and released a news here on October 17th about NaPP's performance in my Bench2 analysis.
The speed bump would not be good, it would be excellent if iziBasic was ported to NaPP. The counterpart would that it would then only work with ARM devices.
To tell the whole truth, I have been waiting for NaPP before evaluating which of the 2 options I would take for iziBasic:
1. either implement an ARM engine for the runtime together with the current 68k one, for calculations and main statements (if/then/else/endif, for/next, while/wend and a few others),
2. or port iziBasic to NaPP only.
For sure, I don't feel like maintaining 2 branches for iziBasic, that would be too much work. In the case option #2 was chosen, iziBasic would just be enhanced to a version 6.1 and, starting with version 7.0 and adequate enhancements, it would be ARM only. Option #2 would also require a huge rewrite of iziBasic. And, since NaPP is quite new, a resulting working version would not be obtained before months from now.
What would you people believe is best for the future of iziBasic?
Cheers,
@+
aldweb |
|
|
Warning: A non-numeric value encountered in /web5/aldweb/www/aldweb_com/www/thread.php on line 497
Answer n° 2
--------
19/11/2006 @ 19:18
by TomA
visitor
|
Hum... good question ! 
If some people use iziBasic with non-ARM devices, they will not be able to use iziBasic if you choose the second option... 
It's not a problem for me, I have an ARM device, but I think about people who have n't an ARM device.
So I vote for first option ! 
Bye !
TomA. |
|
|
|
Warning: A non-numeric value encountered in /web5/aldweb/www/aldweb_com/www/thread.php on line 497
Answer n° 3
--------
20/11/2006 @ 10:02
by Garfield
visitor
|
This is a tough one that would need some thought.
On the one hand I agree that it wouldn't be nice for those users with non-Arm devices to not have any further development. However, having said that, these sorts of arguments have impeded progress in software in the past.
If you look at it with brutal honesty, moving to NaPP is the way to go for the future of iziBasic. It will take months (maybe even a year or more?) to redevelop iziBasic with NaPP, and you have to consider what the market will be like at that time. There will probably be less non-Arm devices around than there are now. Also, prices keep on dropping and by that time I would have thought there would be no excuse to not have an Arm device! 
Also, if you talk about the future of iziBasic, then which is easier to develop further - non-Arm version with Arm applets or full Arm version?
It's not as if the non-Arm users will be left without iziBasic. The current version is very stable and works fine. However, as with computers and software in general, if you want more you will have to keep up with the times.
Even Microsoft is realising this and has stopped supporting Windows98 & ME. Also, if you want to upgrade from Windows98 to WindowsXP (or Vista now) you need a more powerful computer. This is the same with other packages that require more and more power. These things have to happen at some point if progress is to be made. It would be nice to be able to write rather faster games with iziBasic which can't be done now.
iziBasic is now a mature product in its current form. If Aldweb is now willing to put in the time to redevelop it, then I believe he should go the whole way, otherwise he will find himself in this situation again much sooner.
One could also consider what Palmsource (now Access) are doing. If the Palm operating system becomes Linux based, will NaPP be ported to allow iziBasic to simply be recompiled? If this is so, then iziBasic has to become completely Arm based to survive the change.
Hope this has provided some food for thought. 
Thanks.
|
|
|
|
Warning: A non-numeric value encountered in /web5/aldweb/www/aldweb_com/www/thread.php on line 497
Answer n° 4
--------
20/11/2006 @ 20:46
by speedan
visitor
|
Hello Aldweb,
iziBasic deserves the best. It gave us so much pleasure, and a reason to buy Palm devices.
I vote for option #2, for christmas sake.
Good night everybody. |
|
|
|
Warning: A non-numeric value encountered in /web5/aldweb/www/aldweb_com/www/thread.php on line 497
Answer n° 5
--------
21/11/2006 @ 19:13
by Dave O\'Brien
visitor
|
Given limited time and effort, I think you're right - you have to make a choice.
What's the majority of your current users using? That's the big question, I think.
My take:
Old (pre-OS5) Palm devices have a solid tool in iziBasic 6.0. Beyond bug fixes, I wouldn't invest more in those legacy devices if it means holding back the current OS5 devices (and future ones).
I suspect that your new users will be largely OS5-based, and will want speed and a feature set that is easier to deliver under a native OS5 system like NaPP.
Plus, what would you rather work on - old legacy stuff or new flashy stuff? ;^D |
|
|
|
Warning: A non-numeric value encountered in /web5/aldweb/www/aldweb_com/www/thread.php on line 497
Answer n° 6
--------
22/11/2006 @ 03:04
by bh77a
visitor
|
Good topic. My vote is for the second option, compiling with NaPP for arm only devices. While this does present the issue of some users being left without, I feel that it is the way to go.
Would the arm only version of iziBasic be able to produce apps that are targeted at non-arm devices? |
|
|
|
Warning: A non-numeric value encountered in /web5/aldweb/www/aldweb_com/www/thread.php on line 497
Answer n° 7
--------
22/11/2006 @ 12:51
by Garfield
visitor
|
This is a good issue that bh77a has brought up.
1. Are you looking at simply compiling iziBasic in NaPP so that, although iziBasic itself will only work on Arm devices, the programs it produces are the same as they are now and will work on non-Arm devices?
2. Or are you looking at going the whole way so that even the programs that iziBasic itself compiles are fast, Arm-only apps?
For some reason I have been assuming the second option here, but the first is quite possible.
I'm sure the eagerness that we all have is for the first option! It would be good to be able to produce fast games! My floodfill routine would also be very quick!
|
|
|
|
Warning: A non-numeric value encountered in /web5/aldweb/www/aldweb_com/www/thread.php on line 497
Answer n° 8
--------
22/11/2006 @ 18:59
by aldweb
visitor
|
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
|
|
|
|
Warning: A non-numeric value encountered in /web5/aldweb/www/aldweb_com/www/thread.php on line 497
Answer n° 9
--------
23/11/2006 @ 15:33
by Garfield
visitor
|
Hi Aldweb
In answer to your questions:
=> Would you wait so long?
Yes, definitely.
It's not as if we have nothing at the moment. We currently have the existing version of iziBasic which serves our purposes. Knowing that we will have a very upgraded version in development simply gives us the security to continue to support iziBasic today. With the Wiki progressing and the support from all the current members, I see no reason why anyone would want to drop iziBasic over the next year.
If I believed that iziBasic had hit the end and there would be no further development then I would start to look for another platform, no matter how good I felt iziBasic was. There is a lot of development that is needed (you are highlighting some yourself in your next questions) and I wouldn't be happy if these would never be tackled one day.
=> 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?
Yes. This is pretty much the opinion I expressed in my posting above. I don't believe it should be necessary to continue supporting 68k for much more. By the time you have completed version 7.x I wouldn't have thought there would be many 68k models left. Also, prices would have come down even more by then and I can't see any good reason to not have an Arm device if you want one.
=> As from your experience, are there other real blocking points?
Yes.
Multi-dimensional arrays come to mind, as well as the limited size of the stack which prevents the dimensioning of any decent sized multi-dimensional arrays. I would hope that if we are aiming at Arm devices we can increase the stack substantially, or perhaps iziBasic can utilise main RAM rather than the actual stack.
Another limiting factor is the inability to display large amounts of text. I would normally (using HB++ or other IDE) display a multi-line text field with scroll bar and no underline, and fill it with the text I want. However, the maximum text allowed is 4096 characters using the Megastring. I can use a resource file to display the string, but then it occupies the entire screen with up/down arrows instead.
In fact, the limit on the text strings and even the Megastring is very limiting. Hopefully these can be increased.
These are the only real blocking points I can see as there is no work-around for them. I have a whole list of other issues I would like resolved whilst we're at it, but I wouldn't consider them to be real blocking points.
=> 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.
I would go for an iziBasic that couldn't use PP applets, especially if you are able to incorporate access to all Palm OS APIs. With the resulting program running native on Arm and access to all APIs, it should be more than able and fast enough to cater for all needs.
So when will you start? I'm already looking forward to next year's Christmas present! 
|
|
|
|
Warning: A non-numeric value encountered in /web5/aldweb/www/aldweb_com/www/thread.php on line 497
Answer n° 10
--------
12/12/2006 @ 23:36
by Garfield
visitor
|
Hi Aldweb
Have you made any decisions? Have you started yet?
Please keep us informed - it's something we're all very interested in.
Thanks.
|
|
|
|
topic active
 topic closed
 Sticky
 New message -
 Correct message
 Close topic
 Make sticky
|
|
I. aldweb
![[de]](img/de.gif)
![[es]](img/es.gif)
![[it]](img/it.gif)
![[pt]](img/pt.gif)
visitors
visitors online
Top 
© 2004-2013 
