A new QB compiler

[na_th_an]

It all reduces to the same thing:

BASIC's purpose is the principal matter of its speed disadvantages.

Doing all the changes Z!re and Wizard Genius are suggesting, would create another language that is not Basic. So, why bother? Pascal has a syntax very simmilar to Basic's, but it is in a lower level (still over C), so if you can't be bothered to code in C go for Pascal. TP is a great compiler, but its output still can't outperform TC's.

Z!re you keep repeating the boundary checking stuff! We've got it yet, and I think I replied: You can add those optimizations to a BASIC compiler (check PowerBasic 3.5), but still it won't be as fast as C.

And if the program only adds error checking to parts that can have errors, then there's really no problem.

True, and PB 35 does it. But still, you can't reach C's speed 'cause C does not perform ANY runtime checks.

Your VB test: how did you quit? If you add a simple "DoEvents" your program can be 100x slower. Anyways, VB is a better compiler than QB, but it still has tons of checking. VB optimizes way more than QB, but it is even in a higher level than QB.

To me it just seems like: Meh, I don't want to do it, it's impossible!

Have I told you to check PB 35?

The compiler CAN translate the "QB" code to whatever you want.

You could write a translator that makes it C code, and then compiles it.

You CAN, do it... Well, someone can, I can't as I don't know enough ASM nor C (damit)

There are several QB to ANSI C translators. Its purpose is just being able to run BASIC programs compiled in Linux, for example. But mind you: you will never gain much speed 'cause BASIC will keep being BASIC. They still produce C code that does runtime checkings, and rely in a runtime (you may say "well, so let's write one that does not do those checkings, but that comes back to my very point: in that case, BASIC "sense of existence" vanishes: you must get an error, not a crash).

The only thing you are gaining is that most likely the C compiler you use afterwards optimizes many things, but you still won't get the speed of C.

It is simply impossible. If we are talking about a BASIC compiler, of course.

