March Thirtieth 2009 From: Bob Zale, President PowerBASIC, Inc. PowerBASIC Gazette #66 ====================== Subject: Performance and Debugging ================================== I want it to run FASTER... How do I find that Corruption Bug? Give me the tools to Make It Happen. We listened. We've heard it time and again. In fact, as programmers, we've all said it time and again. Performance and debugging are core issues for us all. The new PowerBASIC recognizes it, and takes another step in the right direction. I'd like to talk to you about #DEBUG DISPLAY, #ALIGN, and #OPTIMIZE. They don't get all the press and general "hoopla...", but they're important new tools in the new PowerBASIC. Take a quick look with me? #DEBUG DISPLAY We've all been there. You put the finishing touches on 25,000 lines of great code. It's been testing great. Virtually foolproof. You know the folks will love it. It's even on schedule. And then it happens... A Crash. The computer hangs. Unexplained, a string gets corrupted. The code takes a wrong path for no apparent reason. Strange things that just shouldn't happen. But they do happen. Usually, at the worst moment. That's memory corruption. Classic symptoms of memory corruption. There are many possible causes... bad assembler code, a stack overflow, RETURN without GOSUB, even mismatched "any" or "optional" parameters. But the real culprit is usually just so simple: You referenced an array outside of its bounds, or you referenced a bad pointer variable. But the insidious part is the timing. It doesn't happen right away. You store a value (A) "out-of-bounds" and it overwrites variable (B). You may execute 200,000 lines of code before (B) is referenced, and that's when you finally notice it! But just how do you go back and trace it to "out-of-bounds" (A)? The short answer is "You Don't". So, you spend hour after hour staring at source code. But 25,000 lines is a lot of source code. In fact, in this case, 1,000 lines is a lot of source code. Hour after hour, you just keep looking. Next, you add more error traps. Lots of "ON ERROR GOTO's" will help, but how can you be sure you covered everything? Every one of those 25,000 lines? Finally, you end up in the PowerBASIC debugger. Line by line, you execute that code in single-steps, until you finally find it. It's true, the debugger will almost always succeed, but think of the time? Strange but true, there was a solution 25 years ago. The old versions of interpreted BASIC were crude, but surprisingly effective on this. What happened when you referenced an array element "out-of-bounds"? The program just stopped running and displayed an error message. Of course, that's not very impressive when your client sees it... but it was great for debugging needs, Each and every time an exception was generated, you were sure to know about it. So, with the new PowerBASIC, we took it one step further. We added an important new tool to help you find these hidden errors. When you're still testing and debugging, just add this option: #DEBUG DISPLAY ON It's totally automatic. It's totally complete. Whenever an "untrapped" error occurs (without the benefit of ON ERROR GOTO, TRY/CATCH, etc.), execution is suspended, and a descriptive message is displayed. The message includes the error number, a brief description of the error, and a label to help you find it. This position descriptor word is the first 8 characters of the name of the most recent label, line number, or procedure that was executed. Two buttons follow, marked "OK" and "Cancel". If "OK" is selected, program execution continues despite the error condition. With "Cancel", program execution is stopped. Another interesting idea is to use #DEBUG DISPLAY before there's a problem. Do all your testing with it enabled, and you're sure to find errors that might have otherwise slipped by. Wouldn't you rather know about them in advance? This is one great new tool, but only during development and debug. Never use it in a production program. #ALIGN Isn't it strange? You work so hard on code to optimize it. Squeeze out every last bit of bloat and wasted cycles. Then you add one more line, or move to a new position, and everything changes. Now, it runs faster. Much faster. Or slower. Just what happened here? Well, usually, it's a hardware thing. Without going into all the gory details about cache and pre-fetch, I'd suggest you just accept it and learn to love it. Use it to your advantage, and you'll stay several steps ahead of the competition. A key component of hardware efficiency is alignment. Computers like neatly aligned code. PowerBASIC converts your BASIC source to machine code with tons of JUMP instructions (the equivalent of a GOTO). Every time they execute, the CPU has to load a group of opcodes at the new location. Since the CPU can only load bytes on a particular power of two boundary (2,4,8,16...), the exact location can be very important. Otherwise, it may take multiple loads while your program just waits... And waits... So, how do you take advantage of this? With most compilers, just forget about it, or use trial and error for the next six months. But, with the new PowerBASIC, just use the #ALIGN directive. Place #ALIGN just before heavily accessed labels and loops (the frequent target of jumps), and you'll often find a big difference. Some loops will actually run 100% faster (or more) with proper alignment! You can specify any power-of-two boundary from 2 to 256, but 16 is a pretty good choice for most modern CPU's. PowerBASIC implements #ALIGN by inserting NOP instructions into the code section to bring the opcode location up to the desired address. If the instruction location is already at a multiple of the boundary you chose, #ALIGN doses nothing. There is a small price to pay for this feature. The NOP instructions take some space, so you may see a small increase in the size of your program. In most cases, that's a very small price to pay for the speed bonus. #OPTIMIZE SIZE | SPEED OK, you read about #ALIGN and you like it. You want the speed bonus, but you don't want to take the time to add all those directives. Why can't it be automatic? With the new PowerBASIC, we can do it for you! Just add the directive #OPTIMIZE SPEED, and PowerBASIC will do its best to improve alignment on most all of the important entry points. It's likely you could make better choices, since you know the important ones, but it will be very beneficial nonetheless. This choice offers other enhancements as well, all designed to create the fastest possible code. The alternative is to specify #OPTIMIZE SIZE (the default) and PowerBASIC will concentrate on making your executable as small as possible instead. ==================================================================== Is your PowerBASIC Gazette Electronic Edition subscription coming to you at home or work? If you don't want to miss a single issue, why not subscribe from both email addresses? Send your subscription request to email@powerbasic.com and please include your name and all email addresses you'd like to add as well as your Zip or Postal Code. If you know someone else who would enjoy this newsletter please forward a copy to them so they can subscribe. ==================================================================== All contents Copyright (c) 2009 PowerBASIC Inc All Rights Reserved. PowerBASIC, PB/CC, PB/DLL, PowerGEN, and PowerTREE are trademarks of PowerBASIC Inc. Other names are trademarks or registered trademarks of their owners. ==================================================================== PowerBASIC Gazette - Electronic Edition Volume 1 - Issue 66 Visit us on the World Wide Web at www.powerbasic.com Email Sales: sales@powerbasic.com This newsletter is only sent to email addresses in our subscription list. If you have received this newsletter by mistake or no longer wish to receive it, please send a simple unsubscribe request to support@powerbasic.com with your name and zip/postal code. This newsletter is best viewed with a fixed-width font. ====================================================================