[comp.sys.apple] Heartbeat Blues

jb10320@uxa.cso.uiuc.edu (Jawaid Bazyar) (11/29/89)

   I hope someone out there can help me as I've been banging my head for
about a week with this one.
   I wrote a routine to pause X number of tenths of seconds, it's called 
Pause() and it's included in a user tool set.  Pause() calls some Heartbeat
Interrupt handlers I wrote and here is where the trouble starts.
   Pause first calls AddTimer, which creates a new "timer" by giving it
the amount of time to pause.  A routine "DoTimer" is inserted in the Heartbeat
Queue, and is activated every 6 ticks (1/10th second).  DoTimer runs through
the list of timers and decrements each active count.  For example, if I called
Pause(30), AddTimer would create a new timer with a count of 30. After the 30
ticks are up, the timer remains at zero.
   Pause sits in a loop calling CheckTimer, which returns the current
count for a timer. Pause loops until its timer is 0, after which it simply
returns.
   When I call Pause from my program it hangs.  It's not the tool interface-
it's been thoroughly tested from both assembly and a small C program. In these
cases my routine works.  It is only in my large project program that Pause
does not work.  And even stranger, Pause WORKS in my project program if I'm
tracing the code with the Cortland Debugger.
   The system seems to die terribly when Pause is called- using Guy Rice's
Interrupt Detector CDA I've determined that all interrupts cease when Pause
is called (again, it works from debug/trace).
   If it's important the tool code is physically linked to the program. I've
not had a problem with the other several tools I've written and hooked in this
way.
   Is there something strange about the Heartbeat Queue that I'm overlooking?
   Why does my code work when being traced, but not when executed directly?
 
  Thanx for any help anyone can give me. Source available upon request.

--
===============================================================================
jawaid bazyar    jb10320@uxa.cso.uiuc.edu  Junior/Computer Engineering UIUC

         Beneath the noble birth, between the proudest words, 
                behind the beauty, Cracks appear
         Once, with hands held high, they sang out to the sky
		Why do their shadows bow in fear?

jb10320@uxa.cso.uiuc.edu (Jawaid Bazyar) (11/29/89)

   It's strange answering my own question.  It seems a routine called earlier
did a very naughty thing, i.e. SEI.  

   But I still have one question: what does the debugger need interrupts
turned on for? I realize that if I'd been smart I would have looked at the
debugger P-reg display for interrupt information, but it seems silly for the
debugger to force interrupts on.  What if, for instance, there are some
interrupt handlers installed that absolutely should NOT run? Perhaps it's
fixed in a newer version... (I'm still using all the Beta software)

   Oh well. No one ever said interrupts were going to be any fun. 8^)

--
===============================================================================
jawaid bazyar    jb10320@uxa.cso.uiuc.edu  Junior/Computer Engineering UIUC

         Beneath the noble birth, between the proudest words, 
                behind the beauty, Cracks appear
         Once, with hands held high, they sang out to the sky
		Why do their shadows bow in fear?

ericmcg@pro-generic.cts.com (Eric Mcgillicuddy) (12/01/89)

In-Reply-To: message from jb10320@uxa.cso.uiuc.edu

It seems to me the debugger replaces the instruction with a BRK instruction
and then traps the interupt whern it hits it. If the interupt were disabled
would this affect the BRK? I would like to know since I am working with
interupts on my own project and am having a rough time of it.

jb10320@uxa.cso.uiuc.edu (Jawaid Bazyar) (12/02/89)

In article <8222.infoapple.net@pro-generic> ericmcg@pro-generic.cts.com (Eric Mcgillicuddy) writes:
>In-Reply-To: message from jb10320@uxa.cso.uiuc.edu
>
>It seems to me the debugger replaces the instruction with a BRK instruction
>and then traps the interupt whern it hits it. If the interupt were disabled
>would this affect the BRK? I would like to know since I am working with
>interupts on my own project and am having a rough time of it.

   I don't think so.  As far as I've noticed, the debugger breakpoints only
function during a step or trace operation.  I manually use the BRK breakpoint
method when I need to run my code at full-speed.  Even if the debugger worked
that way, a SEI only affects external, hardware IRQs.  BRK being a software
interrupt is not affected. 
   I haven't seen the new debugger (1.1). Does anyone have it?  Is it better?
Will APW ever have symbolic debugging?  The answers to these questions, and
more, tomorrow on "AIIDTS Talks". :-)


--
Jawaid Bazyar               | This message was posted to thousands of machines
Junior/Computer Engineering | throughout the entire civilized world. It cost
jb10320@uxa.cso.uiuc.edu    | the net hundreds, maybe thousands of dollars.