Qbasicnews.com

What about 100% support for "original" (the current one, PDS 7.1) basic, and extended support, allowing to create 32bit applications and using 32bit libraries (designed esp. for this)


But seriously, a new compiler, that creates more optimized code.

It can be done, and it wouldn't be impossible.


Imagine, the simplicity of BASIC, but the "power" (read: speed) of C

Quote:What about 100% support for "original" (the current one, PDS 7.1) basic, and extended support, allowing to create 32bit applications and using 32bit libraries (designed esp. for this)

VB is 99% compatible with PDS, the language is the same. Direct video access (I mean, no windows) isn't possible unless you wrap DirectX or the GDI, but you can do that in VB already. It would be nice to have it done transparently, but that has to do with Nekrophidius' forthcoming (I hope) compiler.

Quote:But seriously, a new compiler, that creates more optimized code.
It can be done, and it wouldn't be impossible.

Sure, the Microsoft Basic Compiler is shit, the output is so slow, it could be easily improved. But what's the point on building yet another MSDOS (16 or 32 bits) compiler? MSDOS is getting more and more problematic.

Plus, if you really want one, look for PowerBasic 3.5.

Quote:Imagine, the simplicity of BASIC, but the "power" (read: speed) of C

That's impossible. To make BASIC as fast as C you have to:

1.- Add pointers. I mean true pointers. In BASIC you can get a pointer to a piece of data, but nothing else.
2.- Take away all the boundary checks. Such stuff can only be performed in execution time and slowens down the program execution a TAD. It is there to make BASIC simpler to use and to debug. In C, if you write outside an array you will crash the computer, most likely.
3.- Take away the string handler. Coding in BASIC is so simple 'cause the strings are taken care of by the runtime (done in the best way, but not always "the faster" way). In C you have to do it yourself.
4.- Take away (or translate) the deprecated stuff allowed for backwards compatibility.
5.- Change the file managing system to a lower level. In C you deal directly with the file descriptor, in QB it happens like with the STRINGS: you get a handler and the runtime does the rest.
6.- Take away the error managing, and all the execution-time checks.
7.- Change the ports and interrupts managing to a lower level. You are talking to QB, not to the machine, for the sake of security and trying to allow as many crashes as possible. That is slow.
8.- Allow the user to do all the memory management. Currently it is done automaticly.

BASIC is in a very high level to be as fast as C, a language that is, sometimes, "almost assembly". If we make the aforementioned changes to BASIC we put down its simplicity, i.e. its whole point.

Quote:That's impossible. To make BASIC as fast as C you have to:

1.- Add pointers. I mean true pointers. In BASIC you can get a pointer to a piece of data, but nothing else.
2.- Take away all the boundary checks. Such stuff can only be performed in execution time and slowens down the program execution a TAD. It is there to make BASIC simpler to use and to debug. In C, if you write outside an array you will crash the computer, most likely.
3.- Take away the string handler. Coding in BASIC is so simple 'cause the strings are taken care of by the runtime (done in the best way, but not always "the faster" way). In C you have to do it yourself.
4.- Take away (or translate) the deprecated stuff allowed for backwards compatibility.
5.- Change the file managing system to a lower level. In C you deal directly with the file descriptor, in QB it happens like with the STRINGS: you get a handler and the runtime does the rest.
6.- Take away the error managing, and all the execution-time checks.
7.- Change the ports and interrupts managing to a lower level. You are talking to QB, not to the machine, for the sake of security and trying to allow as many crashes as possible. That is slow.
8.- Allow the user to do all the memory management. Currently it is done automaticly.

Not to mention put in optimisations for CPUs better than an 8086. Seriously, QB4.5 was written in 1988. Analysis of the compiled code for "value& = value& + 1" gives something like:

What is much more appalling is that compares involve a function call. And the function isn't a simple compare-and-return, its bloated full of crap!

There's also the floating point interrupt bug, which makes floating point operations 3 to 4 times slower. Though I must mention a fix is out for that...

Any BASIC compiler written today would easily outperform QB4.5.

