[FreeVMS] FreeVMS thought of the day....

[Roger Tucker]

Here is my thought of today, please feel free to comment...
(I may do one of theses each day until I run out of thoughts… :-)

After much reading, I am somewhat convinced that FreeVMS should eventually
be targeted for the IA-32e CPU (a IA-32 bit CPU with 64 bit extensions) for
the following reasons.  I'm hoping this will start a discussion in this
area.

1.  IA-32e has several features that may make writing FreeVMS easier:

	a. IA-32e has an new IPL register (CR8, also called the TPR – task
priority register) that controls the interrupt priority level.
          So a MOV CR8 instruction can be used to raise or lower IPL.
            This can also be done with a normal IA-32 but it is
implementation dependent and depends on the APIC.
            The CR8/TPR is part of the IA-32e architecture.

	b. IA-32e has 8 more 64 bit general purpose registers (R8-R15).

	c. IA-32e has a 64 bit instruction and stack pointer.

	d. fast SYSCALL/SYSRET support is IA-32e (64-bit mode only).

	e. In IA-32e mode, segmentation is generally (but not completely)
disabled, creating a flat 64-bit linear-address space.
          (segment bases of CS,DS,ES,SS are considered zero.)
          Code segments and their associated descriptors and selectors are
still needed to establish mode and privilege level.

    See: ftp://download.intel.com/technology/64bitextensions/

2. IA-32e CPUs allows FreeVMS to match Alpha and later releases of OpenVMS
that support 64 bit addressing.

3. Last but not least, at this rate, when FreeVMS is running and stable
IA-32e CPUs will be the norm rather than the exception.

All this being said, I think we should stay with 32 bit IA-32 CPUs as long
as possible since most of us don't have access to IA-32e CPUs yet...  :-(

Linux runs on tons of different CPUs, but I think FreeVMS should be more
limited in the hardware that is supported to make it easier to maintain and
support, so once we make the jump to 64 bits we should stay there and not
try to support both.  (just my opinion to keep things simpler, because I
think too much complexity is one problem with Linux, and complexity is our
enemy.)

Just thinking,
OK - back to coding,
Roger