john gilmore wrote:
Ed Jaffe's comments about z/OS alsi values are as usual entirely correct.
As usual too there are other contexts in which IBM publications
discuss architectural levels and use terminology derived from
'architecture' in quite different ways. (Consistency is the hobgoblin
of little minds; is it not?)
What follows is an extract from the current (V3R5) z/OS Enterprise
PL/I Programming Guide. It defines the possible
values---1,2,3,4,5,6---of this compiler's ARCH parameter. (This
compiler shares its code-generation machinery with the corresponding
release of the z/OS C compiler; and these level values are thus
applicable mutatis mutandis to it too.)
ARCH ( n ) The current values that may be specified for the ARCH level
are:
0 Produces code that is executable on all models.
[snip]
6 Produces code that uses instructions available on the 2084-xxx
models in z/Architecture mode. Specifically, the compiler on these
ARCH(6) machines and their follow-ons may exploit the
long-displacement instruction set. The long-displacement facility
provides a 20-bit signed displacement field in 69 previously existing
instructions (by using a previously unused byte in the instructions)
and 44 new instructions. A 20-bit signed displacement allows relative
addressing of up to 524,287 bytes beyond the location designated by a
base register or base and index register pair and up to 524,288 bytes
before that location. The enhanced previously existing instructions
generally are ones that handle 64-bit binary integers. The new
instructions generally are new versions of instructions for 32-bit
binary integers. The new instructions also include v A LOAD BYTE
instruction that sign-extends a byte from storage to form a 32-bit or
64-bit result in a general register v New floating-point LOAD and
STORE instructions The long-displacement facility provides
register-constraint relief by reducing the need for base registers,
code size reduction by allowing fewer instructions to be used, and
additional improved performance through removal of possible
address-generation interlocks.
If you specify an ARCH value less than 2, the compiler will reset it
to 2. Note: The ��x�� in the model numbers above (such as
9672-Rx4 is a ��wildcard�� and stands for any alphanumeric machine of
that type, such as 9627-RA4).Note: Code that is compiled at ARCH(n)
runs on machines in the ARCH(m) group if and only if m >= n.
And the system's ARCHLVL= parameter adds even more confusion! ARCHLVL=1
is ESA/390. In OS/390 V2R10, this meant any machine with ALS1 or ALS2
support. In z/OS, this applies only to machines with ALS2 support.
ARCHLVL=2 is z/Architecture. This means the minimum z900 instruction set
supported by z900. The same applies to the ARCHLVL= parameter on the
SYSSTATE macro. In that case, ARCHLVL=0 implies machines that do not
support the relative & immediate facility -- i.e. those before 9672-G2
which do not support ALS1, ARCHLVL=1 implies ALS1 & higher machines in
ESA/390 mode, and ARCHLVL=2 implies z/Architecture as implemented on the
z900. Sheesh!
--
.-----------------------------------------------------------------.
| Edward E. Jaffe | |
| Mgr, Research & Development | [EMAIL PROTECTED] |
| Phoenix Software International | Tel: (310) 338-0400 x318 |
| 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801 |
| Los Angeles, CA 90045 | http://www.phoenixsoftware.com |
'-----------------------------------------------------------------'
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