VB - in my experience its supports a lot of qb commands but the windows version lacks some basic support for commands like screen, I ain't found anything that supports qb graphics commands. What would I like out of qb compiler, all the qb commands apart from the ones that cause problems when ran in windows(ie call absolute and interrupt) and support for dll's, but 16 bit libarys? Thats going to crash someones comp quick, if you run the wrong libary. I would also like some new commands, ones that give the features of some of the main libarys, like future libarys graphics commands. Also some new commands to interact with windows GUI's.

Quote:Not to mention put in optimisations for CPUs better than an 8086.

QB71 has that. Try the "/G2" switch for bc.exe. Still though, it's only 80286...

I believe if the new basic compiler has commands like
-Screen 13 or screen 24 or something for setting up full screens
-WIndow(x,y,width,height) for setting up windows etc
-Easy spritehandling. So just say put(x,y,spritearray)
-And all other stuff that makes qb easy
Then one would have a good QB-like compiler

Check out purebasic It costs 60 Euro and is the best basic compiler I have seen.
If you can program with QB youw will love this one.

Nath:

What stops "us" from writing a compiler, that does most of thoose things automatically?


And, this code:

FOR a& = -2147483648 TO 2147483647
NEXT

Compare it in QB and C, C is a LOT faster.

The above code would take a few DAYS to run on my computer when done in QB.

It took roughly 30 sec when made in C.


So, this is what it does, roughly:

a& = -2147483648
Label:
a&=a&+1
If a& <= 2147483648 Then Goto Label:


Why is that so much slower then in C.


Also, why cant it be done like: You have oundary checking while in the IDE, everything works exactly like in current QB versions.

But you compile to a cleaner state, allowing for no bouundary checks and so on.



And what's the point of programming in QB, none. It's fun and you learn stuff.

So what's the point of yet another compiler, none. It's fun and you learn stuff.



Also, it would be nice if a new compiler allowed for headerless "com" files (pure op codes) output, instead of EXE's with all their header info.

In short I would like a compiler which would allow me to easily modify games to work in windows.

I think that whether you all haven't understood my explanation or you simply haven't read it. That's a little bit frustrating.

Summing it up:

1.- Stuff like SCREEN 13 have to be done through DirectX. You can do that in VB, you just need to code a wrapper or get one already coded.
2.- The rest of the language is the same... Well, it is improved.
3.- QB is not optimized and could be optimized. Z!re, I said that, what I said is that it will never be able to be as fast as C for the zillion reasons I provided above. It can be faster, but never as fast as optimized C.
4.- Nothing stops us, I was just was making some points:
4.1.- For DOS: Why? I am fed up of coding stuff that only QB geeks are able to run
4.2.- For Windows: It would be like VB + Wrapper, and Nek is already on that (I suppose )
4.3.- Building a compiler is probably the most difficult task in programming. Let alone making a good compiler with optimizations

Also, headerless COM files only have 64 Kb for DATA+CODE+STACK. So it is even more limited.

Jatos: That's impossible unless your game doesn't use a lib.

If you are thinking on, for example, getting the source code of Ghinni Run, loading it in the new compiler, and compiling it for windows... that's impossible. You have to make lots of changes. Sure, the core algorithms would be the same, you just change the output (GFX, sound) and input (keyboard, timer)... But you can already do that in VB.

If you want a new compiler, more optimized, for windows and easy to use, wait for Nek's. But forget about loading in your ol' QB games that use LIBs and compiling them. 16 bits code can be run in a 32 bits environment, but shifting to 16 bits mode. The process is too complex to explain here and I feel a little lazy today. Let's say that you simply can't run DirectQB natively in Windows from a Windows EXE.

VB+DirectX produces very tight code. Wouldn't be it better to create a preprocessor that took a QB-like source and translated easy graphics/sound/keyboard commands to DirectX automaticly?

My point is, why would it be impossible to get as fast as C?

And screw 32bit's windows programming, if we wanted that we would switch to VB .. err.. lol


Goes back to my example:

FOR a& = -2147483648 TO 2147483647
NEXT

In qb, takes ages.. In c it's fast.

What would stop the compiler from making the same kind of optimization as a C one?

Or a QB->C translator?

(Can you get QB made libs to work under C?)