Qbasicnews.com

*sigh*

read!!!!

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.

na_th_an wrote that before. read it this time.

really, if you want a faster programming language, learn c or c++ or something. because it's not worth it to make another basic, as there is NO USE FOR IT!!!! all qbasic is any good for is hobby programming, and learning to program and develop programming technique. therefore making a new compiler is just a waste of time.

Barok and Nath, I have read it.


But I don't see why it would be impossible for the compiler to handle thoose things?


Low level file handling, yeah, but the code to make it could still be as simple as before.

OPEN "whatever.txt" FOR OUTPUT AS #1
CLOSE #1

Just that when compiled it is translated to a more efficient way than the one QB is currently using.


Pointers, sure, but why would the user be able to see them?


Boundary checks, they are good, but really.

A boundary check for this:
a=0


At compilation you could check to see: Code cannot, in any way generate a boundary error.


a=b
Code can generate a boundary error.


a=0
b=0
a=b
Code cannot generate a boundary error.


See my point?


Backwards compatibility would not be required if the new compiler is made for PDS 7.1 or QB 4.5, users would simply have to go by that and not use QB 1.1 commands/techniques.


Like I said before, error managing, sure, and debugging, it's really good in QB, so, leave it when developing, and have an option called: Compile final version, or something, that doesent generate the same amount of debug data as QB (because it's slow)


Changing ports could be done, because it's a new compiler, so QB has nothing to do with it.


Memory management, sure, allow the user to be able to do that ,but also do it automatically.



QB is old, it can be made a lot faster by using new ways of optimizing, and using 386/486 or even 586 code instead of 286.

And noone has answered my question:
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?

Man, I'll try to write it simple: BASIC is simple and easy to code in 'cause it handles everything for you. C is fast 'cause it doesn't. If we want a BASIC as fast as C you have to take everything out, that gives out C with another syntax. No ease of use anymore.

Again, QB is horrible, it can be improved in many ways, but it will never be as fast as a good C compiler.

The main difference about coding in QB and coding in C is that when you make a mistake, in QB you get an error and in C you get a crashed computer. That's why developing in QB is easier.

I'll give you another example: Can you create a C compiler that has an output EXE which runs as fast as an EXE written in assembly? No. Why? C is at a higher level than assembly.

Just extrapolate.

I could go into details, but I'm too lazy...

Oh, well...

Quote:Backwards compatibility would not be required if the new compiler is made for PDS 7.1 or QB 4.5, users would simply have to go by that and not use QB 1.1 commands/techniques,

QB 1.1 was released at the same time as PDS 7.1, the commands and techniques are the same, taking appart some "proffesional" stuff they added to the BC series and some stuff they ripped from QB (interrupts, for example).

99% of QB programs rely on the list I provided several posts before. Taking that appart would make every program to crash in the most nasty ways.

Quote:Pointers, sure, but why would the user be able to see them?

Do you know dynamic trees, queues, stacks, dictionaries, maps, priority queues, threaded trees, etc etc etc? Tell me how you do them without pointers and manual memory managing.

Quote:Like I said before, error managing, sure, and debugging, it's really good in QB, so, leave it when developing, and have an option called: Compile final version, or something, that doesent generate the same amount of debug data as QB (because it's slow)

That would create inconsistence and a bunch of security holes. We already have some kind of what you say in QB, that's why there are so many things that behave differently when compiled and when not. What you want to do is extremely difficult, if you know about compiling you'll realize that.

Quote:Memory management, sure, allow the user to be able to do that ,but also do it automatically.

Explain to me how.

The only way I can figure out to do that would add even more branching to the program and even more checks. Old QB programs which used automatic memory managing would be even slower than they were in QB. New QB programs that manage memory themselves would be slower than their C counterparts simply because of the branching.

Quote:Boundary checks, they are good, but really.

A boundary check for this:
a=0


At compilation you could check to see: Code cannot, in any way generate a boundary error.


a=b
Code can generate a boundary error.


a=0
b=0
a=b
Code cannot generate a boundary error.


See my point?

I see your point, but note that your example would be used... never. 99% of times the compiler can't notice the danger of a boundary error until execution time.

Rule #1 when building a compiler: add or not to add boundary checking in the runtime.

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

The fact that the QB compiler is really bad.

Summing it up: you can build a faster compiler which did all those optimizations, but you would never reach C. Reasons mentioned above. That was my whole point.

Plus, QB relies on a runtime to run. C doesn't. Hence...

PS: Your FOR question: In C the compiler is usually intelligent enough to notice that there's nothing inside the loop. QB isn't as intelligent. Plus QB doesn't like 32 bits numbers, LONGs are really bad implemented in QB.

But we are not talking about QB, we are talking about a new compiler that is compatible with the QB language.


And We assume that there is some stuff in the FOR/NEXT loop:

FOR a& = [...]
m&=a&
NEXT



What would stop the new compiler from doing the same optimization that C does...

I know QB is slow, and C will always be slower than ASM, ASM would be slower than doing some direct programming (not even possible anymore, that I know of atleast)

Quote:

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

The fact that the QB compiler is really bad.

We are not talking about the QB compiler, but a new one =)

That's my point.


QB may suck donkey ballz, but so, we're not talking aobut it, we are talking about a new compiler, and why it would be impossible to make it as fast, or atleast close to, C

No.

Last post

Faster BASIC compiler: Yes.
Close to C Speed: Never, unless you want to throw the BASIC features to the trash bin.

Man, if you want fast output, code in C.

The compiler you suggest would be like coding in C but without brackets and ;.

