[libre-riscv-dev] [isa-dev] Re: FP transcendentals (trigonometry, root/exp/log) proposal
andrew at sifive.com
Thu Aug 8 11:07:05 BST 2019
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
> 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
> 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
> 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).
> 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
More information about the libre-riscv-dev