newRPL: [UPDATED April 27-2017] Firmware for testing available for download
|
01-24-2017, 01:48 PM
(This post was last modified: 01-24-2017 01:54 PM by Claudio L..)
Post: #528
|
|||
|
|||
RE: newRPL: [UPDATED December-29-16] Firmware for testing available for download
(01-24-2017 06:17 AM)The Shadow Wrote: Pity, I actually prefer it the old way. But then, when I cut my teeth on RPL, I imbibed the idea that one was supposed to avoid local variables wherever possible. newRPL's philosophy is taking some adjustment.In general, I protected all list processing commands from doing "damage" outside of processing the list. But then this was before I had 8-levels of stack undo in place, perhaps I need to rethink this and remove the protection, since now you can go back to the stack with a single key stroke. (01-24-2017 06:17 AM)The Shadow Wrote:Quote:The compiler optimization when I made the compiler fully re-entrant, and the error handling in STREAM and all other list processing commands when I added conditional breakpoints. EDIT: I just realized this went out in the last release, you CAN test it! There's quite a few improvements to the debug mechanism that allows: a) Hardware-based HALT and AUTORESUME operations: For example, alarms can be triggered in the middle of your code (not yet implemented). If an alarm is triggered while you are running a program, the program is HALTed, the action for the alarm takes place (whether it is displaying a message or running a program), and then the program autoresumes like nothing happened. Timers also come to mind as a future implementation (same as alarms, really). b) All normal debugging commands HALT, CONT, KILL are implemented in a compatible way. Also SST and SST[down arrow] do the same as usual. c) Conditional breakpoints: To set a breakpoint you need to provide: << program to debug >> Offset (an integer) << condition program >> (optional) The command SETBKPOINT will "set" the breakpoint, CLRBKPOINT will remove it. The arguments are as follows: << program to debug >> is any code or subroutine you want the breakpoint to be triggered on. Offset is an index (1 to N) to provide a more specific location within the program. Consider the program as a list, when the Instruction Pointer is in front of, or within the object at index N, it will evaluate the condition to see if it needs to halt or not. Using an offset of 0 the breakpoint could trigger anywhere inside the given program. The condition program is any arbitrary program that returns true/false (1 or 0) to the stack, but makes no other modifications to it. 1 means HALT, 0 means condition not met. This argument is optional, if it's not given then the breakpoint always triggers (it's the same as giving the condition program << 1 >>. Then you run your program normally (no need to use DBUG or anything). When the IP reaches the specified location, the condition program will be executed. Because the condition program is running within the halted program, it has access to all local variables, including the counters inside a FOR loop, etc. Once the breakpoint triggers, the program is HALTED the same as a HALT command. Unlike the static nature of HALT, you can now redefine (and/or move) the breakpoint while the program is halted, then keep debugging. By the way, when a program is halted, you have access from the stack to all local variables: If you do << 34 'X' LSTO HALT >> Then X on the stack will recall 34. Trying to STO to X will overwrite the local copy, not the global variable. The variable will go out of scope on CONT or KILL. I'm thinking there could be a LVARS menu that shows local variables when halted. Also, there could be (should be?) a real interactive in-calc code debugger in the (not immediate) future. |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 3 Guest(s)