All I want is speed, and the QB syntax =)


And I already know C, I just don't like it (it's syntax that is, and the constat use of () and ;, it annoys me )

na_th_an: I can think of a good counter-example: PowerBasic. It has pointers, nearly as fast as C (much faster than qb), and still supports strings.

It also supports bytes, byte arrays, and zero-terminated AS STRING*?'s so you can do strings the fast way too. Just because the basic style strings are also there doesn't mean you have to use them if you think they're slow.

If its IDE didn't suck, and it did metacommands, CONST statements, etc the QB way, I bet we'd all be using it instead.

I just got through reading all that. It took me about 30 minutes, and I'm a FAST reader . Well, personally, I like Pascal, but it uses a lot of ;s and etc. And that's irrelevant anyhow. Personally, I think it would be possible to write a compiler that generates EXEs as fast as C, from QBasic syntax. It would be very hard. Personally, I would add structure, like { and } or BEGIN and END (Yes, I already know there's a END in QBasic :lol: ). I would think that it would be possible to have the programmer take care of memory access, etc, himself, without major syntax changes. Remember, though, if you're going to make a new compiler with all those features, it will NOT be 100% compatible wth QBasic as it is today. All the lower level stuff would be represented as High-level code that fits into QB, and implemented at "real" low-level ASM. But don't forget, none of your ideas fit with the original idea of BASIC. You can make a new laguage with those features (I'm not gonna help you, I'm to lazy ) but it won't be the same. BASIC was ORIGINALLY DESIGNED to be simple. It was originally designed not to be compiled - but to be interpreted. It was originally designed, not for "true" Programmers, but for college students and others who couldn't understand ASM (which was BASICally the only language that existed). If you make a language like that, and I admit, this is not the 70s and 80s anymore, and QBasic isn't like those languages were, you're still not in BASIC. But I don't entirely agree with na_th_an about it being a C with different syntax; it would be possible to make a totally different language; maybe even better :wink: But you will still have to deal with the polarizing of simplicity versus speed, memory, etc. so which is more important? Would you really be making a new language, or just a new syntax for C? What are the cost versus the benifits - or in other words, is it worth it? I don't know if I agree that compilers are the HARDEST to make in Programming. Personally, I would not want to make an Operating System (although I'm planning to some day - but not in QBasic :lol: ). But I'd say Compilers are in the top 2 hardest to make... and like I said, I'm NOT helping. :lol: so if you wanna make a language, don't ask me for help. Besides, I'm still not sure if I agree with Z!re or na_th_an more... but good look in your friendly debate.

-Written by a 13-year-old 8)
:rotfl: :bounce: :rotfl: :bounce: :rotfl: :bounce: :rotfl:

Quote:Boundary checks, they are good, but really.

A boundary check for this:
a=0

Isn't necessary, the compiler can figure out the constants at compile time. However for the following code:

The compiler cannot check for a possible overflow at compile time, it has to be done at run time. If the user types in some stupidly large number, the runtime system will catch it and give a warning. In a language like C, you don't have a runtime error checker. If you a reading a number from the user, you need to do you own checks on the input to see if it is valid or if you want speed and the possibility of a crash you can omit the checks. The runtime system is part of Basic's philosophy, and also part of what makes it slow.

Quote:Like I said before, error managing, sure, and debugging, it's really good in QB, so, leave it when developing, and have an option called: Compile final version,

You can't remove the runtime error checker from basic anyway because it would break the "on error" exception handler. It is easy enough to write an enclosed program that won't generate errors, but anything that is interactive is always subject to abusive users.

Quote:And noone has answered my question:
FOR a& = -2147483648 TO 2147483647
NEXT

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

What C compiler are you using, if it isn't a 16bit Dos compiler you are comparing apples and oranges for a start. Nothing stops this from being better optomized, except for the fact the Qbasic's compilers were written around 20 years ago. Try the same thing in VB and see if its slow.

If you really want a new basic compiler, you could try one from this list

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

Like, the following code:
FOR a=0 to 128
b=a+a
NEXT

Imagine the number of boundary checks in that, absoluey useless, C compilers don't check, thus faster, QB checks, all the time.

Why not make it check when compiling, if there is no overflow, then don't add boundary checking, but if for example:

a%=983475928374597340927304875230487

The compiler notes, that there is an overflow, AT COMPILE, and returns the error.

What I mean is, that the compiler test-runs the code, (or actually, everything except delays (sleep) and user inputs, obviously this means that do loops would always be boundary checked, if they have a user exit)

And if the code is prone to generate an overflow,. then add an owerflow check.

For example:
input a
for b=0 to 345
a=a+b
next

Would require boundary check, whereas:
a=388
for b=0 to 345
a=a+b
next

Would not.


And if a programmer uses ON ERROR, then just make it do some extended error checking. Perhaps even look up which errors the programmer traps.

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

a=0 will never generate an overflow error, right.


And I'm comparing QB and a 16bit compiler (that i forgot the name of, damit..)
EDIT: Tested it in VB, I quit at ~-200'000, after 3 minutes.
32bit C compiler (Dev-CPP I think, not sure, a friend made me the prog) ~30 sec to complete the whole thing

Here's the prog:
FOR a& = -2147483648 TO 2147483647
b&=a&-b&
NEXT


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


And I know it's hard to write compilers, I'm writing one for Novix, it's really hard, and mine isn't even a "real" (well it is, but well, yeah.. lol) one.


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

And you don't even think about it, WHY would it be impossible to have a compiler, that is 100% QB syntax compatible, but as fast as C (or close too).

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)