Development of functionality and features beyond Bob's editing role.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
iQEVAwUAT6MAGVudqy9GNsiIAQLNfQf6A1ea2aD58oU+qUEyxn6srzNrNIAK1lV/
LTN0sA29VOKGMGxhTicYM3UQJfhF+o4Q4NPy1L6XleiQeQcnWCPrw2B+03Ava1Ri
aQwMVy9Tth9byVX251+N59cZ7PBxdgFC7B6A2mCdcjWN2YryLH9v/4cns73nPVZ+
phaJnFGyKK1e7zqJKql2PM5e1TPVci5nt1e/MQ6ZRGngl4M4FCjUGMu4QWywA9JL
6CsjI9a1MAlJvcSila2e7sE+BkFlpk28bTz4wxGtLk/zincW/hWFgaLmGtQDZj/c
nUj7rWoeb4vunb9RoaX483aFBDEaK/SgWdcO8jEfWGu+9z+tg5qmdA==
=ziw3
-----END PGP SIGNATURE-----
Added SET ON, SET NOON, ON, GOTO and RETURN command support
The ControlFlow changes fix a potential bug in breakpoint handling
which arguably merely could be “not supported”. That bug is that if
a breakpoint’s actions have multiple actions AND an action early in
the list invokes a do command file, the subsequent pending breakpoint
actions are not performed.
The ControlFlow patch/changes implement the following extensions to
the SCP command language without affecting prior behavior:
GOTO <Label> Command is now available. Labels are lines in which the first non whitespace character is a “:”. The target of a goto is the first matching label in the current do command file which is encountered. Since labels don’t do anything else besides being the targets of goto’s, they could be used to provide comments in do command files, for example (“:: This is a comment”)
SET ON Enables error trapping for currently defined traps (by ON commands)
SET NOON Disables error trapping for currently defined traps (by ON commands)
RETURN Return from the current do command file execution with the status from the last executed command
RETURN <statusvalue> Return from the current do command file execution with the indicated status. Status can be a number or a SCPE_<conditionname> name string.
ON <statusvalue> commandtoprocess{; additionalcommandtoprocess}
Sets the action(s) to take when the specific error status is returned by a command in the currently running do command file. Multiple actions can be specified with each delimited by a semicolon character (just like breakpoint action commands).
ON ERROR commandtoprocess{; additionalcommandtoprocess}
Sets the default action(s) to take when any otherwise unspecified error status is returned by a command in the currently running do command file. Multiple actions can be specified with each delimited by a semicolon character (just like breakpoint action commands).
ON <statusvalue>
ON ERROR Clears the default actions to take when any otherwise unspecified error status is returned by a command in the currently running do command file.
Error traps can be taken for any command which returns a status other
than SCPE_STEP, SCPE_OK, and SCPE_EXIT.
ON Traps can specify any status value from the following list:
NXM, UNATT, IOERR, CSUM, FMT, NOATT, OPENERR, MEM, ARG, STEP,
UNK, RO, INCOMP, STOP, TTIERR, TTOERR, EOF, REL, NOPARAM, ALATT,
TIMER, SIGERR, TTYERR, SUB, NOFNC, UDIS, NORO, INVSW, MISVAL,
2FARG, 2MARG, NXDEV, NXUN, NXREG, NXPAR, NEST, IERR, MTRLNT,
LOST, TTMO, STALL, AFAIL.
These values can be indicated by name or by their internal numeric
value (not recommended).
Interactions with ASSERT command and “DO –e”:
DO –e is equivalent to SET ON, which by itself it equivalent
to “SET ON; ON ERROR RETURN”.
ASSERT failure have several different actions:
If error trapping is not enabled then AFAIL causes exit from the current
do command file.
If error trapping is enabled and an explicit “ON AFAIL” action is defined,
then the specified action is performed.
If error trapping is enabled and no “ON AFAIL” action is defined, then
an AFAIL causes exit from the current do command file.
Other related changes/extensions:
• The “!” command (execute a command on the local OS), now returns
the command’s exit status as the status from the “!” command.
This allows ON conditions to handle error status responses from
OS commands and act as desired.
• Argument substitution has been extended for do command file
execution. The extended argument substitution include
substitution of any program environment variable (referenced by
%ENVVARNAME%) along with dynamic expansion of several pseudo
environment variables:
%DATE% expands to a string of the form: yyyy/mm/dd (i.e. 2011/01/23)
%TIME% expands to a string of the form: hh:mm:ss (i.e. 17:23:44)
%CTIME% expands to a string of the form: www mmm dd hh:mm:ss yyyy
(i.e. Mon Jan 24 08:22:33 2010)
%ENVNAME% expands to a string which has the value of the environment
variable ENVNAME
4 files changed