To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.robotics.rcx.legosOpen lugnet.robotics.rcx.legos in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Robotics / RCX / legOS / 60
59  |  61
Subject: 
Re: Debugging
Newsgroups: 
lugnet.robotics.rcx.legos
Date: 
Wed, 17 Mar 1999 19:40:15 GMT
Viewed: 
1238 times
  
Lou Sortman <lou_sortman@servicemerchandise.com> wrote:

Alternatively, you could just change tm_switcher() to ignore tasks that are
in a 'P_SUSPENDED' state or something like that.

The simplicity of that approach could well be worth the trivial drop in performance
vs the separate queue approach.

It's what I'm doing for now in my debugger work.  I haven't tried it out
yet, though.

I'll be interested in seeing if you can make breakpoints work.  I can't think
of an easy way with the available hardware.

The best I could come up with was to overwrite the instruction with a jump
to itself, and when the scheduler reschedules a task, it would check if it
was stopped on this instruction; and if it was it would tell the denugger.

On this architecture, are all instructions the same length as the mentioned jump (or
longer)?   (I don't have the manual handy.)  If so, this does seem like a good way
to do it.  The scheduler could dereference the stack pointer and see if it points to
(or just past) that opcode, and only (take the time to) scan the breakpoint list if
it does.  I am assuming that a jump to one's own address is going to be a relative
jump, and, therefore, always the same byte sequence.

I carefully looked at the opcodes, and found that the shortest opcodes are
all 2 bytes, and hand-coded the 2 byte instruction that jumps to itself.
The scheduler can do exactly as you said, and actually I was thinking that
it would just suspend the task and somehow notify the debug task, who
would be responsible for scanning the breakpoint list.  Yes, it is a
relative jump.

-Matt



Message is in Reply To:
  Re: Debugging
 
(...) However, last night, I wrote a brute force (spin loop) msleep which works fine in the scheduler. I found that 800 iterations of an empty for loop with a 16 bit index comes pretty close to 1ms. Granted, I cheated a little, knowing that the (...) (26 years ago, 17-Mar-99, to lugnet.robotics.rcx.legos)

7 Messages in This Thread:


Entire Thread on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact
    

Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR