I would like to know where in the ISA to place floating-point estimate functions? For my rendition of a RISCV processor there’s currently (single precision) reciprocal square root estimate, reciprocal estimate, and sigmoid approximation functions. I can image that there may be other estimate or approximation functions that might be handy in some circumstances.
--
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+u...@groups.riscv.org.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/0b25c347-227c-4626-acd9-10d52d8838bb%40groups.riscv.org.
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+u...@groups.riscv.org.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/a48af2fc-a782-4c9b-88d9-401e7b79f969%40groups.riscv.org.
Bruce’s suggestion sounds good to me. I had been thinking along the same lines, I thought there might be someone else developing custom FP already using a range of instructions that I could steal a few opcodes from. My mind churning away “there has to be someone else working on estimate functions already…” It might take me a while to get there, not being the brightest tool in the shed.
Is it better to use a truncation of an accurate algorithm, rather than a table lookup? The only thing I can think of to do, is code them both, run them both, then measure the power consumption somehow.
There is no possible scheme that allows multiple independent parties
to create extensions (custom or otherwise) that each take up four
major opcodes (12.5% of the entire encoding space) from a 32 bit
instruction that already has the standard ISA in it, and somehow
enable instructions from each of those extensions to be available
simultaneously.
For a private extension that will forever remain private you are of
course entitled to use all the custom major opcodes and the RV128 ones
and whatever other holes you find.
However this is simply not tenable for something that you think you
might one day want to share with others. In this case you should be
using 48 or 64 bit opcodes.
(and, yes, the exact scheme for those
isn't yet ratified,
but I think Clifford's latest suggestion has a lot
of merit)
On Sat, Jul 13, 2019 at 12:05 AM lkcl <luke.l...@gmail.com> wrote:
>
> On Saturday, July 13, 2019 at 2:43:03 PM UTC+8, andrew wrote:
> > On Fri, Jul 12, 2019 at 11:20 PM lkcl <luke.l...@gmail.com> wrote:
> >
> >
> >
> > > What then happens to upstream gcc, llvm and binutils?
> >
> >
> >
> > The GCC/Binutils RISC-V maintainers sidestep this question by maintaining a policy against upstreaming custom extensions. We've instead provided basic support for custom instructions in Binutils (the .insn directive), which, while quite primitive, suffices to implement a C intrinsics-style programming model.
>
> This works extremely well for proprietary vendors, working on proprietary custom extensions, developing proprietary secretive firmware that never sees the light of day.
>
> It also works well for rapid prototyping and R&D.
>
> Where it falls down - the case that I have been trying to get through to the RISC-V Foundation for over 18 months now that a proactive strategy is essential if RISCV is to succeed long-term - is where the custom extensions become *public* world wide common usage.
You can use a scheme such as I suggested to Robert Finch, where you
decide which bits you want to use yourself (selected in a way likely
to remain compatible with others) and make your tools flexible enough
to allow arbitrary contents of the remaining bots.
There is mathematically no way to parcel out such as limited thing as
a 32 bit space in such a way that everyone in the world gets a unique
and non-overlapping space for their custom extension. The best that
can be done is to allow each custom extension to have its opcodes
easily re positioned depending on what other custom extensions the
user wants available in the same program (without mode switches).
Flags can be provided to compilers giving masks or maybe other
information about where each custom extension is to be places. Linkers
and other object code tools can be written to renumber opcodes for
custom extensions within existing object files.
> Under such circumstances the gcc team will feel pressurised by sheer overwhelming user demand and the prospect of hard forks of gcc being downloaded from "unofficial" locations in the tens of thousands.
I predict they won't.
> Who is going to take responsibility for properly designing and proposing a strategy for mitigating this easily predictable and extremely high probabity scenario, before it is too late?
Strategies that can cope with small custom extensions such as function
estimate instructions are easy to come up with. Strategies that can
cope with custom extensions that each fill four major opcodes are
mathematically impossible.
On Mon, Jul 15, 2019 at 10:01 PM lkcl <luke.l...@gmail.com> wrote:
> On Monday, July 15, 2019 at 9:56:18 PM UTC+1, Bruce Hoult wrote:
>>
>> There is no possible scheme that allows multiple independent parties
>> to create extensions (custom or otherwise) that each take up four
>> major opcodes (12.5% of the entire encoding space) from a 32 bit
>> instruction that already has the standard ISA in it, and somehow
>> enable instructions from each of those extensions to be available
>> simultaneously.
>>
>
> there is. it's called the ISAMUX/ISANS proposal. it's been discussed several times, and mentioned several times, over the past 18 months.
>
> the little-endian / big-endian proposal is the first official extension that (partly) meets the ISAMUX/NS requirements [the LE/BE field is proposed to be WARL which needs to be fixed and made WLRL]
>
> https://libre-riscv.org/isa_conflict_resolution/isamux_isans/
I am fully aware of this. It is NOT making different extensions
available simultaneously to a program, it requires a mode change to
access different extensions.
> Who is going to take responsibility for properly designing and proposing a strategy for
> mitigating this easily predictable and extremely high probabity scenario, before it is
> too late?
If you're happy to sprinkle your program with mode changes then there
is nothing in opcode space management that needs mitigating and no
design needed.
>> For a private extension that will forever remain private you are of
>> course entitled to use all the custom major opcodes and the RV128 ones
>> and whatever other holes you find.
>
> this is where the approach of the RISC-V Foundation breaks down. the processor that we are developing is very speciically designed to be mass-volume and, because it is libre, it will be very high profile. libre means: the entire and full source code *has* to be made public [and all development discussions have to be public, as well. no exceptions].
>
>
>> However this is simply not tenable for something that you think you
>> might one day want to share with others. In this case you should be
>> using 48 or 64 bit opcodes.
>
> we can't. we're taking up the *entirety* of the 48 and 64 bit opcode space for SV prefixing.
That is *extremely* unfriendly and un-neighborly of you, and likely
completely rules out ever combining your extension with any other
official or unofficial extensions.
> you've not been following the discussion, bruce. if you can get up to speed on ISAMUX/ISANS it would be very helpful for the RISC-V community. the current draft spec is here https://libre-riscv.org/isa_conflict_resolution/isamux_isans/
Factually incorrect, I have been following it from the start. Kindly
do not assume you know my state of mind, and do not assume that
disagreement with you implies ignorance on the part of the person
disagreeing with you.
--
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+u...@groups.riscv.org.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/f5353b12-3dc1-405b-8656-9231478d33a7%40groups.riscv.org.
(Posting to the list because lkcl appears to be replying to the list, even if messages were posted directly to lkcl, as Robert did)lkcl,I've not been involved in any of these discussions other than as an interested reader and observer.To this outside observer, you are the one who comes across as the bully.
You frequently use language that comes across as disrespectful, dismissive of others' ideas or experience.
Yet when someone then pushes back against you even in a minute degree, you quickly claim to be attacked, and jump to calling them bullies.
Yes. Well, it should be blocked via legal means. Incompatibility is a disaster for an architecture.
The viability of PowerPC was badly damaged when SPE was introduced. This was a vector instruction set that was incompatible with the AltiVec instruction set. Software vendors had to choose, and typically the choice was "neither". Nobody wants to put in the effort when there is uncertainty and a market fragmented into small bits
Note how Intel did not screw up. When SSE was added, MMX remained. Software vendors could trust that instructions would be supported. Both MMX and SSE remain today, in all shipping processors. With very few exceptions, Intel does not ship chips with missing functionality. There is a unified software ecosystem.
This goes beyond the instruction set. MMU functionality also matters. You can add stuff, but then it must be implemented in every future CPU. You can not take stuff away without harming the architecture.
In this particular example, I saw Bruce defending themselves against an attack from you.
To me, you were the one who were the bully, right from the start, belittling others' experience and knowledge on the topic, and then when people adjusted their tone to match yours, you jump on them and call them bullies.Again, to me as an outside observer ... you're not in the right here.To reiterate: to this outside observer, who has been on the receiving end of bullying ... you are the one who looks like the bully. Including when you accuse others of bullying you – which is a tried and tested tactic used by bullies all over the world whenever their victims finally stand up to them.
I'll leave others to decide who is or is not technically incorrect or
slanderous.
(again, cc'ing con...@riscv.org because relevant context is provided, below).
On Tuesday, July 16, 2019 at 9:23:11 AM UTC+1, Christian Brunschen wrote:(Posting to the list because lkcl appears to be replying to the list, even if messages were posted directly to lkcl, as Robert did)lkcl,I've not been involved in any of these discussions other than as an interested reader and observer.To this outside observer, you are the one who comes across as the bully.i know, christian: i'm aware of this perspective.
i've apologised for it, in the past, made an effort to ask for advice (demonstrated a willingness to accept constructive feedback), sought out and used resources that are specifically designed to help resolve conflict, sought out resources that help with group interactions, define what makes for good communities, and much *much* more, to no avail (i.e., the efforts that i've made have been persistently and consistently ignored, and are beginning to become so exhausting that i've begun to give up on using them).
so can i ask you this very simple question: have you witnessed *any* such efforts by bruce? have you witnessed *any* efforts on his part to:(1) apologise(2) acknowledge other peoples' perspectives(3) acknowledge his mistakes(4) ask questions(5) ask for feedback
You frequently use language that comes across as disrespectful, dismissive of others' ideas or experience.Yet when someone then pushes back against you even in a minute degree, you quickly claim to be attacked, and jump to calling them bullies.the important thing here is to distinguish two groups.
(1) newcomers who do not necessarily know the background (technically, or its forums history of abuse that goes back LONG BEFORE i even joined)
(2) long-time contributors who really should know better (and who consistently and persistently flagrantly engage in abuse and "technical bullying").the first group: *if* they are open-minded, i am respectful towards them, and go to some lengths to thank them for their contribution and make them generally feel welcome.
given that i (nobody is) am not "in charge" of these forums,
being merely a contributor, obviously i cannot do that for every single message and every single person: clearly this is a *group* responsibility.
where someone who falls into that first group demonstrates that they are *not* open-minded: such people are easy to detect.
generally i try to give them "three strikes", and then (honestly) i lose all patience with them.
the second group: yyeah. i don't need to spell it out (actually, i probably do. *sigh*).
the problems faced by Standards Development are particularly unique.
that is a huge amount of pressure, and it is really, *really* important that both newcomers *and* the long-time contributors recognise, understand and accept it, and adjust accordingly.so when i am vocal and outspoken, it is because i *KNOW* what the consequences of mistakes are. because this *is* a Standards Development Mailing list, i EXPECT other people to KNOW this about long-term Standards Development. if they don't, then, well... i'm really sorry, but, putting it bluntly and honestly: they need to get educated, drastically fast. and, again being blunt and honest: that's really not my responsibility: it's theirs.
In this particular example, I saw Bruce defending themselves against an attack from you.you need to understand
that Bruce has been persistently engaging in bullying behaviour for over 18 months, now, to the point where he's actually taken up a "personal crusade" of hunting me down in *other forums* and engaging in either technically-incorrect attacks or just plain slander, both against me and also against the Libre RISC-V project.
these ongoing attacks have resulted in the reputation of RISC-V being tarnished, through Bruce's direct association with SiFive, because people can clearly see the attacks for what they are.
consequently, several extremely prominent and experienced engineers across the world want absolutely *nothing* to do with RISC-V.so unfortunately, yes: i can see how, without that long-term context, it may indeed look like he is "defending" himself from "attack". others have made this same mistake in the past, as well, and it's caused me no end of problems.
i've had to "learn" to EXPECT to be attacked, here, and have had to actually change the language to a severely excruciating style that must make reading what i write almost unbearable. it will be such a huge relief to me to *not* have to expect constantly to be under attack!so i suspect that, partly, you are noticing this "defensive" language (it's extremely locked-down and is itself combatative language, designed as it is to PREDICT verbal attacks and PRE-EMPT them... thus forcing me to MENTION past attacks, and, therefore, we have the APPEARANCE of the message itself BEING an attack).
... you see how that works? bottom line: if people stop attacking and bullying me, my messages will no longer need to take that into account, and will stop *appearing* to be bullying in and of themselves.
this is exhausting to have to do, day-in, day-out, and i should never have had to begin to do it in the first place! not to mention, i'm taking up valuable sponsorship money that i will actually have to explain and account for, publicly! it is one of the most bizarre / surreal situations i've ever been in.To me, you were the one who were the bully, right from the start, belittling others' experience and knowledge on the topic, and then when people adjusted their tone to match yours, you jump on them and call them bullies.Again, to me as an outside observer ... you're not in the right here.To reiterate: to this outside observer, who has been on the receiving end of bullying ... you are the one who looks like the bully. Including when you accuse others of bullying you – which is a tried and tested tactic used by bullies all over the world whenever their victims finally stand up to them.so to illustrate to you why that is very very specifically not the case: let's do a test [i.e. let's see if Bruce does the same thing].
i am going to ask you this simple question:i'm sorry for giving that impression: it's not the intent (i.e. was accidental)
- how could i have done better?the very fact that i am willing to even *ask* this question - which is genuine and in good faith - should tell you everything that you need to know, namely that (a) it's a *genuine* apology and (b), it's asking for constructive feedback. and in case you believe that i am being disingenuous, i'll emphasise it again: *i actually genuinely want to know the answer to that question*.
so i hope that helps provide some very important context, Christian. and thank you for raising the point that *i* am the one that "looks like a bully". having been subjected to bullying in all forms since around the age of 11 [it began with boarding school taunting, for five years, with absolutely no chance of escape, and the bullies *actively* hunting me down if i reported them], i'm keenly aware how it makes people feel, so it is consequently one of my absolute worst waking nightmares to be accused of *DELIBERATELY* wishing harm - of any kind - on another human being.
ok that's enough. i have to get back to developing the processor.
--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+u...@groups.riscv.org.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/cffd88dc-45f4-4f68-b8e8-1e40d9ebd027%40groups.riscv.org.
On Tue, Jul 16, 2019 at 10:31:23PM -0700, lkcl wrote:
> to answer that, we have to look at who is behind the new process. both
> karsten and i raised concerns about the new process, that it's instigated,
> driven, policed and judged by people who are simply have too close a link
> to the perpetrators of unacceptable behaviour, and in some cases *are
> actually the perpetrators themselves*.
Luke, stop putting things into my mouth that I have never said
and stop trying to create the impression that I would somehow
agree with your behaviour and with what you are trying to stage
here - I definitely do not; exactly the contrary is true.
I have voiced concerns regarding the wording of specific clauses
of the code of conduct published by the foundation because I
believe that the wording of those clauses is unsuitable for a
code of conduct, and I have expressed criticism regarding the
foundation claiming to speak for the RISC-V community at large in
publishing this specific wording while there has been no
involvement at all of the community at large in the design and
adoption of this specific code of conduct,
but I have never
stated anything of what you, Luke, claim above.
If somebody
would like to read what I really have written, just take a look
at the sw-dev list archive; the thread starts at
https://groups.google.com/a/groups.riscv.org/forum/#!topic/sw-dev/OcNyKVHFuaE
To make that absolutely clear: My aforementioned criticism
regarding the design of this specific code of conduct text is in
absolutely no way to be taken as any form of agreement with your
behaviour on these lists, which I perceive as respectless,
condescending and often outright aggressive against anybody who
isn't willing to dance to your tune.
I have to agree with Christian on this. I am also absolutely fed
up with you misrepresenting things that I have written to further
your personal agenda.
--
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+u...@groups.riscv.org.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/a5bef204-da54-4ae0-bd1e-c6386df102e2%40groups.riscv.org.