12 replies to this topic

[MicroPro]

Hi.
As you all know, The BASIC language of ClassPad runs really slow and inefficient. So every person who wants to write good (the best) programs on-calc on ClassPad should use CPLua.

But some programmers have written programs in BASIC, and still some BASIC programs are being written.
I was wondering what's wrong with the cp's internal basic language that runs so slowly? And therefore tried to write my own BASIC interpreter to see how much difference is there in speed! Yes I did that spent 24 hours during the last two weeks to research and develop this addin. I call it 'QBasic' (version 0.1.0).

Already done some benchmarks:

Benchmark 1: Print 123 Print 123*456 Print "Hey there" Print "ClassPad" (Copy and Paste that 25 times to make 100 lines of code.) Time of running: CPBASIC: 9 seconds. QBasic: 4 seconds. Note that QBasic doesn't have some limitations of CPBASIC, for example in CPBASIC the output window can have max. 30 lines, while QBasic virtually has unlimited number of lines.

Benchmark 2: 1 => a 1+2 => b 12345 => c 123*456 => d (Copy and Paste that 100 times to make 400 lines of code. Then add the following line:) Print "Done." Time of running: CPBASIC: 1 second. QBasic: 4 seconds. QBasic saves variables directly in mcs memory, but I think CPBASIC saves them in ram for a while and detects duplicate variable assignments, which is why QBasic runs slower in this case.

The above expressions are the only things it supports (for now): Print and =>.
Note: You can't have functions in expressions. For example Print sin(x) and sin(30)=>x are not valid (again for now).

It's only a very limited add-in, only a proof of concept. However anyone who likes to try it, download it from here. Type your program in 'Program' application of cp, then go to QBasic and run them via 'Open' menu.

A question is: am i going to develop it more and make a full basic interpreter? I don't know. It depends on people's reactions. Please tell me what do you think about the idea.
Bye.

Edited by MicroPro, 03 November 2010 - 07:10 PM.

[Kilburn]

Oh, hey there, haven't seen you in a while! Didn't think people would be still around making applications.

Looks pretty interesting there, so basically you're aiming to replicate the CPBASIC interpreter and make it more optimized? Seems interesting. I'd recommend that you store a table of variables, and only write them to MCS when the program ends or is interrupted. Writing directly to the MCS is obviously way too expensive to be usable continuously in a program.

Anyway, good luck on that!

[MicroPro]

Wow... Replies!

Actually, the main thing i wrote this addin for, were the graphic commands which are too slow in CPBasic. I don't know if i can develop QBasic enough to be able to run that commands.

I'd recommend that you store a table of variables, and only write them to MCS when the program ends or is interrupted.

This is what i thought Program (the CP BASIC) did, but recently i found out that CPBasic really writes variable to mcs as soon as you assign sth to them and still it's faster than QBasic! I'm trying to find the reason.
BTW, Kilburn, I'm having lots of fun with your bf compiler!

Didn't have time to work on that since that post. But i hope i have some free time to make it more complete this week.
Thanks for posts.

Edited by MicroPro, 12 November 2010 - 10:46 AM.

[PAP]

A better Basic interpreter sounds like a very good idea, but I have to say something... The main problem with CPBasic is not only slow program execution, but also, and even more important in my opinion, the very poor features, especially as far functions and subroutines are concerned. CPBasic practically does not support subroutines at all, it actually reminds me the ancient implementations of Basic, dated 30+ years ago. No matter how faster the new interpreter will be, I think it won't be useful for serious programming, if a better way to implement real subroutines is not implemented. So my point it, just a copy of CPbasic features which will run faster will have limited usability. I have my LNA in mind saying that... it is practically impossible to implement it in a basic interpreter which does not support decent functions/subroutines, and data hiding.
It is up to you, MicroPro, I guess implementing faster versions of CPbasic's graphics functions in your Basic would be nice, but if you think about implementing the rest of CPbasic, I believe you should consider improving subroutine support, otherwise it is not really worth the effort...

Edited by PAP, 27 November 2010 - 06:12 PM.

[MicroPro]

Constructive Ideas!

Although CPBasic is a... ok... I don't wanna become angry now. But want it or not, there are many programs (and games ) already written in CPBasic which users use a lot.
Before i make this addin i had ideas of expanding the cp basic while keeping programs compatible with the real Program application. For example instead of using StrCmp for string comparison, use If "str1"="str2", etc. Implementing such functions does not make programs incompatible. Implementing subroutines can be so.

For example this: Sub Add(x,y) return x+y SubEnd Print Add(2,4)

can be converted to this CPBasic-compatible code: Local x,y,ret x:=2 y:=4 Goto Sub_Add Lbl Calling_Position Print ret Lbl Sub_Add ret:=x+y Goto Calling_Position

As soon as one makes a CPBasic compiler, then we can make any desired modification to the language. But there is just one 'small' problem: Implementing a BASIC program editor and compiler is a lot of work to do. Right now in programming this addin i know that i don't need to take care about syntax errors too much, since Program Editor has already nagged about most syntax errors and the user has fixed them. But guess how difficult would be implementing that editor from scratch! (If i just had the source codes... )

