Path: utzoo!attcan!uunet!mcvax!dutrun!dutesta!franky From: franky@dutesta.UUCP (Frank W. ten Wolde) Newsgroups: comp.sys.ibm.pc Subject: Re: Turbo C Debugger (really: profiling under DOS vs. Unix) Message-ID: <1173@dutesta.UUCP> Date: 11 Jul 88 12:16:02 GMT References: <11590@agate.BERKELEY.EDU> <1803@akgua.ATT.COM> <12338@mimsy.UUCP> <222@ftp.COM> Reply-To: franky@dutesta.UUCP (Frank W. ten Wolde) Organization: Delft University of Technology, Dep. of Electrotechnical engineering. Lines: 68 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 | ##########################################################################