From @mail.uunet.ca:beejay@micor Thu Apr 8 18:03:58 1993 Received: from calvin.sfasu.edu by umaxc.weeg.uiowa.edu (5.61.jnf/920629) on Thu, 8 Apr 93 18:03:45 -0500 id AA13365 with SMTP Received: from ghost.uunet.ca (uunet.ca) by calvin.sfasu.EDU with SMTP (5.59/25-eef) id AA00754; Thu, 8 Apr 93 17:55:26 CDT Return-Path: <@mail.uunet.ca:beejay@micor> Received: from ocunix by mail.uunet.ca with UUCP id <10501(4)>; Thu, 8 Apr 1993 18:45:58 -0400 Received: by micor.OCUnix.On.Ca (smail2.5) id AA02700; 8 Apr 93 17:07:08 EDT (Thu) To: hyperc-l@calvin.sfasu.edu Subject: New products Date: Thu, 8 Apr 1993 13:07:06 -0400 Message-Id: <9304081707.AA02698@micor.OCUnix.On.Ca> From: beejay@micor.ocunix.on.ca (Basil Johnson) Status: R A HyperC product announcement ============================= DEBUG - the prologue As an assembly language programmer, my most favourite software tool is Bugbyter. I couldn't work without it. I'm now teaching myself C using HyperC. Let me tell you, making the change hasn't been fun. As a C newbie I am prone to making errors and having to contend with HyperC's many quirks without so basic a tool as a symbolic debugger in my arsenal is running my nerves ragged. Since I know of nobody who has a HyperC debugger, then we must all be relying on the most primitive tool available for debugging a C program: the ubiquitous printf() function. We must place debugging printf() statements in our source at strategic points where we need to monitor variables. When we have squashed the bug(s), we remove the now extraneous printf() statements. We can of course avoid removing the debugging printf() statements if we set a DEBUG flag and make their execution conditional on the flag, i.e. #if debug .... #endif. As a C newbie feeling his way through the language, and not writing anything more than short, text-based, teletype-display programs, I tolerate printf(). Barely. Accustomed to GUI type menus, help screens etc,. in my assembly programming, I am ever mindful that someday I would be writing these type of interfaces in C, and debugging printf() statements would be clobbering my screen. A debugger was the first item on my wish list of HyperC projects. But I don't yet have the C smarts to write one. Nobody has made my wish come true, so, I have been looking for code for a debugger that maybe a few more knowledgable people could port. During my search, I came upon Thomas D. Webb's DEBUG (Computer Language, February 1986). Neither its size nor the code looked like it would overwhelm me so I decided to quietly port it to HyperC. No vapourware from this guy. Now that I'm alpha testing, I can say that the HyperC community will soon have a limited debugger and I can tell you about it. DEBUG - what it isn't! ---------------------- It still isn't what I want. It doesn't provide for setting break points and monitoring registers. It doesn't have run-time variable modification or program flow modification. So the hunt is still on. If you come across code for a debugger, send it to me. I may not be able to port it, but I'll learn a lot by just trying. After reading the rest of this, if you are interested in beta-testing DEBUG when it is ready, fill in the profile request and email it to me. DEBUG - what it is! ------------------- With DEBUG, this is the minimum you do to use it. (1) add '#include debug.h' to your program (2) include a #define DEBUG statement either in your program or in the debug.h header file (3) add a call in your program to DEBUG's control function, inkey() (4) place special debugging statements at the strategic points in your program as you would with a debugging printf() (5) link debug.o with the rest of your application module(s). Macros defined in debug.h are the basis for the special debugging statements you will put in your program. They cover each data type. For example, if you want to confirm that within the function getname(), the string variable, 'string' is "hello, world", you could place in your program these debug statements: TS("-----Now in getname()------", ">>>>>>>>>"); // code to do a variety of things // TS("Testing string", string); // TS("-----Leaving getname()------", "<<<<<<<<"); Some other debug statements are TC, TI, TUD, TLD and TLH. So, like printf(), you must modify your program when using DEBUG but with a bit of elegance. Just one line instead of three. However, the big advantage over the printf() way is that your program's display on the text screen is preserved. Sorry, no graphics! The results of your debug statements are displayed in a different window in a single step mode. The debug window is divided into two blocks: 40 columns wide by 23 lines. The left hand block holds the text you supplied as the first argument to the macro, e.g. TS(). The right hand block holds the value of each target variable you are tracing or an explicit assignment, as with "<<<<<<<<" above. When a debug statement is executed the result is displayed in the debug window on the last line. Following on with the above example, this would appear on line 24 (1-24): -----Now in getname()------ >>>>>>>>> DEBUG waits while you review the results. Press any key to return to the program window where program execution continues in real-time until the next debug statement is encountered. The debug window reappears looking partly like this. -----Now in getname()------ >>>>>>>>> this on line 23 Testing string hello, world this on line 24 The display of the last debug execution has now been bumped up one line. So, you have a history of the results of all your debug statements to that point in the trace. The first result in the Trace_Table will scroll off the screen after 23 statements have been processed. Only the most recent 23 statements will be visible. In a future update, I may make the Trace_Table larger, provide a paging capability or allow the trace to be written to a file for later review. At any point while the debug window is visible, you can disable DEBUG and revert to full program control by pressing OpenApple-T [Escape-T for ][+]. This instruction is permanently shown on the top line in the debug window. The DEBUG variable, 'trace_sw' is a toggle switch that turns DEBUG on and off. Theoretically, you could insert a statement like trace_sw = ON in your program and DEBUG would be invoked; trace_sw = OFF to disable it. Types, what types? ------------------ The released version of DEBUG will allow you to display variables of all types supported by standard HyperC. This specifically includes char, char[], int, unsigned, long and short. TC("user_text", char_variable); TS("user_text", string_variable); TI("user_text", int_variable); TUD("user_text", unsigned_variable); When tracing a long or short in your program, you would use one of the following debug statements to trace it since HyperC doesn't make a distinction between int, short and long. TI("user_text", short_variable); TUD("user_text", long_variable); In addition, DEBUG supports LINT (array of 2 longs). The type 'long' is not supported in any other form because HyperC's printf() and sprintf() do not support '%ld' as a conversion format string. Variables of type LINT can be displayed in either hexadecimal or decimal (an ASCII string). TLD("user_text", LINT_variable); /* print as decimal */ TLH("user_text", LINT_variable); /* print as hexadecimal */ DEBUG will also support the types EXTENDED, DOUBLE, SINGLE and COMP as used in the floating point package. Such variables are declared in the form, fpType(floating_point_number). e.g. f = Extended(12.978). DEBUG commands you place in your programs to trace/ display these are: TFE("user_text", Extended_fp_var); /* floating point */ TFS("user_text", Single_fp_var); /* single precision fp */ TFD("user_text", Double_fp_var); /* double precision fp */ TFC("user_text", Comp_fp_var); /* compound integer */ TFLD("user_text", Extended_fp_var); /* 32 bit int - decimal */ TFLH("user_text", Extended_fp_var); /* 32 bit int - hex */ DEBUG does not support auxfp, simply because I haven't got around to trying it out, yet. Display of variables -------------------- Characters and strings are of course displayed as ASCII characters. Data type int is displayed in decimal. LINT variables can be displayed in either decimal or hexadecimal. The unsigned data type is currently displayed in decimal. I anticipate adding a TUH to provide a choice for those of us who prefer to think in hexadecimal. I may do that before DEBUG is released. The code that displays a LINT variable in decimal form depends on the fptostr() function. I would very much like to remove this dependency before the release. If someone has a C routine that can convert a 32 bit hex number in the form: low_word high_word to a decimal string without leading zeroes, please email me. All the floating point data types that can be assigned (Extended, Double, Single and Comp) have their results displayed in decimal when the corresponding TFE, TFD, TFS and TFC macros are used. They use the floating point fptostr() function. An additional pair of macros is for only those occasions when an Extended() is used for a LONG assignment. These, TFLH and TFLD are for hexadecimal and decimal output respectively. The fptostr() function in the floating point package allows you to choose between decimal and exponent notation and the number of decimal places to display is selectable. However, you get 6 decimal places if you put 0 in the parameter list. DEBUG does not currently provide a choice for either of these. For EXTENDED, DOUBLE and SINGLE precision variables, the exponent notation flag is set to 'NO' and the number of decimal places is fixed at 6. I don't see any reason at this time to make these dynamic. But I'm open to change if there is an overwhelming demand for these features. In a later release, I could add these parameters in the trace commands for these three fpType variables. e.g. TFE("user_text", extended_fp_var, decplaces, [NO|YES]); fptostr() displays a leading space for positive numbers and '-' for negatives ones. DEBUG retains this for EXTENDED, SINGLE and DOUBLE type variables only. DEBUG philosophy is that COMP and LONG are integral. Accordingly, these types are displayed as positive numbers without (a) preceeding spaces or (b) trailing decimal point or zeroes, unlike the floating point package. Anticipating that those who use HCsys16 may need to display a 32 bit number in hexadecimal, I have also provided another debug statement: TFLH("user_text", Extended_fp_var); /* LONG */. This differs from TFLD() only in output format. As I said, this is primarily for the 16 bitters, but 8 bitters can also use it without any repercussions. It can safely be used instead of TLH with DEBUG. I doubt very much that the fp package is used very often. Likewise, I don't expect the floating point capabilities of DEBUG to be widely used. Furthermore, there is a considerable amount of overhead (6k) resulting from the necessary inclusion of sane.o and fp65.o from the floating point package. So why does DEBUG support floating point, you ask? Frankly, Webb's program provided it, albeit with a compiler in which it was natural and its printf() and sprintf() supported '0L' and '%ld'. But it was also a challenge and an opportunity to learn about HyperC's floating point package. It was frustrating but rewarding. In the final analysis, the HyperC community has a 'symbolic' debugger that covers the full realm of data types. Nevertheless, in addition to DEBUG, I plan to release DEBUGLITE which will use only the standard HyperC and provide support for tracing char, int, unsigned and LINT variables. However, as mentioned previously, displaying LINT variables in decimal depends on the fp package and so, this will not be available if I don't get the routine I'm seeking. Release schedule 1. Product Announcement - April 8, 1993 2. DEBUG Beta release distribution - April 20, 1993 3. Demo - April 20, 1993 4. Final beta reports due - May 30, 1993 5. Product release - between May 30, 1993 and June 15, 1993 depending on beta-testing reports. There are only 40 days between the beta release date and the scheduled report date. It seems short, but I'm betting that any beta-tester who is writing an application will immediately start using DEBUG when he gets it and DEBUG will therefore get a good shakedown. As indicated above, a demo wil be released at the same time as the beta. This will be distributed to all on the hyperc-l mailing list. Beta- testers will recieve the module that they can link with their programs and the most current documentation. Wanna be a tester? I'm looking for a good mix of testers. From a hardware perspective, I will need at least one person with a IIgs, II+, IIc, //e and Laser. I'll need someone who's using the 65802. In terms of shells, I'll need to test its compatibility with Opix and HCsys16(?) in addition to the standard opsys/shell. I haven't started using Opix yet and I don't use HCsys16(I don't have a 65802). And if you are developing software which does a lot of screen writes, windows, menus etc,. or uses the HyperC floating point package, you are a good bet to get the nod as a beta-tester. Beta-tester profile ------------------- Computer [IIgs, //e, II+, IIc, Laser] CPU [6502, 65c02, 65802, 65816] opsys [opsys, opix, hcsys16] current development project features: - describe the project and uniqueness from a video output viewpoint. - anything else you care to mention. Complete the above and email it to me if you are interested in being a DEBUG beta-tester. Apply only if you are serious in spending some time with this software. Selection as a tester is not automatic. Late acknowledgement: I just realized that the version of Debug now in alpha test will not work with the Videx 80 column card. I can fix it but that would likely delay the release. So the ][+/Videx will not be supported in the initial release. Basil Johnson UUCP: micor!beejay |Oh, Fate! ... Nepean, Ontario InterNet: |Such a stupid thing: CANADA K2B 8E9 beejay@micor.ocunix.on.ca |Command a bird to fly (613) 820-0804 |Then clip its wing!