\documentstyle[urg]{article} % see urg.sty for details \begin{document} \issueno{0064} % This should always be 4 digits. \version{2} % This should be an integer. \date{91-06-12} % The editor, uiref and airef are optional. Thus if you do not define them, % they will not appear in the title. \editor{David Emery} %\airef{key AI references, if relevant} % All references to AI here and in the document should have the form % AI-xxxxx where x is a digit (5 digits) \uiref{UI-0012, UI-0015, UI-0043, UI-0065} % All references to UI here and in the document should have the form % UI-xxxx where x is a digit (4 digits) % The following are not optional and will appear in the title. They have all % been given default values so as to prevent LATEX from raising errors. \title{Address Arithmetic Operations} \section{13} \history{To be developed, Jan 90; To be discussed (a very rough draft), June 90; To be discussed, Sept 90; Agreed in principle, June 91} \shorteditor{D.Emery} \shorttitle{Address Arithmetic Operations} \status{Agreed in principle} % create and print the documents title (i.e. all the above) \maketitle % The remaining sections are constructed using the following environments % Some helpful notes on the layout of how we like the material prepared:- % If any part of the sections are listed by use of numbers or letters, % then the listed part should be enclosed by % \begin{enumerate} % % \end{enumerate} % and replace each number/letter in the list with \item % If a piece of program text is displayed, then the text % should be enclosed by % \begin{verbatim} % % \end{verbatim} % This will display the text in a typewritten text form. % If a reserved word or a variable from the program text is used % in the document, then it should be enclosed by {\tt } % This will display the word in a typewritten text form. % If the underscore _ is used in variables within {\tt }, % then it must be preceded by \ % Take care of double quote marks - use two single left(``) or right('') % quote marks and not the double quote mark("). \begin{issue} A standard syntax/specification for Address Arithmetic is needed. \end{issue} \begin{recommendation} The type {\tt SYSTEM.ADDRESS} shall not be a limited private type. {\tt SYSTEM.ADDRESS} may be a private type (recommended), an integer type, or a composite type (e.g. record type). Assignment, equality and inequality shall be supported on {\tt SYSTEM.ADDRESS}. The type {\tt ADDRESS\_OFFSET} shall be declared as an integer type (either signed or unsigned), with an implementation-defined range including the value 0. An implementation may support negative values in {\tt ADDRESS\_OFFSET}, but is not required to do so. For any of these operations (including the relational operators), an implementation is permitted to raise {\tt ADDRESS\_ERROR} if no reasonable interpretation of the requested operation exists on the machine. The following declarations shall be included in package {\tt SYSTEM}: \begin{verbatim} ADDRESS_ERROR : exception; type ADDRESS_OFFSET is ; -- this must be an integral type including the value 0 -- Note: Any of these operations may raise ADDRESS_ERROR if the -- resulting value either is out of range (e.g. a "negative -- address" on a machine where that makes no sense, or where -- the resulting value is not legal during program execution -- (e.g. an address that is not included in the address space of -- the program during execution.) function "+" (LEFT : ADDRESS; RIGHT : ADDRESS_OFFSET) return ADDRESS; function "+" (LEFT : ADDRESS_OFFSET; RIGHT: ADDRESS) return ADDRESS; function "-" (LEFT : ADDRESS; RIGHT : ADDRESS_OFFSET) return ADDRESS; function "-" (LEFT : ADDRESS; RIGHT : ADDRESS) return ADDRESS_OFFSET; --for instance: size := stop_address - start_address function "mod" (LEFT : ADDRESS; RIGHT : POSITIVE) return ADDRESS_OFFSET; --for instance: byte_offset_in_word := object'address mod 4 function "<" (LEFT : ADDRESS; RIGHT : ADDRESS) return BOOLEAN; function ">=" (LEFT : ADDRESS; RIGHT : ADDRESS) return BOOLEAN; function ">" (LEFT : ADDRESS; RIGHT :ADDRESS) return BOOLEAN; function ">=" (LEFT : ADDRESS; RIGHT : ADDRESS) return BOOLEAN; function IMAGE (ADDR : ADDRESS) return STRING; function VALUE (STR : STRING) return ADDRESS; \end{verbatim} The following relationships must hold for {\tt "+"}, {\tt "-"} and {\tt "mod"} ({\tt ADDRESS\_OFFSET'(0)} is the identity value for address arithmetic): \begin{verbatim} for all addresses X: X = X + ADDRESS_OFFSET'(0) X = ADDRESS_OFFSET'(0) + X X = X - ADDRESS_OFFSET'(0) \end{verbatim} The following relationship must hold for the {\tt IMAGE} and {\tt VALUE} functions: \begin{verbatim} for all addresses X: X = VALUE(IMAGE(X)) \end{verbatim} Note that the format of the string returned by {\tt IMAGE} is not defined by this UI. The implementation should document the format of the string returned by the {\tt IMAGE} function (and the string accepted by the {\tt VALUE} function). An implementation may add other operations on {\tt ADDRESS} and {\tt ADDRESS\_OFFSET} to this package. \end{recommendation} \begin{discussion} The type {\tt ADDRESS} is restricted by this UI from being a limited private type. In other words, the type {\tt ADDRESS} must directly support assignment and equality. (The reason is that the rest of this UI has little practical utility if one cannot store values of type {\tt ADDRESS}.) This UI permits the type {\tt ADDRESS} to be an integer type, but this is not recommended. The reason for this is to prevent problems in resolving overloading with respect to the integer operators. If {\tt ADDRESS} is an integer type and declarations in {\tt SYSTEM} are directly visible, the following call cannot be resolved: \begin{verbatim} NEW_ADDR := ADDR + 3; \end{verbatim} The underlying notion here is that addresses are ordered and enumerable, in the sense that one can talk about ``the address after this one'' or ``the address two values away from this one''. So the proposal is to do ``offset arithmetic'' on addresses. Thus {\tt "+"}, and {\tt "-"} take an address and an offset and return an address. {\tt "mod"} also provides an offset in some sense. The version of {\tt "-"} that operates on two addresses returns the distance between the two addresses, yet another offset (from one to the other). Finally, the relational functions complete the abstraction of ordering on addresses. To represent the valid values of offsets, the type {\tt ADDRESS\_OFFSET} is defined by this UI. {\tt ADDRESS\_OFFSET} must be an integral type, and types derived from the pre-defined integer types or types defined from some implementation-defined type (in particular, unsigned types) are permitted by this UI. The operations on this type are the usual operations on integers, including the arithmetic and relational operators and the pre-defined attributes. Note that some of these operations may not make sense in all cases on all machines. For instance, given a segmented machine such as the i386 in protected mode, there is no particular meaning in comparing two addresses in two different segments. But, comparing two addresses in the same segment is quite well defined. Hence these operations may raise {\tt ADDRESS\_ERROR} at any time. The implementation needs to explain the conditions where {\tt ADDRESS\_ERROR} may be raised. One item not included in this proposal is any mechanism for converting integers to addresses. This is deliberate. In some sense, one can convert an address to an integer via \begin{verbatim} INT := INTEGER("-" (LEFT => THE_ADDRESS, RIGHT => ADDRESS_OFFSET'(0))); \end{verbatim} and can convert an integer to an address via \begin{verbatim} ADDR := "+" (LEFT => NULL_ADDRESS, RIGHT => ADDRESS_OFFSET(THE_INTEGER)); \end{verbatim} However, these operations are not well-defined by this UI, and the resulting values may not have any real meaning. It is useful to provide a mechanism for printing out the value of an address, and the {\tt IMAGE} function is provided for this. Furthermore, the {\tt VALUE} function will return a value of type {\tt ADDRESS} given a (well-formed) string. The form of the string returned by {\tt IMAGE} (and accepted by {\tt VALUE}) is not defined by this UI. If addresses are actually integer values, then it would make sense for the implementation to define {\tt IMAGE} and {\tt VALUE} in terms of the integer attributes {\tt 'IMAGE} and {\tt 'VALUE}. The reason for this UI is to support a common syntax for address arithmetic. The utility of this syntax is to support portability of code using address arithmetic across compilers on the same architecture. There is no intent that this UI guarantee the `universal' semantics of address arithmetic across all machine architectures. However, most architectures have a reasonable interpretation for address arithmetic, which can be supported by this package. \end{discussion} \begin{practice} Verdix has everything but {\tt "mod"} on the Sun ({\tt ADDRESS} is private), and Alsys includes {\tt "mod"} on the Sun ({\tt ADDRESS} is private). Both systems provide a way to convert a numeric quantity into an address. Meridian on the PC declares {\tt ADDRESS} to be an integer type, so all integer arithmetic operations are available on these values. DEC Ada provides {\tt "+"}, {\tt "-"} and the relational operations ({\tt ADDRESS} is private). Telesoft on the Sun treats {\tt ADDRESS} as an access type ({\tt ADDRESS} is access {\tt INTEGER}), so no arithmetic or relational operators are available. \end{practice} %\begin{Appendix} %other supporting information %\end{Appendix} \end{document}