bug 1244: add linked list ddffirst image
[libreriscv.git] / openpower.mdwn
index 614b9c31b12a449c22233ef1fdfccba4ae15a76d..da186f35b69cb6ad4c6d427ea795e555f6f0888e 100644 (file)
@@ -1,19 +1,19 @@
 # OpenPOWER
 
 In the late 1980s [[!wikipedia IBM]] developed a POWER family of processors.
 # OpenPOWER
 
 In the late 1980s [[!wikipedia IBM]] developed a POWER family of processors.
-This evolved to a specification known as the OpenPOWER ISA. In 2019 IBM made the OpenPOWER ISA [[!wikipedia Open_source]], to be looked after by the existing [[!wikipedia OpenPOWER_Foundation]]. Here is a longer history of [[!wikipedia IBM_POWER_microprocessors]]. These IBM proprietary processors 
-happen to implement what is now known as the OpenPOWER ISA. The names
+This evolved to a specification known as the POWER ISA. In 2019 IBM made the POWER ISA [[!wikipedia Open_source]], to be looked after by the existing [[!wikipedia OpenPOWER_Foundation]]. Here is a longer history of [[!wikipedia IBM_POWER_microprocessors]]. These IBM proprietary processors 
+happen to implement what is now known as the POWER ISA. The names
 POWER8, POWER9, POWER10 etc. are product designations equivalent to Intel
 POWER8, POWER9, POWER10 etc. are product designations equivalent to Intel
-i5, i7, i9 etc. and are frequently conflated with versions of the OpenPOWER ISA (v2.08, v3.0, v3.1).
+i5, i7, i9 etc. and are frequently conflated with versions of the POWER ISA (v2.07, v3.0c, v3.1b).
 
 
-Libre-SOC is basing its [[Simple-V Vectorisation|sv]] CPU extensions on OpenPOWER because it wants to be able to specify a machine that can be completely trusted, and because OpenPOWER, thanks to IBM's involvement,
+Libre-SOC is basing its [[Simple-V Vectorisation|sv]] CPU extensions on POWER ISA, because it wants to be able to specify a machine that can be completely trusted, and because POWER, thanks to IBM's involvement,
 is designed for high performance.
 
 See wikipedia page 
 is designed for high performance.
 
 See wikipedia page 
-https://en.m.wikipedia.org/wiki/Power_ISA
+<https://en.m.wikipedia.org/wiki/Power_ISA>
 
 very useful resource describing all assembly instructions
 
 very useful resource describing all assembly instructions
-https://www.ibm.com/docs/en/aix/7.1?topic=reference-instruction-set
+<https://www.ibm.com/docs/en/aix/7.1?topic=reference-instruction-set>
 
 # Evaluation
 
 
 # Evaluation
 
@@ -23,12 +23,15 @@ EULA released! looks good.
 # Links
 
 * OpenPOWER Membership
 # Links
 
 * OpenPOWER Membership
-  <https://openpowerfoundation.org/membership/how-to-join/membership-kit-9-27-16-4/>
+  <https://openpowerfoundation.org/join/>
 * OpenPower HDL Mailing list <http://lists.mailinglist.openpowerfoundation.org/mailman/listinfo/openpower-hdl-cores>
 * [[openpower/isatables]]
 * OpenPower HDL Mailing list <http://lists.mailinglist.openpowerfoundation.org/mailman/listinfo/openpower-hdl-cores>
 * [[openpower/isatables]]
+* [[openpower/whitepapers]]
 * [[openpower/isa]] - pseudo-code extracted from POWER V3.0B PDF spec
 * [[openpower/gem5]]
 * [[openpower/sv]]
 * [[openpower/isa]] - pseudo-code extracted from POWER V3.0B PDF spec
 * [[openpower/gem5]]
 * [[openpower/sv]]
+* [[openpower/prefix_codes]] Decode/encode prefix-codes, used by JPEG, DEFLATE, etc.
+* [[openpower/opcode_regs_deduped]]
 * [[openpower/simd_vsx]]
 * [[openpower/ISA_WG]] - OpenPOWER ISA Working Group
 * [[openpower/pearpc]]
 * [[openpower/simd_vsx]]
 * [[openpower/ISA_WG]] - OpenPOWER ISA Working Group
 * [[openpower/pearpc]]
@@ -78,14 +81,6 @@ Thus it is completely unnecessary to add any vector opcodes - at all -
 saving hugely on both hardware and compiler development time when
 the concept is dropped on top of a pre-existing ISA.
 
 saving hugely on both hardware and compiler development time when
 the concept is dropped on top of a pre-existing ISA.
 
-## Condition Registers
-
-Branch Facility (Section 2.3.1 V2.07B and V3.0B) has 4-bit registers: CR0 and CR1.  When SimpleV is active, it may be better to set CR6 (the Vector CR field) instead.
-
-## Carry
-
-SimpleV extends (wraps) *scalar* opcodes with a hardware-level for-loop. Therefore, each scalar operation with a carry-in and carry-out will **require its own carry in and out bit**. Most sensible location to use is the CRs
-
 # Integer Overflow / Saturate
 
 Typically used on vector operations (audio DSP), it makes no sense to have separate opcodes (Opcode 4 SPE).  To be done instead as CSRs / vector-flags on *standard* arithmetic operations.
 # Integer Overflow / Saturate
 
 Typically used on vector operations (audio DSP), it makes no sense to have separate opcodes (Opcode 4 SPE).  To be done instead as CSRs / vector-flags on *standard* arithmetic operations.