Z!re and WizardGenius are not talking about a BASIC compiler, but about a "insert-name-of-new-language-here" compiler. I find it interesting (I've been creating interpreters and stuff like that since I can remember), but somewhat pointless: you have plenty of languages available that perform quite well. You don't need that. Seriously.

C isn't such a hassle to code in. C'mon, just a ";" after each statement won't kill ya ... And you can always use #define s to convert your C code in a BASIC-alike code.

Btw, try PB 3.5

Try it, try it.

It is like QB but with some low level stuff (bitwise manipulation, BYTE data type, inline assembly and more), and does optimize, plus generates i386 code.

Did I mention it?

Try PB 3.5

Btw, I remember having given it to Relsoft... Did you do something with it?

EDIT: I just remembered... There is something that looks very similar to what Z!re and WizardGenius are suggesting: Moonrock. It is way faster than QB, does less checkings, and produce really tight executables (hello world = 100 bytes more or less). I suggest you to try it. But expect a crash instead a "integer out of range"

[LooseCaboose]

Ofcourse some boundary checks would be needed, but QB does it even on a=0 (What I know atleast)

You aren't listening, there is a difference between compile time and runtime checks. Compile time checks are inexpensive because they are done once and the resulting executable is no slower. Runtime checks are expensive because they are done everytime a particular set of instructions is executed. Some compilers do check assignment of a constant that is too large for the variable is it being stored in, for example:

Code:

#include <stdio.h>
int main(void) {
  unsigned char a = 32768;
  printf("a = %d\n", a);
}

Code:

# gcc -Wall -pedantic num.c -o num
num.c: In function `main':
num.c:3: warning: large integer implicitly truncated to unsigned type

# ./num
a = 0

Thats okay, but you still cant remove the runtime checks in basic on any variable that has come from outside the program, or any subsequent use of that variable. Also, most mathmatical operations on variables will need to be checked at runtime, because even if both variables are within the limits of their storage types, the result of adding them, or raising one of the to the power of the other, may not be. The runtime checks are part of basic's philosophy, thats how the language works. C doesn't have alot of runtime checking, thats its philosophy, its fast, but you also get given enough rope to hang yourself with.

WHY would it be impossible to have a compiler, that is 100% QB syntax compatible, but as fast as C (or close too).

Heres an example for you, recently for one of my projects our class had to write an inverted index for being able to search for text (similar to what search engines do with the web). The source document isn't known upfront, so the whole thing is done with dynamic memory. I wrote mine to fit nicely into memory, by parsing all the inputs and then allocating the right amount of space. A friend of mine took a different approach, and designed his program to guess roughly how much memory each structure was going to take, allocate a large chunk of memory, and then extend it if it was wrong. His solution ran somewhat faster than mine, but often used far more memory than was necessary. This is the power of C, you are allowed to make assumptions and handle all the memory management yourself, etc, but it is much more difficult than having a high level language like basic do it all for you.

You could write a translator that makes it C code, and then compiles it.

Yes, you could do that. But for it to faithfully compile and run like basic the generated C code would need to be extremely verbose and contain a number of error checks around certain parts of the code. Most C programmers don't code like this, and could easily produce faster code than a converted could produce, much in the same way that a skilled assembler programmer will always produce faster code than a C programmer with a compiler.

And the list, none of them are 100% QB syntax compatible.

I didn't say they were, but maybe you could bench mark some of the 32bit basic compilers from that list against some C compilers. I guarantee those basic compilers produce faster code than QB, but still dont match up to most C compilers. If you are really keen, the source for a number of those compilers is available, so there is always room for improvement.

[Z!re]

Ok then, a new language, that is 100% QB syntax compatible.

There :rotfl: happy? :lol:



I quit VB by pressing CTRL+Break, then do a debug check.



Where can you find PB and Moonrock then? *interessted*

[Jonathan Simpson]

There isn't that much point in making yet another basic language compiler. If what your looking for is something very QB like, the powerbasic console compiler is pretty close for text based stuff... it even has LPRINT. Unfortunatly, it doesn't have the "FREE-NES" of QB, but it's worth every penny if you want to be able to really program with BASIC, and I mean that.

VB is 99% compatible with PDS, the language is the same.

That is true, but misleading. While about 90 + percent of QB statements still exist and are mostly compatible, QB code converted to VB has a much lower conversion rate than that. In my experience, 20% or less of the code is usable directly. This is more than anything else a result of PRINT, LOCATE, and similar text handling statements which no longer exist (and for good reason). Now, I know many of you may not care much about text handling, your probably more concerned with graphics, but I've had to translate or rewrite a handful of QB programs into VB, and it is not an easy task.

[LooseCaboose]

Ok then, a new language, that is 100% QB syntax compatible.

Thats impossible. If you create a new language, even with the same syntax as Qbasic, but remove all the runtime checks and change the way the error handler works then it will no longer be 100% QB compatible.

Whats the deal with wanting 100% compatibility anyway, everything that can be done in Qbasic can be done in PB, VB, C, Java, etc, etc, its just done differently. If you really want to be able to write programs with no memory limits and fast execution, then it is time to learn a new language, not ask someone else to make a better version of the one you are currently using.

I seriously doubt the Qmunity are ever going to shift to using a new compiler, as na_th_an has pointed out, it is impossible to create a 100% compatible 32-bit Qb compiler (at least without some major hacks), and little point in making another 16bit/Dos one. There are already plenty of other mostly-compatible basic compilers that are available for a variety of environments, that provide all sorts of cool additions like gui commands and access to DirectX and OpenGL, but none of these have caught on here yet. The reason that I think people still code for QB (at least why I do) is because of the challenge of writing software for such a limited environment/compiler.

[someone42]

Of course a win32-target compiler will never be 100% compatible with all QB programs. How do you think win32 would handle:

Code:

' Wait for VSync
WAIT &H3DA, 8, 8
WAIT &H3DA, 8

The thing to realise is that 100% QB compatible does not imply 100% DOS compatible. When I talk about 100% QB compatibility, I am talking about PureQB™.

Of course because QB is limited, QB programmers have to resort to "hacks" like the above to achieve the desired functionality.

What if a new QB compiler included a standard library that included certain low level functions related to video, sound, input, network etc.?

BTW, thanks for the responses!

[Z!re]

Loose: I never wanted someone else to do it, and it wasn't even I who started the thread, I just think i would be a good idea to have a faster compiler for the popular language called BASIC, and the compiler should be compatible with QB 4.5, PDS 7.1.


And I do know other languages, I just don't like them

[na_th_an]

Z!re: Google If you can't find them, I'll send them to you, just get me on MSN.

PB35 is almost 99.9% syntax-compatible with QB. The IDE sucks, but you can always use another IDE.

Moonrock is easy to find:

http://www.rowan.sensation.net.au/moonrock.html

But the language is quite a bit different.

There are BASIC compilers better than QB, and a whole bunch, but they will never catch up, for one reason or another.

someone42: exaclty my point. In the very moment you change of platform (from MSDOS to Win32) you make the 100%-compatibility an uthopy.

LooseCaboose: Completely true. As always

---

Btw, where's that OBDS thingie? (plug).