openpower/isans_letter.mdwn

   1 # Letter regarding ISAMUX / NS
   2
   3 Hardware-level dynamic ISA Muxing (also known as ISA Namespaces and ISA
   4 escape-sequencing) is commonly used in instruction sets, in an arbitrary
   5 and ad-hoc fashion, added often on an on-demand basis.  Examples include:
   6
   7 * Setting a SPR to switch the meaning of certain opcodes for Little-Endian
   8 / Big-Endian behaviour (present in POWER and SPARC) * Setting a SPR to
   9 provide "backwards-compatibility" for features from older versions of
  10 an ISA (such as changing to new ratified versions of the IEEE754 standard)
  11
  12 The Libre-SOC team, developing a hybrid CPU-VPU-GPU, needs to add
  13 significantly and strategically to the POWER ISA to support, for example,
  14 Khronos Vulkan IEEE754 Conformance, whilst *at the same time being able
  15 to run full POWER9 compliant instructions*.
  16
  17 There is absolutely no way that we are going to duplicate the
  18 entire FP opcode set as a custom extension to POWER, just to add a
  19 literally-identical suite of FP opcodes that are compliant with the
  20 Khronos Conformance Suites: this would be a significant and irresponsible
  21 use of opcode space.
  22
  23 In addition, as this processor is likely to be used for parallel
  24 compute purposes in high-efficiency environments, we also need to add
  25 FP16 support.  Again: there is no way that we are going to add *triple*
  26 duplicated opcodes to POWER, given that the opcodes needed are absolutely
  27 identical to those that already exist, apart from the FP bitwidth (32
  28 / 64).
  29
  30 There are several other strategically critical uses to which we would
  31 like to put such a scheme (related to power consumption and reducing
  32 throughput bottlenecks needed for heavy-computation workloads in GPU
  33 and VPU scenarios).
  34
  35 In addition, the scheme has several other key advantages over other ISA
  36 "extending" ideas (such as extending the general ISA POWER space to
  37 64 bit) in that, unlike 64 bit opcodes, its judicious and careful use
  38 does not require large increases in I-Cache size because all opcodes,
  39 ultimately, remain 32-bit.  The scheme also allows future *official*
  40 POWER extensions to the ISA - managed by the OpenPOWER Foundation -
  41 to be strategically managed in a controlled, long-term, non-damaging
  42 way to the reputation and stability of OpenPOWER.
  43
  44 Therefore we advocate being able to set "ISAMUX/NS" mode-switching bits
  45 that, like the *existing* LE/BE mode-switching bits, change the behaviour
  46 of *existing* opcodes to an alternative "meaning" (followed by another
  47 mode-switch that returns them to their original meaning. Note: to reduce
  48 binary code-size, alternative schemes include setting a countdown which,
  49 when it expires, automatically disables the requested mode-switch)
  50
  51 Note also that to ensure that kernels and hypervisors are not impacted
  52 by userspace ISAMUX/NS mode-switching, it is critical that Supervisor
  53 and Hypervisor modes have their own completely separate ISAMUX/NS SPRs
  54 (imagine a userspace application setting the LE/BE bit on a global basis,
  55 or setting a global IEEE754 FP Standards compatibility flag).
  56
  57 Further, that Supervisor / Hypervisor modes have access to and control
  58 over userspace ISAMUX/NS SPRs (without themselves being affected by
  59 setting *of* userspace ISAMUX/NS SPRs), in order to be able to correctly
  60 context-switch userspace applications to their correct (former) running
  61 state.
  62
  63 Given the number of mode-switch bits that we anticipate using, we advocate
  64 that such a scheme be formalised, and that the OpenPOWER Foundation be
  65 the "atomic arbiter" similar to IANA and JEDEC in the formal allocation
  66 of mode-switch bits to OpenPOWER implementors.
  67
  68 We envisage that some of these bits will be unary, some will be binary,
  69 some will be allocated for exclusive use by the OpenPOWER Foundation,
  70 some allocated to OpenPOWER Members (by the OpenPOWER Foundation),
  71 and some reserved for "custom and experimentation usage".
  72
  73 (This latter - custom experimentation - to be explicitly documented
  74 that upstream compiler and toolchain support will never, under any
  75 circumstances be accepted by the OpenPOWER Foundation, and that this be
  76 enforced through the EULA and through Trademark law).
  77
  78
  79 However as we are quite new to POWER 3.0B (1300+ page PDF), we do
  80 appreciate that such a formal scheme may already be present in POWER9
  81 3.0B, that we have simply overlooked.
  82