[Libre-soc-bugs] [Bug 602] New: low performance bare minimum functionality SIMD emulator required

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=602

            Bug ID: 602
           Summary: low performance bare minimum functionality SIMD
                    emulator required
           Product: Libre-SOC's first SoC
           Version: unspecified
          Hardware: Other
                OS: Linux
            Status: CONFIRMED
          Severity: enhancement
          Priority: ---
         Component: Source Code
          Assignee: lkcl at lkcl.net
          Reporter: lkcl at lkcl.net
                CC: libre-soc-bugs at lists.libre-soc.org
   NLnet milestone: ---

CRITICAL NOTE: THERE IS NO INTENTION OF ANY KIND OR IMPLICATION OF ANY KIND TO
ADOPT VSX.

please do NOT use this bugreport to discuss, promote or advocate adoption of
VSX in LibreSOC, in any way shape or form, including but not limited to changes
in register file formats, ordering, or hardware changes of any kind that would
imply that VSX *might* be adopted at some future point.

see https://www.sigarch.org/simd-instructions-considered-harmful/ and please
consider SIMD literally to be harmful to implement.


the purpose of this bugreport is to act as a stop-gap measure due to an
unforseen consequence of SIMD being made mandatory in ELF v2, some years ago.

ELF v1.5 (with 1.9 addendum to 64 bit) only has BE distro implementations, and
msjor software projects (including golang) are DROPPING BE support entirely.

Microwatt, A2O, A2I and LibreSOC are accidentally completely excluded from
major modern distros, and with ABI changes taking estimated 3 to 5 years to
propagate, there are very few options. 

* gcc / libc6 triplets require an entire new distro port (or multilib addition
to an existing port), the adoption window is 18 months for binutils alone.

* VSX is a whopping 600 instructions and if unrealistic estimates of 1
instruction per day are utilised this is still 2.5 *years* of HDL development
and unit tests.

consequently although performance would be terrible, an emulator is about the
only workable least disruptive least costly option.

emulation using qemu or qemu-kvm (which requires hypervisor mode) is not
entirely realistic: the project is too large.

an option which cuts significant time off the development cycle is to write a
compiler that autogenerates c code similar to how ISACaller works.  the v3.0B
pseudocode may be morphed into executable code and language-translated into c.

performance is the absolute lowest priority here.  simplicity and expediency
are top priority.

-- 
You are receiving this mail because:
You are on the CC list for the bug.