Pocketviewer.de Community Forum

Hello,

» It's a pity that OWBasic itself consumes so much recources while running
» the programs, i think it could be much faster, if it runs directly on the
» hardware. But until now, i can only code in OWB...

what would "run directly on hardware" be for you? Do you think about native code generation?


» Hey Moritz, is there any possibility, that the development of OWBasic will
» continue?

In principle, yes, there is. Just with a different premise.

My first involvement with OWBasic was primarily driven by my own interests. I had certain things I wanted to be able to do in an OWBasic program (e.g. use pointers to support certain patterns of programming) which weren't possible in Wolfgang Ortmann's OWBasic 4.0. (Actually, using pointers was possible by some really weird tricks with arrays and VAR parameters, but let's not go into that.)

Since then, my interests have shifted. Back then I primarily worked in C, C++ (well, kinda) and OWBasic, and I did it just for fun. This has changed since the end of my high school days - nowadays, some of my work is for commercial purposes (mostly in C++, Delphi and Java), and my hobby work is targeted at C++Builder and Delphi (both of which are actively maintained by very cooperative folks and supported by a reasonably large community, which of course raises the motivation on my side). And, of course, I got a life and can't spend all day working on software

I'm still interested in compilers and, of course, all the low-level trickery involved with it; this is why I'd say there is a chance that I continue to work on OWBasic someday. As you can see, I'm not actively maintaining it right now, and that's mostly for four reasons:

1. OWBasic is at the limit, in every sense of the word. It fills up pretty much all of the 128 KB available for a custom PV add-in. You really don't want to know what nasty kind of things I had to do to gain yet another KB to be able to implement a new feature. (Should you really want to know, diff the source code of OWBasic 4.0 against the more recent versions.) The core interpreter and some other speed-sensitive parts are written in assembly code for the "old" x86-based PV models (which implies that I need to maintain the same source code twice, once in assembly language for the old models and once in C for the PV-S1600).

2. OWBasic isn't really a proper compiler. That may sound a bit rough, but since I've dived into compiler literature a bit, I realized what would be possible if the parser generated a parse tree. Writing a backend that emits native x86 code would be more or less trivial then, not to talk about all the code optimizations that become easy to implement. In the current implementation, OWBasic directly emits the byte code which is then interpreted during execution. This allows only for trivial optimizations such as constant folding (which I believe I implemented in v4.4).

3. OWBasic suffers from several conceptual flaws. For example it doesn't really support stack variables (i.e. all local procedure variables are allocated as global variables); this is why you can't call a function recursively without all kind of problems.

4. The OWBasic code base isn't exactly easy to maintain. I was able to apply a few basic changes relatively quickly, but it took me months to really understand most of it, mostly because of all the magic numbers (e.g. error codes, symbol list entry offsets etc.), the global variables, multiple uses of the same buffers, the state management in the parser and those kinds of things.

To be clear: above reasons aren't meant as an offense to Wolfgang Ortmann. Considering where OWBasic v1.0 started, many decisions which are a problem nowadays are totally understandable in that context. After reading the source code of OWBasic 1.0, I was deeply impressed by his evolution of the compiler. Also, with all the "dirty hacks" I applied to keep OWBasic within the limit of 128 KB, I really contributed my share of "smelly code" to the code base.

It's about the same kind of problem that Borland^WInprise^WBorland^WDevCo^WCodeGear^WEmbarcadero has with BCC which initially was just a C compiler for DOS and today is a full-fledged C and C++ compiler that targets Win32, once targeted Linux/x86 (in the time of Kylix 3) and will probably target Mac OS/x86 and Win32/x64 in the future. Of course, about every compiler has to deal with this problem some day, but only the really large vendors (IOW, only Microsoft) can afford to solve the problem the clean way: by doing a total rewrite. Matter of fact, Microsoft's Visual C++ compiler has undergone several rewrites according to the Compiler Team interviews published on The Code Project, but AFAICS, Borland's compiler didn't. This is the reason why BCC runs about three times faster than MSVC - it's still the old piece of software written in hand-optimized C and assembly code -, but it's also the reason why BCC currently can't keep up with MSVC in terms of code optimization and standards compliance.


Considering all these points, you might be able to understand why I really haven't any interest to hack in yet another major feature into the current code base. While I'm interested in creating something new and powerful, I think it won't be possible without large compromises. For example, I could initiate an all-new compiler that features native code generation, borrow some code from the "original" OWBasic (the lexical analzyer, the essential runtime library functions, the menu GUI etc.) and rewrite everything else. This would of course imply about zero compatibility with existing OWBasic source code, and no native code support on PV-S1600. (PV-S1600 support is doable, but while I'm quite experienced with x86 CPUs, I don't know much about the 68k CPU used in the PV-S1600, so don't expect it anytime soon.) However, the code generated by this new compiler could be on par with C code compiled with the SDK compiler in terms of speed, at least in theory. (Btw, don't expect much improvement in floating point calculations; the old PV models don't have an arithmetic coprocessor, and thus all FP operations are emulated by the CPU. The PV-S1600 does support FP operations natively, which becomes obvious when comparing the speed of, say, PVPlot on old and new PVs.)

Don't take above paragraph as a promise. Right now I'm on vacation (visiting Tromsø in Norway), and I'm working on a C++Builder plug-in when time allows. From September onwards I'm going to study Physics, and I'll need to move to another city because of that, so don't expect anything in the next months. But when I have some spare time and sufficient motivation, I might begin to implement the aforementioned project.

Thoughts and comments and critics are much appreciated.