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: 
3587 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 (...) (28 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
    

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