I am trying to get a programming task done using a version of BASIC that produces super-fast code but has a crummy debugger. Execution speed is a big deal for what I’m doing, and I already know how to use this compiler, so I don’t really want to switch. And I don’t particularly like Visual Basic — the obvious alternative — because it’s relatively complex and probably doesn’t produce code that runs as fast.
However, VB has an excellent debugger, and right now I am dead in the water because I can’t figure out how to get a particular bit of code to run. I assume that there is a subtle syntax error or variable mismatch, but my debugger doesn’t provide enough info to diagnose such problems without a lot of trial and error. I don’t think I would have had such a difficult time if I were using VB.
So the tradeoff is between the time I spend debugging and the time I save by using the fast-executing code generated by this hot-shit compiler. Maybe there would be no problem if I were a better programmer, but I’m not, and I’m not sure that I wouldn’t have been better off overall if I had used VB from the start.
I’m also not sure who is the idiot here. Probably it’s me. The compiler designer is merely doing what he does best, he represented the product accurately, and I chose to buy it, so I can’t blame him. But maybe I shouldn’t have been so attracted by the siren song of fast code at the expense of easy debugging. (And maybe I should have realized that a specialized product designed by an individual is likely to have flaws reflecting the designer’s strengths and weaknesses. For example, a brilliant designer of compilers might see less need for a first-class debugger than would a marginal programmer like me.)
Compilers are like vehicles and other technology in that speed is not necessarily the most important feature from a user’s perspective. Speed needs to be balanced against ease of use and other characteristics, and each user will have his own preferred set of tradeoffs.
Why not debug the number crunching part in VB or even good old Quick Basic and transfer back to Powerbasic by cut and paste or text files? Blitzbasic is also good choice for high speed crunching and graphics.
PB code has limited compatibility with MSFT BASICs, so I don’t think it would be worth the trouble. Also, PB does have a debugger, it’s just not as powerful as the VB debugger. But thanks for the suggestions.
I presume you’re working on the code for an electronic voting machine. ;)
How did you know? I am rewriting the current software to incorporate the latest nanotech principles. It’s secret, however, so please don’t tell anyone.
BASIC? Sheesh, if you want speed, program in assembler.
How very annoying. This is why I prefer broadly adopted development platforms (I’m Just Another Perl Hacker, truth be told :-)
I do happen to be into exotic lisp and scheme dialects, and I know the kind of frustration at a small development toolset’s inadequacies.
Chin up, and oh, what kind of problem is it anyway? There may be a better tool to solve it…
Uncle Bill: Thanks for the suggestion but I think you missed my point about not being a good programmer and tradeoffs.
David: I’m doing what I usually do in these situations: putting it aside and working on something else. I don’t know what the problem is. The symptom is that a loop counter doesn’t increment correctly. It feels like a compiler error, but this kind of thing is never a compiler error, it’s always my error. I’ll come back to it later.
Do you have an aliasing problem, where you branch to a different part of the program and change the loop variable? The pattern below caught a lot of people in Fortran…
for i
Not an aliasing problem. I’m missing something simple yet fundamental. For example:
FUNCTION PBMAIN
LOCAL A AS LONG
LOCAL B AS LONG
FOR A = 1 TO 10
B = 2 * A
NEXT A
END FUNCTION
If I run this program in the debugger and step through the loop, the debugger shows the value of A incrementing correctly with each iteration, from 1 through 10. No problem.
But if I remove the operation from within the loop and then step through the program, the debugger shows the value of A decrementing from 10 to 1.
In the actual program, two subroutines are called from within the loop. The value of A that is passed to the subroutines decrements from its terminal value when it should be incrementing from 1.
Note that this behavior occurs with the previous version of this compiler/debugger as well as the one I’m using now. Note also that the debugger compiles the code before running it, so interpretation is not a source of error here.
This has to be something simple yet I don’t see it.
QuickBASIC used to use a STEP keyword.
eg
FOR A=1 TO 10 STEP 2
would repeat at A=1,3,5,7,9
Did, or might, you try that to see if it fixes it?
Thanks. I tried it and it doesn’t work.
The only other thing I can think of is to not use A as a passed variable or in calculations, but copy its value into C and pass that instead.
It looks to me like you’ve got a compiler bug (or feature). My guess is that the compiler thinks that you’re not using the loop index (in your example, A), and is choosing to optimize the loop as a decrement & jump if not zero, rather than an increment & compare against a constant. Your best bet is to copy the loop index into a temporary variable, so that the compiler knows that you’re using the index, and pass the temporary to the subroutine.
If you just assign to the temporary variable, the compiler could notice that the assignment is dead (not used anywhere), optimize out the assignment, and decide that the loop index isn’t used, bringing you back to your original problem.
I think it has to be user error rather than compiler error because 1) I’ve never had this problem before with this compiler and 2) the apparent error occurs in a simple test program as well as in the program that I’m debugging. It may be time to steel myself for humiliation and post a query on the PowerBASIC online forum.