This could certainly happen, as the custom space is expressly designed
not to be regulated.
It is certainly possible to add a CSR that changes instruction
encoding on the fly. We already have the possibilty of a writable
misa to enable/disable extensions on the fly or to change base ISA.
But you'd want to make sure most common use cases don't need this.
Moving the custom extensions into the standard ISA encoding space,
even if it means 48-bit or longer encodings, is probably preferable to
any kind of dynamic switching in practice. For many custom
extensions, code size is probably not the primary concern, as overall
application's code size will be dominated by all the standard code.
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@groups.riscv.org.
To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAPweEDzSUSh2bCGJ-oDzSWN-SVk43MTHfRdn1aw_e-M3XoUs3A%40mail.gmail.com.
On Thu, Apr 12, 2018 at 6:02 AM, Andrew Waterman
<wate...@eecs.berkeley.edu> wrote:
>> Right now, hmmm this hadn't occurred to me until now: vendors that
>> create custom instructions will be FORCED into the position of
>> maintaining their own fork of gcc. Without the above *STANDARD*
>> formal method that is part of the *BASE* RV, the first vendor that
>> submits patches to gcc basically becomes the de-facto "dominator" of
>> that encoding. Total chaos and much pain ensues.
> It might've just occurred to you, but it occurred to us a long time ago.
*gently*, Andrew. Someone coming in new can't know everything. That
I quickly and independently derived "what you already knew" is a good
sign, as it increases the probability that the decision / analysis
that you did was good, yeah?
On 12/04/2018, 08:55, "kr...@berkeley.edu" <kr...@berkeley.edu> wrote:
By definition, RISC-V won't have incompatible standard extensions.
The whole point of the custom instruction encoding space is that we
don't have to talk about it. All standard tools and OSs should ignore
it.
Agreed. Custom extensions are just that … custom for a particular vendor/device/project/implementation.
Think an FFT or AES engine that gets hooked to the CPU and can be called via a single instruction.
The actual instruction may vary from project/device to project/device.
If someone comes up with a great (set of) instruction(s) that benefits a whole community, it should be proposed as a foundation supported extension.
Richard
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/23247.742.482965.940004%40KAiMac.local.
On Wed, Apr 11, 2018 at 10:38 PM, Luke Kenneth Casson Leighton
<lk...@lkcl.net> wrote:
> Thank you for sharing these insights and stories, Albert, I
> appreciate hearing things like this. hmmm, has anyone done a RISC-V
> disassembler to make sure that it also does not have the same kinds of
> flaws?
Objdump can disassemble of course.
On Wed, Apr 11, 2018 at 10:16 PM, Luke Kenneth Casson Leighton <lk...@lkcl.net> wrote:On Thu, Apr 12, 2018 at 6:02 AM, Andrew Waterman
<wate...@eecs.berkeley.edu> wrote:
The disconnect here is that this mailing list typically has a sober tone, whereas my observation is that when you see a hole (actual or perceived), you jump on it, assume the worst, and editorialize an extrapolation. Of course I can't expect you to know everything that's happened over the last several years. But I can also ask that you operate under the assumption that the other participants on this list weren't born yesterday, and perhaps some more subtlety might be appropriate.
On 12/04/2018, 08:55, "kr...@berkeley.edu" <kr...@berkeley.edu> wrote:
By definition, RISC-V won't have incompatible standard extensions.
The whole point of the custom instruction encoding space is that we
don't have to talk about it. All standard tools and OSs should ignore
it.
Agreed. Custom extensions are just that … custom for a particular vendor/device/project/implementation.
Think an FFT or AES engine that gets hooked to the CPU and can be called via a single instruction.
The actual instruction may vary from project/device to project/device.
If someone comes up with a great (set of) instruction(s) that benefits a whole community, it should be proposed as a foundation supported extension.
So we see here the limits of objdump: it has to know the instruction,
and it has to know which subarchitecture it's looking at. In RISC-V's
case, the "subarchitecture" includes which custom instructions it has.
The backwards/forwards compatibility with custom instructions has been
addressed, by reserving a few of the major opcodes for custom
instruction extensions only.
What you're concerned with is something completely different: conflicts
between different, separately authored, custom extensions.
There's no easy answer for that.
The encoding space is unavoidably limited (though
RISC-V has more free encoding space than most), hardware considerations
like the placement of fields within an instruction are important, and
every solution or workaround has a cost, which might not be acceptable
for some applications.
>> I see nothing ambiguous about "these opcodes are reserved for your custom
>> extensions". And requiring registration for custom extensions is not a good
>> thing.
>
> in a later message (i notice you're going through the thread....)
> you'll see that this was addressed. i hope.
Personally, I'd put that information in the device tree: which
extensions are available, with their name (in device tree style, which
combines the vendor within the name) and how to enable/disable each of
them (which CSR and which bit within the CSR, if it's not permanently
enabled).
This has the distinct advantage that the operating system does
not need to have a table mapping the architecture ID to the extensions
and their control registers, and therefore an old operating system can
be used with a new processor without losing access to the custom
extensions it already knows.
> By the "Desert Island Test" in its strictest definition, neither
> RISC-V *nor the linux kernel* are software libre, due to the need for
> the atomic global registration. However I do get your point.
The difference is that it's not legally mandated. If I'm stuck in a
desert island, I can use any machine ID I want, and won't face any legal
repercussion for doing so when I get back to civilization.
Also, AFAIK the machine ID is much less important nowadays, since the
configuration is no longer done using board files (keyed by the machine
ID), instead it's done through the device tree. The ARM machine ID is a
relic from the old days.
What's more probable is that you license the backend part of the custom
instructions, and are responsible for wiring them to the decoder yourself.
There's a difference between exploring the options, and emphatically
affirming that RISC-V *will* fail unless the correct option is chosen.
> ok so let's think it through. topologically it's equivalent to the idea
> that i suggested:
>
> MISA |= extension1 # sets context "extension 1 encoding enabled"
> AAAA # extension 1 meaning of AAAA
> ADD r1, r2, r3
> MISA &= ~extension1 # disable extension 1
> MISA |= extension 2 # sets context "extension 2 encoding enabled"
> BBBB # extension 2 meaning of AAAA
>
> yeah that would work! so, again, the assembler (see, i'm paying
> attention...) would generate (at the top of each function... _still_
> paying attention i hope) the required enable-extension MISA codes. the
> *implementation* of that would switch out hardware in the "instruction
> decode" phase (precedent for that practice has now been set... and
> implemented... so that's good to know).
The assembler cannot generate the enable/disable instructions, because
the assembler doesn't know the function boundaries. What would generate
these instructions would be the compiler. The compiler could, however,
use a "pseudo-instruction" which the assembler expands into one or more
real instructions.
>
> my only main concern would be: does enabling or disabling of the
> extension result in any kind of unpredictable resetting or alteration of
> the CSRs associated with that extension? because if so that's going to
> be Bad.
That's defined by the extension author and/or implementer.
> So far, Luke's IANA-style numbering is the best way. I'm pretty sure
> we can elaborate on that to make it very flexible and still keep it
> simple. This will not affect vendors that do not attempt to support
> conflicting extensions, so it has zero cost to them (except perhaps
> returning 0s for a CSR that might control this switching of
> extensions).
>
We already have IANA-style numbering for vendor and arch IDs.
--
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@groups.riscv.org.
To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CALo5CZyr-2GS9pxyM8AVj0ZunTn5wXUj8PzOD5PuP%2B6A2xd9Tg%40mail.gmail.com.
Just a quick comment. I don't regard C2 as being all that "general purpose". It's been designed to perform as well as possible across SPEC, both INT and FP.
Typical computer workloads do not have anywhere near as much FP in them as SPEC and so C2 is likely to be quite far from the best compressed encoding for typical operating system, compiler, internet, and business code (which SPECINT is probably not a terrible proxy for).
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CALo5CZyr-2GS9pxyM8AVj0ZunTn5wXUj8PzOD5PuP%2B6A2xd9Tg%40mail.gmail.com.
--
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@groups.riscv.org.
To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAMU%2BEkxN29Yc%3DS8XFXQ5LFzH4FJh7p1_kEjcYSPh592jzej-eQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAMU%2BEkxN29Yc%3DS8XFXQ5LFzH4FJh7p1_kEjcYSPh592jzej-eQ%40mail.gmail.com.
--
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@groups.riscv.org.
To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CA%2B%2B6G0CGjmDc54Cw80NjCKm39xnzxJHctXrf2BtMfR9Lc0Jv7Q%40mail.gmail.com.
--
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@groups.riscv.org.
To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAPweEDy%3D0Oc3VqY7pGGCtyMLj3FGFTLNi0YiF23ROqq7yfgpsw%40mail.gmail.com.
This strawman is so stupid it is amusing.
As I said earlier - this is a non-problem.A customer that falls into the trap of requiring two separate custom extensions from one or more vendors that have conflicting encodings, and requiring working silicon for both extensions that do not conflict--- deserves to go out of business.Neither IP vendor will go out of business (for those reasons, anyway).
This strawman is so stupid it is amusing.
Thirdly - going to call ARM to solve your problem?Do you seriously expect them to implement a custom extension?
As I said earlier - this is a non-problem.
A customer that falls into the trap of requiring two separate custom extensions from one or more vendors that have conflicting encodings, and requiring working silicon for both extensions that do not conflict--- deserves to go out of business.
Yeah, 640kB (or 2 major opcode slots) ought to be enough anyway.
--
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@groups.riscv.org.
To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAPweEDy%3D0Oc3VqY7pGGCtyMLj3FGFTLNi0YiF23ROqq7yfgpsw%40mail.gmail.com.
Exactly.
Consider the Scenarios
1: one IP vendor supplying only the custom extensions. Customer must integrate into their core
2: one IP vendor supplying core+ custom extensions
3: two or more IP vendors supplying only custom extensions. Customer must integrate into their core
lk...@lkcl.net wrote:
> On Wednesday, April 18, 2018 at 2:38:33 PM UTC+1, Allen Baum wrote:
>
> [...]
>
>
> A customer that falls into the trap of requiring two separate
> custom extensions from one or more vendors that have conflicting
> encodings, and requiring working silicon for both extensions that
> do not conflict--- deserves to go out of business.
>
>
> I believe we have established that the number of remaining custom
> opcodes in the 32-bit space is sufficiently small (2) such that the
> probability of this scenario "businesses using RISC-V deserving to go
> out of business" - is extremely high. In an earlier message in this
> thread approximately six different *classes* of high-value potential
> custom extensions were listed.
What luck! For RV32, there are exactly *six* major opcodes that can be
used in this manner: CUSTOM-0, CUSTOM-1, OP-IMM-64/CUSTOM-2,
OP-64/CUSTOM-3, OP-IMM-32, OP-32. :-)
On a more serious note, the issue here is the inflexibility of wanting
extensions with incompatible encodings in a single processor and wanting
*pre-existing* working silicon for what, put simply, would be a *new*
product -- a processor that combines those extensions for the first
time. I hope that all can see the temporal contradiction in that scenario.
> Would you agree that the probability of conflicting encodings is very
> high?
I consider it a certainty (at the scale of "all of RISC-V") and propose
that we work to manage the consequences of that inevitability. Consider
this: how to ensure that the Chinese no-name gone-tomorrow
new-name-next-day manufacturers follow whatever process is developed for
coordinating unique extension encodings and do not just decide that that
process is "too complex" and drop their extensions right on top of
whatever happens to be in the way?
> Anyway: there is one potential "solution" that comes out of your
> reaction, Allen (see? every contribution is valuable!) and that's the
> possibility of simply laying down one core with one custom extension,
> and another totally separate core with another custom extension.
Entirely separate cores are not needed, as each hart can have its own
{vendor-id, arch-id} tuple.
> Now, whether that's acceptable to a Fabless Semi Company is an
> entirely different matter. It would mean having to have separate SMP
> cores, such that the performance may be adversely affected if the
> algorithm specifically requires the close cooperation between two
> custom encodings, such that the overhead of dropping down to L2 cache
> and back to another core is simply not a way to achieve the desired
> performance.
Not entirely SMP, only separate harts (HARdware Threads) within the same
core. Custom inter-hart synchronization instructions (directed-yield?
semaphores?) could even be added to assist in aligning the cooperating
harts.
With ARM you're not going to be able to have one custom ISA extension, let alone two!!
--
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@groups.riscv.org.
To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/f90e6d0a-07a5-426e-a63a-18d2c1898f7c%40groups.riscv.org.