Aron_Fingers_Nelson@cup.portal.com (09/10/87)
To all,
I just thought that you all might like knowing about this.
If any of you are on compuserve, you might want to suggest that
he keep on developing this program. Since I am not on compuserve could
anyone monitoring David's Tcdebug explorations keep me informed?
David is the same programmer that wrote Tdebug plus and it is a very
good T-pascal debugger. (2.0 should be great!) Hope he keeps
on developing Tcdebug.
He has my support!
Aron_fingers_nelson@cup.portal.com
August 9, 1987
TCdebug Version 0.00
(C) Copyright 1987 by L. David Baldwin.
All Rights Reserved.
Further copyright information given below
OVERVIEW
TCdebug is an experimental source code debugger for use in debugging Turbo
C (tm) Programs on the IBM-PC (tm). Its goal is to allow source code
debugging in all of Turbo C's memory models and with most of the possible
compile and link options. TCdebug allows you to:
1. View your source code (and, optionally, the assembly language
code) while debugging.
2. Trace the operation of your program by source code lines or by
assembly language instructions.
3. Insert breakpoints in your program by function name, by line
number, or hexadecimal address.
4. Examine (and change) simple global variables by symbolic name.
Local variables may also be examined and changed, but require that
the proper displacement on the stack be known.
5. Set up a Watch window to keep continuous tabs on a variable.
TCdebug is not a finished program. It is being released at this time to
get an indication of interest and to obtain assistance in finding bugs and
problems which are probably numerous at this time.
TCdebug is designed exclusively for debugging Turbo C programs. It should
not be used on programs generated by other compilers.
SYSTEM REQUIREMENTS
1. An IBM-PC, AT, or compatible. Screen compatibility is a must.
2. PC-DOS 2.0 or above.
3. Approximately 128k more memory than would normally be required to
run the program to be tested.
PREPARATION
TCdebug requires that a Map file for your program be present to supply
information on the program symbols and line number locations. When
compiling and linking with TC, the options can be set with O/C/C/L and
O/L/M/P. With TCC use -M and -y.
1
When starting a debugging session, the following files should be on the
default drive:
PROG.EXE (or, optionally, .COM for the Tiny Model)
PROG.MAP the map file
various.C all the source files for the program (or at least all that
will be accessed.)
OPERATION
TCdebug may be started by entering the filename of the program to be
debugged and any parameters that the program requires on the command line
as:
TCdebug PROG <other stuff>
Here, PROG is the name of the program to be tested with EXE being the
default extension. <other stuff> will be passed on to PROG as its command
line when execution begins. If TCdebug is called without parameters, a
request will be made for them.
When execution begins, TCdebug loads the Map file, the EXE file and reports
some facts about the program. Note should be made of whether pointers are
regarded as Near or Far by default as this will be important when
displaying pointers later.
After "hitting any key", the program is executed to "main()" and the
debugging screen appears. The debugging screen is divided into two parts.
The lower section is the command and data section. The '*' is a prompt for
one of the commands described later. The top part of the screen displays
the program source code text which at this point will be centered at the
first statement in main(). Source code line number appear on the left and
the current line (the one to be executed next) is highlighted.
Dividing the two portions of the debugging screen is a line which shows the
name of the source file presently displayed.
Two keys which can be tried at this point are the F9 and F10 keys. The
F9 key toggles into and out of the assembly mode. When in assembly mode,
the assembly language instructions of the program are displayed with the
source code lines interspersed. The F10 key toggles between the debugger
screen and the screen which receives program output.
SPECIAL KEYS FOR VIEWING TEXT
The following keys may be used to change the text being displayed:
Pg Up
Pg Dn Move the display up or down one page.
2
^Pg Up
^Pg Dn Move to the start or end of the current file.
Up arrow
Down arrow Scroll up or down one line.
^Left Arrow (with Scroll Lock on)
^Right Arrow (with Scroll Lock on)
Scroll horizontally left and right.
F9 key Toggle in and out of assembly mode.
F10 key Toggle between the debug screen and the screen
of the program under test.
In addition, the text being displayed may be changed using the View command
described later.
COMMAND EDITOR
Commands are entered at the '*' prompt. When entering commands, the
following keys may used to edit the command: (They perform the same
functions as they do in the Turbo C editor.)
^A,^S,^D,^F,^G,^T,^H,^V,^Y,LFARW,RTARW,^LFARW,^RTARW,
Ins, Del, Backspace
The Insert mode (default) is indicated by a slightly fatter cursor. The
cursor is normal in the Overwrite mode.
In addition, a stack of the last 6 commands (those having more than 3
characters) is maintained. The F3 key accesses the stored commands from
the most recent to the oldest and the F5 key accesses them in the reverse
order. These old commands may be used as is or may be modified by editing
them.
Note that commands are not acted upon until the Enter key is hit. (The
cursor does not have to be at the line end to enter the command.)
COMMAND PARAMETERS
TCdebug uses one or two letter commands. The command is often followed by
one or more parameters. Parameters are delimited from the command and each
other using spaces. The one exception to this is the format parameter
which is preceded by a comma. The parameters which may be used are:
3
<Symbol>
A C source code symbol representing a function name or variable as
appropriate. The leading underbar added by the compiler has been
stripped off, so symbols are entered exactly as used in the source
program. Case is significant.
<Line Number>
Line numbers are entered as <filename>\<number> as:
myprog.c\345
In most cases, the <filename> part can be dropped. An entry of the
form
\345
implies line number 345 in the currently displayed source file.
(Currently, the '\' also may be dropped and a simple decimal entry will
do. However, the '\' may be required in future versions.)
<Hexaddress>
Normal numerical entry in TCdebug is decimal with hex entries allowed
by preceding them with '0x'. However, numerical address entries must
be entered in hex to distinguish them from line numbers. A
<hexaddress> takes the following form:
0x1234:0x1ABC
es:bx+2
SS:BP-0X5a
As indicated above, register names are allowed in address
specifications. The _current_ value in the register is used--the
address does not change if the register value later changes. The
segment part of the <hexaddress> may be dropped as in:
bp-0xA
0x123
bx
If no segment is present in the entry, there is an implied segment.
The rules for determining the implied segment are:
1. If the BP register is used, SS is implied.
2. If BX,SI,DI are used (but not BP), DS is implied.
3. If none of the above and a data entry is expected, DS is implied.
4. If a code address is expected, the current CS is implied.
<Format>
Format parameters are entered as one or two letters preceded by a
comma. Case is significant. The purpose of the <format> parameter is
to inform TCdebug of the size and type of a variable as this
information is not available in the Map file. <format> parameters
correspond to those used in the C 'printf' and 'scanf' functions.
4
Currently supported are:
c,s,i,d,u,x,X,o,p,g,G,li,ld,lx,lX,lo,Np,Fp,lg,lG
For the p (pointer) format, the default pointer size for the selected
memory model is used. This size is indicated in the information
presented at startup. To override the default, use either N or F as
appropriate.
The c (character) format has been used as a catchall for byte size
items. Display is in quoted character form, decimal, and hex. Change
entries may be made using any of those forms.
COMMANDS
G (Go)
Format:
G [<parameter> [<parameter..]]
The Go command starts execution of the program under test. Execution
will continue until a breakpoint is reached or the program terminates.
One or more breakpoints may be entered with the Go command. These
breakpoints are called temporary breakpoints as they are in effect only
until the first stopping point is reached. Any temporary breakpoint
would then have to reentered with the next Go command if desired.
Examples:
G Start execution with no temporary breakpoints. (There might be
some permanent breakpoints, however.)
G \345 funct1 0x113
Start execution with temporary breakpoints at line number 345, at
the start of function, funct1, and at address CS:0x113. In
addition, there might be other permanent breakpoints in effect.
T (Trace)
Format:
T (or F7 key)
In source code mode, execute the code on the current line. Execution
will stop at the next encountered line number. If the current line
contains a function call, the break will be at the start of the
function.
In assembly mode (assembly code is displayed), execute the next assembly
language instruction.
5
N (Next)
Format:
N (or F8 key)
In source code mode, execute the code on the current line in its
entirety. In assembly mode, this command currently does nothing.
The difference between the Trace and the Next command is that if the
current line contains a function call, Next will completely execute the
function whereas Trace will Trace through the function.
P (Permanent breakpoint)
Format:
[-]P [<parameter>]
The P command is used to specify permanent breakpoints. Unlike temporary
breakpoints, permanent breakpoints remain in effect until removed (using
a '-' preceding the P command).
If no parameter is entered, the breakpoints in effect are listed.
Passcounts are not implemented at this time.
Examples:
P List all permanent breakpoints.
-P Delete all permanent breakpoints.
P moda.c\345 Install a breakpoint at line 345 in file moda.c.
-P funct1 Remove a breakpoint at function funct1.
P 0x34b Install a breakpoint at CS:034B.
V (View text)
Format:
V [<parameter>]
The View command may be used to change the text being observed
in the text window. If no parameter is entered, the text will
be centered around the current line.
Examples:
V initscreens View text at function initscreens.
V \545 View text around line 545.
6
VF (View File)
Format:
VF <filename>
The View command is for viewing the program source files. The VF
command allows any ASCII file to be displayed.
You Get the Idea!!!!!
Guess you can reach him at Balwin, COmpuserve ID # 76327,53.darrylo@hpsrlc.UUCP (09/11/87)
In comp.sys.ibm.pc, Aron_Fingers_Nelson@cup.portal.com writes: > To all, > > I just thought that you all might like knowing about this. > If any of you are on compuserve, you might want to suggest that > he keep on developing this program. Since I am not on compuserve could > anyone monitoring David's Tcdebug explorations keep me informed? > David is the same programmer that wrote Tdebug plus and it is a very > good T-pascal debugger. (2.0 should be great!) Hope he keeps > on developing Tcdebug. > He has my support! > > Aron_fingers_nelson@cup.portal.com > > August 9, 1987 [ ... ] > I'd like to point out that, as the program is in the testing stage (i.e., users are really testers at this point), TCDEBUG can, CURRENTLY, only be downloaded from Compuserve. IT CANNOT BE UPLOADED TO OTHER BULLETIN BOARDS, USENET, ETC.. The reason for this is to prevent (well, try to prevent) people from distributing "pre-release" versions all over the known world. Apparently, Dave Baldwin has had problems with early released versions of his other programs; to this day, people ask him questions about these early versions (e.g., he receives complains about bugs in these early versions, bugs which have been fixed in the current ones). I imagine that, once TCDEBUG has been debugged, these distribution restrictions will be lifted, and people will then be free to distribute TCDEBUG. -- Darryl Okahata {hplabs!hpcea!, hpfcla!} hpsrla!darrylo CompuServe: 75206,3074 Disclaimer: the above is the author's personal opinion and is not the opinion or policy of his employer or of the little green men that have been following him all day.
hollen@mana.megatek.uucp (Dion Hollenbeck) (09/17/87)
In article <3320053@hpsrlc.HP.COM> darrylo@hpsrlc.HP.COM (Darryl Okahata) writes: >In comp.sys.ibm.pc, Aron_Fingers_Nelson@cup.portal.com writes: > >> To all, >> >> I just thought that you all might like knowing about this. >> If any of you are on compuserve, you might want to suggest that >> he keep on developing this program. Since I am not on compuserve could >> anyone monitoring David's Tcdebug explorations keep me informed? Could anyone monitoring this on Compuserve please post progress to the net and not merely reply to Aron_Fingers_Nelson. I am sure there are lots of us who would be interested in Turbo C if only there were a debugger available. Thanks in advance. Dion Hollenbeck (619) 455-5590 x2814 Megatek Corporation, 9645 Scranton Road, San Diego, CA 92121 { sdcsvax!sdcc6 | hp-sdd | seismo!s3sun } !megatek!hollen
williamo@hpcupt1.HP.COM (William O'Saughnessy) (06/15/88)
A turbo C debugger was posted about 2 or 3 months ago. I think it came from Waterloo. It works and is a lot better than none. You might also ask on "*lang.c*". Good Luck.
jeff@cdp.UUCP (06/15/88)
I've seen at least two shareware debuggers for Turbo C. One is
from David Baldwin (CompuServe #76327,53); the other is from
SAYSoft (14938 Kimberley, Houston, TX 77079). The former
package is apparently free and provides a nice full screen
interface (vaguely like CodeView). The latter has a $25
registration fee and has a somewhat easier to learn command
structure, but does not step thru code very nicely (it is almost
"tty like"). Both are available on various bulletin boards.
Jeff Dean
{hplabs,parcvax}!cdp!jeffnelson@sun.soe.clarkson.edu (Russ Nelson) (06/15/88)
In article <5930008@hpcupt1.HP.COM> williamo@hpcupt1.HP.COM (William O'Saughnessy) writes: >A turbo C debugger was posted about 2 or 3 months ago. I think it came >from Waterloo. It works and is a lot better than none. You might also >ask on "*lang.c*". Good Luck. TCDEBUG.ARC was written by Dave Baldwin. The canonical place to find it is Compu$erve. I posted it to comp.binaries.ibm.pc, and it's on the c.b.i.p archive machine. Either call (315)268-6667 (3/12/24, 8N1) and look in the Turbo C area, or anonymous ftp to grape.ecs.clarkson.edu [128.153.13.196] and look in file/turboc/tcdebug.arc. The c.b.i.p archives are in file/binaries. In both places, get 'files.bbs' for a short description of the files. -- signed char *reply-to-russ(int real_network) { /* Why can't BITNET use */ if (!real_network) return "NELSON@CLUTX"; /* TCP/IP? */ else return "nelson@clutx.clarkson.edu"; }
stephen@tolerant.UUCP (Yeung) (06/16/88)
From article <5930008@hpcupt1.HP.COM>, by williamo@hpcupt1.HP.COM (William O'Saughnessy): > A turbo C debugger was posted about 2 or 3 months ago. I think it came > from Waterloo. It works and is a lot better than none. You might also > ask on "*lang.c*". Good Luck. Was it posted at source code level, or binaries only? In any case, would someone please either re-post or send me a copy? Thanks! -- ------------------------------------------------------------------------ H. Stephen Au-Yeung ucbvax!hplabs!pyramid!voder!tolerant!stephen Tolerant Systems, Inc. 81 E Daggett Dr, San Jose CA 95134 408-433-5588
musson@usdtsg.Dayton.NCR.COM (Scott Musson) (06/17/88)
In article <1722@tolerant.UUCP> stephen@tolerant.UUCP (Yeung) writes: >From article <5930008@hpcupt1.HP.COM>, by williamo@hpcupt1.HP.COM (William O'Saughnessy): >> A turbo C debugger was posted about 2 or 3 months ago. I think it came > >Was it posted at source code level, or binaries only? In any case, would >someone please either re-post or send me a copy? Thanks! >H. Stephen Au-Yeung ucbvax!hplabs!pyramid!voder!tolerant!stephen Me too please.... it would be greatly appreciated. Thanks. -- Scott Musson || musson@usdtsg.Dayton.NCR.COM NCR Corp. SDC-5 || Telephone 513-445-7766 Dayton, Ohio 45419 || If you don't like it...don't read it!!
wew@naucse.UUCP (Bill Wilson) (06/17/88)
Could someone please report this debugger. Our copy came in bad.
--
Bill Wilson (Bitnet: ucc2wew@nauvm)
Northern AZ Univ
Flagstaff, AZ 86011
{These views are mine and do not necessarily reflect those of my employer}boba@hpwala.HP.COM (Bob Alexander) (06/17/88)
In article <733@naucse.UUCP> wew@naucse.UUCP (Bill Wilson) writes: >Could someone please report this debugger. Our copy came in bad. I second (third?) the request. - Bob "just bought Turbo C" Alexander
eudes@occam.uucp (Jacques EUDES) (06/22/88)
In article <1722@tolerant.UUCP> stephen@tolerant.UUCP (Yeung) writes: >From article <5930008@hpcupt1.HP.COM>, by williamo@hpcupt1.HP.COM (William O'Saughnessy): >> A turbo C debugger was posted about 2 or 3 months ago. I think it came > >Was it posted at source code level, or binaries only? In any case, would >someone please either re-post or send me a copy? Thanks! >H. Stephen Au-Yeung ucbvax!hplabs!pyramid!voder!tolerant!stephen Me too please.... it would be greatly appreciated. Thanks. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | Jacques Eudes | 76.51.46.00 poste 5130 | eudes@occam.imag.fr | | L.G.I. I.M.A.G. BP 53 X 38041 GRENOBLE CEDEX FRANCE | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | Jacques Eudes | 76.51.46.00 poste 5130 | eudes@occam.imag.fr | | L.G.I. I.M.A.G. BP 53 X 38041 GRENOBLE CEDEX FRANCE | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
brb@akgua.ATT.COM (Brian R. Bainter) (07/01/88)
From article <3143@imag.imag.fr>, by eudes@occam.uucp (Jacques EUDES): In article <1722@tolerant.UUCP> stephen@tolerant.UUCP (Yeung) writes: >From article <5930008@hpcupt1.HP.COM>, by williamo@hpcupt1.HP.COM (William O'Saughnessy): >> A turbo C debugger was posted about 2 or 3 months ago. I think it came > >Was it posted at source code level, or binaries only? In any case, would >someone please either re-post or send me a copy? Thanks! >H. Stephen Au-Yeung ucbvax!hplabs!pyramid!voder!tolerant!stephen > I saw one in binaries yesterday that I pulled off. It was version 1.1. Should be the latest and greatest. From what I have seen of it, it also does profiling. Things are getting better and better.
dbraun@cadavr.intel.com (Doug Braun ~) (07/02/88)
A long time ago (around the beginning of the year) I saw in a Borland ad that new products "based on their advanced debugger technology" would be available the second quarter of the year. Since then, I haven't seen or heard another word on this subject. Does anyone know what Borland's plans are (if any) for releasing an "official" Turbo C debugger? To get a really good debugger, the compiler has to be enhanced to output the right info into object files. This means that there is a lot the current 3rd party debuggers just cannot do. Doug Braun Intel Corp CAD 408 765-4279 / decwrl \ | hplabs | -| oliveb |- !intelca!mipos3!cadev4!dbraun | amd | \ qantel /
ked@garnet.berkeley.edu (Earl H. Kinmonth) (07/03/88)
>I saw one in binaries yesterday that I pulled off. It was version 1.1. >Should be the latest and greatest. From what I have seen of it, it also >does profiling. Things are getting better and better. The profiler is pretty dumb compared to that available for **IX systems.
uh@materna.uucp (Uwe Hoch) (07/04/88)
In article <1801@akgua.ATT.COM> brb@akgua.ATT.COM (Brian R. Bainter) writes: >From article <3143@imag.imag.fr>, by eudes@occam.uucp (Jacques EUDES): > In article <1722@tolerant.UUCP> stephen@tolerant.UUCP (Yeung) writes: >>From article <5930008@hpcupt1.HP.COM>, by williamo@hpcupt1.HP.COM (William O'Saughnessy): >>> A turbo C debugger was posted about 2 or 3 months ago. I think it came >> >>Was it posted at source code level, or binaries only? In any case, would >>someone please either re-post or send me a copy? Thanks! >>H. Stephen Au-Yeung ucbvax!hplabs!pyramid!voder!tolerant!stephen >> >I saw one in binaries yesterday that I pulled off. It was version 1.1. >Should be the latest and greatest. From what I have seen of it, it also >does profiling. Things are getting better and better. Why are thos nice things not posted to comp.sources.ibm.pc or comp.binaries.ibm.pc. If someone gets a copy of the debugger, please mail it to me too. Many thanks in advance!! Uwe Hoch Dr. Materna GmbH Vosskuhle 38 D-4600 Dortmund 1 West Germany E-Mail: USENET: uh@materna.uucp ..!seismo!mcvax!unido!materna!uh
uh@materna.uucp (Uwe Hoch) (07/05/88)
In article <369@materna.uucp> uh@materna.UUCP (Uwe Hoch) writes: > >Why are thos nice things not posted to comp.sources.ibm.pc or >comp.binaries.ibm.pc. If someone gets a copy of the debugger, please >mail it to me too. Many thanks in advance!! > >Uwe Hoch Ok, forget it, I just found the stuff in comp.binaries.ibm.pc. I think I was complaining a little bit too early. Uwe Hoch Dr. Materna GmbH Vosskuhle 38 D-4600 Dortmund 1 West Germany E-Mail: USENET: uh@materna.uucp ..!seismo!mcvax!unido!materna!uh
brb@akgua.ATT.COM (Brian R. Bainter) (07/06/88)
From article <2525@mipos3.intel.com>, by dbraun@cadavr.intel.com (Doug Braun ~): > A long time ago (around the beginning of the year) I saw in a > Borland ad that new products "based on their advanced debugger > technology" would be available the second quarter of the year. > Since then, I haven't seen or heard another word on this subject. > Does anyone know what Borland's plans are (if any) for releasing > an "official" Turbo C debugger? To get a really good debugger, > the compiler has to be enhanced to output the right info into > object files. This means that there is a lot the current > 3rd party debuggers just cannot do. > > Doug Braun Intel Corp CAD > 408 765-4279 I talked with Borland on the phone the other day when I was ordering my 1.5 upgrade for Turbo C, and I asked them if the new debugger was out yet. They told me that it was not. When I asked them when it would be out they said that they didn't know and said something like it was in beta test. According to what I was told in January, they were in beta test then. Your guess is as good as mine. Brian
brb@akgua.ATT.COM (Brian R. Bainter) (07/06/88)
From article <11590@agate.BERKELEY.EDU>, by ked@garnet.berkeley.edu (Earl H. Kinmonth): >>From what I have seen of it, it also >>does profiling. Things are getting better and better. > > The profiler is pretty dumb compared to that available for **IX > systems. In case you havn't noticed, DOS (unfortunately) is not anywhere near **IX. Get real!
jds@mimsy.UUCP (James da Silva) (07/07/88)
In article <1803@akgua.ATT.COM> brb@akgua.ATT.COM (Brian R. Bainter) writes: >From article <11590@agate.BERKELEY.EDU>, by ked@garnet.berkeley.edu (Earl H. Kinmonth): >>>From what I have seen of it, it also >>>does profiling. Things are getting better and better. >> >> The profiler is pretty dumb compared to that available for **IX >> systems. > >In case you havn't noticed, DOS (unfortunately) is not anywhere >near **IX. Get real! Actually, Brian, a DOS Compiler has the potential to blow away any Unix-based compiler in the area of profiling; DOS's main weakness is a strength when it comes to profiling. The lack of multitasking and protection allow you to get very accurate results free of any distortions. The PC's clock chip keeps track of time in 1 microsecond increments. This counter can be read (for example) at the entry and exit of each C function. With a little more work the compiler can determine the exact net time (the time spent executing inside the function) and gross time (the time spent in the function + in any functions called) for each function. Gprof, on the other hand, has to make the best of the relatively coarse sampling done by the kernel combined with the call graphs it constructs to *estimate* the amount of each function's time to attribute to the calling functions, based on the relative number of calls made. Unfortunately, I have yet to see a compiler that takes full advantage of the PC's clock chip to construct a really great profiler. - Jaime ---------------------------------------------------------------------- usenet: uunet!mimsy!jds James da Silva internet: jds@mimsy.umd.edu "Stand on each other's shoulders, not on each other's toes."
ked@garnet.berkeley.edu (Earl H. Kinmonth) (07/07/88)
In article <1803@akgua.ATT.COM> brb@akgua.ATT.COM (Brian R. Bainter) writes: >From article <11590@agate.BERKELEY.EDU>, by ked@garnet.berkeley.edu (Earl H. Kinmonth): >>>From what I have seen of it, it also >>>does profiling. Things are getting better and better. >> >> The profiler is pretty dumb compared to that available for **IX >> systems. > >In case you havn't noticed, DOS (unfortunately) is not anywhere >near **IX. Get real! There are profilers available for MSDOS that offer a reasonably close approximation to the profiling available under *IX, for example the prof program with the MKS Toolkit. Get educated!
nelson@sun.soe.clarkson.edu (Russ Nelson) (07/07/88)
In article <12338@mimsy.UUCP> jds@mimsy.umd.edu (James da Silva) writes: >Actually, Brian, a DOS Compiler has the potential to blow away any Unix-based >compiler in the area of profiling; DOS's main weakness is a strength when it >comes to profiling. > >The lack of multitasking and protection allow you to get very accurate >results free of any distortions. ... The following package is on the comp.binaries.ibm.pc archive machine, grape.ecs.clarkson.edu [128.153.13.196] under file/turboc/tchrt.arc. Grape.ecs is also the CUHUG Fido BBS, (315)268-6667, 300/1200/2400 8N1. TCHRT Turbo C High Resolution Timer Version 1.01 18 May 1988 --------------------------------------------------------------- TCHRT is a library of subroutines that implement a very high resolution timing function. With suitable statements added to an application's source code, a very accurate profile of the application's execution time can be generated that provides the developer with a clear picture of what parts of the application code are taking the most time to execute. With this information, an application's "hot spots" can quickly be determined and algorithm or assembly code optimization can be implemented to increase performance. Some significant features of TCHRT are: - Timing accuracy to one microsecond. This accuracy is independant of execution environment (PC, AT, 386) so long as the hardware is 100% IBM PC compatible. The timing software calibrates itself to the host processor speed, so absolute accuracy is maintained regardless of host CPU and it's associated clock rate. - User definable profiling. Source code statements are added by the user to time those areas of the application that are of interest. Only two source code statements are required to time any portion of the application, and up to 100 different parts of the application may be timed. Unlike "binning" profilers that report only sampled "hits" on a range of CPU Program Counter (PC) addresses, TCHRT allows the user to profile any part of an application's source code, down to a single statement or procdure call. Unlike "binning" profilers, there is an exact one to one correspond- ance between the profiler's result and source code statements. - A complete summary of the profiler's results is generated. This summary can be automatically sent to the CRT display, a printer, or a disk file. Multiple summary reports can be generated during a single run to show changes in performance as an application's runtime parameters are dynamically changed. - No side effects during application execution. Unlike many profilers, the application "wall clock" execution time does not significantly change when TCHRT is active. Also unlike many profilers, the system's timer interupt (1C hex) is not altered, so the system clock is not disturbed. Normal interupts continue at their usual rate. Requirements ------------ 100% hardware compatible IBM PC, AT or 386 microcomputer. PS/2 machines have not been tested - reports regarding PS/2 compati- bility are welcome! Borland Turbo C V1.5. TC V1.0 has not been tested, but will probably work. -- Pray that Bush gets re-elected so that the Republicans will be blamed for it.
dab@ftp.COM (Dave Bridgham) (07/07/88)
In article <12338@mimsy.UUCP> jds@mimsy.UUCP (James da Silva) writes:
The lack of multitasking and protection allow you to get very accurate
results free of any distortions. The PC's clock chip keeps track of time in
1 microsecond increments. This counter can be read (for example) at the
entry and exit of each C function.
While the timer chip does have a 16 bit counter that's being
incremented about once a microsecond, there's a problem. The chip has
a bug. When you read that counter what you get is the value shifted
left one bit. In other words, you lose the most significant bit. I
kludged around this problem by comparing the current value of the
counter with the value I read on the previous call. If it's less and
I havn't taken a timer interrupt in between, then I set the high bit
on the value I return. This of course isn't guarenteed to work, but
if the routine is called often enough (more than every 27
milliseconds) then it should stay accurate. If anyone knows a way
around this bug in the chip, I'd really like to hear about it.
David Bridghamevas@euraiv1.UUCP (Eelco van Asperen) (07/09/88)
in article <12338@mimsy.UUCP>, jds@mimsy.UUCP (James da Silva) says: > Actually, Brian, a DOS Compiler has the potential to blow away any Unix-based > compiler in the area of profiling; DOS's main weakness is a strength when it > comes to profiling. ... > Unfortunately, I have yet to see a compiler that takes full advantage of > the PC's clock chip to construct a really great profiler. Yeah, and it's so easy to create a few routines to manipulate the clock chip and do profiling. I've created a small package based on the Unix 'cb' program to modify C source-code; at the start and end of each function, function-calls are made to signal entry and leave of the function. This is not perfect of course; if the 'return'-statement of a function contains stuff that takes a lot of time, that time is not added to the function's running time but to it's caller. Here's what a small function would look like after modification; int small(int hello) { int PROFdummy_var = PROFstart(); int alfa; .... if (alfa) { PROFend(); return hello; } { PROFend(); return -1; } } The 'int PROFdummy_var =' statement is used to include the time spent in initialization. I run the clock at 4659 ticks per second, ie. 18.2 * 256 Hz. Unfortunately, I can't distribute the code because it is a hacked version of 'cb' and runs on a Unix box here (yes, we have a real AT&T source license). How about it, Borland, Microsoft ? Give us either built-in profiling or the option to call special functions on entry & leave of functions. Eelco van Asperen. ---------------------------- uucp: evas@eurtrx or: mcvax!eurtrx!evas earn/bitnet: asperen@hroeur5 ---------------------------- #include <stdjunk.h> #include <inews/filler.h>
franky@dutesta.UUCP (Frank W. ten Wolde) (07/11/88)
In article <222@ftp.COM> dab@ftp.COM (Dave Bridgham) writes: >In article <12338@mimsy.UUCP> jds@mimsy.UUCP (James da Silva) writes: > > The lack of multitasking and protection allow you to get very accurate > results free of any distortions. The PC's clock chip keeps track of time in > 1 microsecond increments. This counter can be read (for example) at the > entry and exit of each C function. > >While the timer chip does have a 16 bit counter that's being >incremented about once a microsecond, there's a problem. The chip has >a bug. When you read that counter what you get is the value shifted >left one bit. In other words, you lose the most significant bit. I >kludged around this problem by comparing the current value of the >counter with the value I read on the previous call. If it's less and >I havn't taken a timer interrupt in between, then I set the high bit >on the value I return. This of course isn't guarenteed to work, but >if the routine is called often enough (more than every 27 >milliseconds) then it should stay accurate. If anyone knows a way >around this bug in the chip, I'd really like to hear about it. > > David Bridgham I'm not quite sure if you're talking about the 8253 timer chip, but if you do this might help: The 8253 can operate in 6 modes. Currently it is configured to run in mode 3 (square wave rate generator). In this mode, the count value is decremented by *2* for every clock pulse input. When the counter reaches zero, its output state is toggled and the counter is reloaded to its initial value. Since the IBM PC interrupt lines are edge sensitive, this would produce an interrupt every 2 countdown cycles of double decrements. This means that in between two interrupts the counter reaches each count value twice (causing ambiguous readings). The solution is to change the counter's mode to mode 2 (rate generator). The count value is now decremented by *1* on each count input pulse. When the counter reaches the value 1 its output changes from high to low and stays low for the duration of *one* input clock pulse. Using this mode, the interrupt rate is not changed, however, in between two interrupts only one count-down cycle takes place, yielding unambiguous count read-outs. The following (assembler) code will put timer 0 of the 8253 in mode 2: mov al,34H ; timer 0; mode 2; binary count out 43H,al ; port address 8253- mode register xor ax,ax ; load count value (low byte first) out 40H,al ; timer 0 counter register out 40H,al If you are interested in our source code (assembler routines to link with microsoft C), please let us now via E-mail. Hope this has been helpful, Paul E. Schuurmans, Frank W. ten Wolde. E-mail: dutesta!franky -- ########################################################################## Frank ten Wolde | UUCP: ..!mcvax!dutrun!dutesta!franky Delft University of Technology | Faculty of Electrical Engineering | Delft | The Netherlands | ##########################################################################
mcdonald@uxe.cso.uiuc.edu (07/13/88)
Since the topic seems to have shifted to profilers rather than debuggers, I should say that I found a neat profiler called "Inside!" from a company called Paradigm on Bix. This is of course a crippled version, but it profiled all the programs I fed it quite nicely. There are versions for several compilers. For Microsoft C you want the Quick C version, even if you don't really use Quick C. The crippled version is actually rather small: about 35K .exe file. Doug McDonald