I've been developing hard the last days, and QBasic now supports If, While, Do LpWhile, For, Local variables, Input, and more. Once it becomes able to run some of the programs already available to the public, i will release a beta version.

[PAP]

Curious to see how it will go. But I have to insist, if you keep Qbasic fully compatible with CPbasic this will simply mean you will have a very poor programming language running considerably faster than CPBasic. I understand it is too early to tell where you will go with this project, but I think you should keep in mind that if you want your Basic to be used for serious programming, sooner or later you will need to deal with CPBasic's subroutine implementation (if that thing can be even called a "subroutine"), and will need to improve them, thus making a Basic not fully compatible with CPBasic. This is not a big deal, your Basic could run programs made for CPbasic, but not vice-versa.

Edited by PAP, 28 November 2010 - 05:00 PM.

[MicroPro]

I think my last post was a bit unclear. The code user writes in the program editor is later compiled by the classpad. ClassPad always executes the compiled code.
I wanted to say it's possible to add subroutine ability to cp-basic without actually making it unrunnable in the real "Program" application. When user enters the code at the left (the above post), it can be silently compiled to the code at the right. So for using procedures there is no need to break compatibility.

You see, most things, such as structured programming (i think), can be implemented in the language. And we need a good compiler that knows how to compile that code to be cp-basic compatible.

Still if one day, i feel i have to break compatibility, i will do it. But for things like subroutines i see no need.

[vanhoa]

Not really, sub-routines is including recursive ones, which should be implement by stack of memory frames, not static label itself.
And, well, in my opinion, if you want it to be faster than built-in one, you should rewrite the CAS.
Anyways, good work:)

Edited by vanhoa, 30 November 2010 - 01:46 AM.

[PAP]

I still have doubts, for example how can you translate structured code to CPBasic native code... What will happen if you define a subroutine with local variables that should not be visible to the rest of the program? How could you implement structured code, separated in several program files, as my LNA is structured? A command like CPLua's require command is needed then. How can that be translated into CPbasic code? There are plenty of things to be addressed. I wish you luck in this project, and I am ready to do experiments with your Qbasic, implementing a numerical method on it, when that would be possible.

[MicroPro]

Not really, sub-routines is including recursive ones, which should be implement by stack of memory frames, not static label itself.

Not really thought about recursive functions. You're right. If it's going to be cp basic compatible the compiler should generate a stack in the basic code.

if you want it to be faster than built-in one, you should rewrite the CAS.

Actually i must rewrite the expression parser and evaluator. Heavy work such as diff, intergral, etc could be left out to cp's cas. Implementing my own expression parser was an idea i had from the beginning, but i decided to do that after i could implement some other features of the language.

how can you translate structured code to CPBasic native code...

I have ideas for those issues. Private variables in functions can be set at the start of the function and deleted when the function ends. For modules, the simplest way is to have a program with an argument 'FunctionNumber' which will jump to the correct function. 'Require' can be a processor command that tells compiler into which file it should look for the functions. Other solutions may exist.
But to be frank with you, you are growingly persuading me not to stick to CPBasic syntax and commands. Although i have strong reasons for myself not to break compatibility.

Edited by MicroPro, 30 November 2010 - 08:26 PM.

[vanhoa]

You can start with OWBasic for PV. But anyways, calculators are getting old within these years...

[MicroPro]

Hi!
QBasic Version 0.20 released!
I put the link in another topic for ordinary users (i.e non-programmers) to download it. But i would like to continue our technical (ok, not so much technical) discussion here.

First about the new version: It doesn't have an editor. Only runs the programs.
This is full list of things this version of QBasic supports: Commands: Print, Input, Message, Locate, ClrText, GetKey, Local, Pause, Stop; statements: If, While, Do...LpWhile, For, Switch; other things that are now supported: running EXE files, using system variables and CAS functions, running subroutines within the main program (and nested subroutines). It can also print expressions, lists and matrices but cannot save them to variables.

Now about being CP-BASIC-compliancy:

how can you translate structured code to CPBasic native code...

It doesn't compile to editable CPBasic code. It compiles to EXE code.
CP's EXE format has assignment (JUMP), Lbl...Goto, program branching instructions, etc which means theorically it's a complete assembly language able to run everything: imagine a C++ compiler that compiles to CPBasic code!
If you are curious i explain more about the EXE format later. I've discovered the entire structure of it and its commands. I'm very proud of it! (Wasn't actually very difficult! )
So if the compiler can compile structured CPBasic code and make classpad compatible EXE files out of them, do you think it's necessary to go out of the specs of the CPBasic?

You can start with OWBasic for PV.

Actually, i don't want to make another non-embedded language. Many people program their classpad using the built-in program application, to be able to call them from 'Main' or any other application. And they run others' program from Main, too.

calculators are getting old within these years...

I wanted to comment on this but i don't know what to say. I 'mildly' agree.

Edited by MicroPro, 12 December 2010 - 06:35 PM.