[libre-riscv-dev] [isa-dev] Re: FP transcendentals (trigonometry, root/exp/log) proposal

[Andrew Waterman]

On Thu, Aug 8, 2019 at 1:36 AM lkcl <luke.leighton at gmail.com> wrote:

> [mostly OT for the thread, but still relevant]
>
> On Thursday, August 8, 2019 at 3:33:25 PM UTC+8, waterman wrote:
>
> > It's not obvious that the proposed opcodes justify standardization.
>
> It's outside of your area of expertise, Andrew. Just as for Luis, all the
> "metrics" that you use will be screaming "this is wrong, this is wrong!"
>

Oh, man.  This is great.  "Andrew: outside his element in computer
arithmetic" is right up there with "Krste: most feared man in computer
architecture".


>
> Both Jacob and I have Asperger's. In my case, I think in such different
> conceptual ways that I use language that bit differently, such that it
> needs "interpretation". Rogier demonstrated that really well a few months
> back, by "interpreting" something on one of the ISAMUX/ISANS threads.
>
> Think of what I write as being a bit like the old coal mine "canaries".
> You hear "tweet tweet croak", and you don't understand what the bird said
> before it became daisy-food but you know to run like hell.
>
> There are several aspects to this proposal. It covers multiple areas -
> multiple platforms, with different (conflicting) implementation
> requirements.
>
> It should be obvious that this is not going to fit the "custom" RISCV
> paradigm, as that's reserved for *private* (hard fork) toolchains and
> scenarios.
>
> It should also be obvious that, as a public high profile open platform,
> the pressure on the compiler upstream developers could result in the
> Altivec SSE nightmare.
>
> The RISCV Foundation has to understand that it is in everybody's best
> interests to think ahead, strategically on this one, despite it being well
> outside the core experience of the Founders.
>
> Note, again, worth repeating: it is *NOT* intended or designed for
> EXCLUSIVE use by the Libre RISCV SoC. It is actually inspired by Pixilar's
> SIGGRAPH slides, where at the Bof there were over 50 attendees. The
> diversity of requirements of the attendees was incredible, and they're
> *really* clear about what they want.
>
> Discussing this proposal as being a single platform is counterproductive
> and misses the point. It covers *MULTIPLE* platforms.
>
> If you try to undermine or dismiss one area, it does *not* invalidate the
> other platforms's requirements and needs.
>
> Btw some context, as it may be really confusing as to why we are putting
> forward a *scalar* proposal when working on a *vector* processor.
>
> SV extends scalar operations. By proposing a mixed multi platform Trans /
> Trigonometric *scalar* proposal (suitable for multiple platforms other than
> our own), the Libre RISCV hybrid processor automatically gets vectorised
> [multi issue] versions of those "scalar" opcodes, "for free".
>
> For a 3D GPU we still have yet to add Texture opcodes, Pixel conversion,
> Matrices, Z Buffer, Tile Buffer, and many more opcodes.  My feeling is that
> RVV's major opcode brownfield space simply will not cope with all of those,
> and going to 48 bit and 64 bit is just not an option, particularly for
> embedded low power scenarios, due to the increased I-cache power penalty.
>
> I am happy for *someone else* to do the work necessary to demonstrate
> otherwise on that one: we have enough to do, already, if we are to keep
> within budget and on track).
>
> L.
>
> --
> You received this message because you are subscribed to the Google Groups
> "RISC-V ISA Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to isa-dev+unsubscribe at groups.riscv.org.
> To view this discussion on the web visit
> https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/666729c1-c7c9-47a4-af20-0cc78f6cea99%40groups.riscv.org
> .
>