In order to ease porting KeyTech to new hardware, a machine independent debugger is desirable. This proposal provides fairly general access to the machine independent facilities provided by a domain key. The access to the machine dependent facilities (such as registers) is much more limited to ease porting.

Design Alternatives.

There are several design alternatives considered in this design. I would appriecate your opinions whether we should change the design the these areas (or, of course, any others).
The open cell concept from DDT.
This alternative would change the syntax of the Alter Commands.

More general variable names for the Debugger Storage using a record collection for storage.

Using C syntax for expressions.

Using C syntax for gate jumps.

The debugger provides local storage for several kinds of data. The names of these storage locations are a letter designating what kind of location followed by a number from 0 to some implementation limit specifing which specific location is to be accessed. K is used for keys (e.g. k0, k99). S is used for string storage (e.g. s3). The special key variable D is used to specify the current domain. Changing D changes the current domain under consideration by the debugger. The variables D0 through D15 are the general key slots of the domain.
What are the mechanisms for setting and dislaying the debugger storage "cells"? If I do a KC below and put a string into S1, how can I look at it (display it) later?

Is a call to the returner sufficent for this requirement? (Would need to have a returner key handy or built in.) - WSF

Might I suggest a DS format|number command to display a string. I realize that calling returner with %p might apply - ACB

By popular demand see the DE (display expression value) command below. - WSF

Expressions are made up of decimal and hex (starts with 0x) numbers and operators. The operators are a subset of the C operators and use C syntax (ugh!). The operators may include: + - * (both times and prefix indirection) / % ~ & << >> and |. The special variable L is the last address displayed and may be used in expressions.
Can I concatenate and/or split strings in debugger string storage cells?

Not in the current design - WSF

Utility Commands

KC (key, oc) KEYSFROM(pk1,pk2,pk3) STRINGFROM(ps) KEYSTO(rk1,rk2,rk3,rk4) STRINGTO(%p<label>)
This operation calls a key. The keywords are optional and may occur in any order. KEYSFROM may be abbrievated as KF, KEYSTO as KT, STRINGFROM as SF, and STRINGTO as ST. %p causes the returned string to be printed as in the display commands below. <ps> is the passed string specification. It may be a string storage area (e.g. S1), a character string enclosed in double quotes ("), or a hex string starting with 0x. <label> is a debugger string storage area that will be set to the value of the returned string. This string may be passed in a subsiquent call. Either %p, <label>, or both may be specified.
Does not %p need a format specification. ASCII/HEX. I suppose that DUMP format is sufficient if not a little ugly. No big deal . - ACB

We could do what the new command system does. i.e. If the string is all printable characters, then display it as characters, otherwise in dump format. Hex only with no formating to help determine offsets is a bad joke on the user. I think dump only for the initial version is the way to go. - WSF

Is a KEYFORK operations needed/useful?

COPYKEY <inputkey> <outputkey>
Copies <inputkey> to the slot named by <outputkey>.

Is this the list of "things" which can be displayed:] M - memory (data?) address space]
P - program address space]
R - registers]
C - control information]
E - expression

DM <address> <length>

Displays the current domain's data address space for length bytes. Data is displayed in hex with a space between each word (32 bits in the initial version). An ascii interpretation of the data is also provided. The left hand column of each line of the display is the offset (in bytes) of the first byte of the line from the address entered.
Some displays of this kind always start at some "even boundry" (i.e. a multiple of 16, or whatever). This would start with the user supplied address, always?]
Nit, why "M"(memory?) and not "D"(data?)

Always at the user address. I get anoyed at things (like CP) that show me what they want and not what I asked for. - WSF

I have seen displays that nominally align but supply leading blanks on the first line of the display until the requested address comes up. - ACB

The trouble with that approach is frequently you are after consistant offsets in data that is not naturally aligned on word boundries. An example is stepping through the nodes in a node pot. To aid recognization of the fields in a node you would like the start of each node to be in the same place in the display, not marching all over the screen. If you want word aligned displays you can always provide word aligned addresses. - WSF

Would D be better??? - WSF

DP <address> <length>
Displays the current domain's program address space.

DR
Displays all the data returned by a Domain_Get???Registers command. The display format is the same as above.

DC
Displays all the data returned by a Domain_Get???Control command. The display format is the same as above.

DE <expression>
Evaluates <expression> and displays the result. If expression is a word, then its value is displayed in both hex and decimal. If it is a string storage location, then the value is displayed in dump format (as for DM).

AM <address> <data>
Stores in the current domain's data address space at <address>. The <data> stored is either a character string enclosed in double quotes ("), a hex string starting with 0x, an expression (with an assumed length of a word), or a reference to the name of a string storage location. The length stored is the length of <data>.
How portable is "word"? It means 32 bits here?

I am assuming a #define for machine dependencies such as word size. The question in my mind is: Is this debugger, and KeyTech itself, portable to architectures where word size is not a multiple of character size? - WSF

AP <address> <data>
Stores in the current domain's program address space.

AR <offset> <data>
Performs simmilarly to the AM command above. <offset> is the offset in the string returned by a Domain_Get???Registers operation.

AC <offset> <data>
Performs simmilarly to the AM command above. <offset> is the offset in the string returned by a Domain_Get???Control operation. This command may be changed depending on the specific kernel support for changing domain control information.

Most debugger program control operations (e.g. breakpoints) are machine dependent. The only machine independent operation is:

G

Clear the trap code and restart the domain.