From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) by sourceware.org (Postfix) with ESMTPS id 6CA813857432 for ; Wed, 11 May 2022 00:01:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6CA813857432 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dabbelt.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=dabbelt.com Received: by mail-pf1-x42d.google.com with SMTP id p8so513236pfh.8 for ; Tue, 10 May 2022 17:01:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dabbelt-com.20210112.gappssmtp.com; s=20210112; h=date:subject:from:to:message-id:mime-version :content-transfer-encoding; bh=iMz11mh+9g4WHK2NBWc/yNalnj8pM60lt81LIZU2aTQ=; b=gm8tsvD2g5z3Y7h3ZWlummvb6VJa+sTKWzZnIkOsiZmtwARjd2wtDlvi9PyzmQFtQq n4GZS+SjVIwCFYi/RQiBSyqkGJJ614HiSPF5WK3EiqO4twjWSaOjE44JmpDrP01CAbh3 OrSv94LVyUfCLb5HFUh6SfTtXrShjSNL86TzBPlNJa4qyVJ0MSM2Cl21Q/9prcEZXByF ocrn1jvZSu1AeCJqFal+l+Bs5HZg4hrtOYKlNdGROy5VO/Dvk8D/Uup+QYIJPgLIAYx9 8Fg1W33D8jYH5tYhrPw2CTiD4AaqziQnq5FCnot/gjF3Q2pLBobMDw0HAEzeNYrI4rG7 F5Tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:subject:from:to:message-id:mime-version :content-transfer-encoding; bh=iMz11mh+9g4WHK2NBWc/yNalnj8pM60lt81LIZU2aTQ=; b=EU0P81uxoOmFl/z5g88US/UbJ8Hh9kOPLE2draJiq+9LR8Y93Yfk5ydXY01taBp+pO znPKyQEhr1P8jiMODdKrewxN4fH+mKqOI8FI0IBWw/qClCq5upaokaBd4WwSMY5lajiP +KKUonTXerGV/3NW6rJ1nYJ/qQNV3ZAm76P8/mOVZa00EkJOKisw2ISmCdHvY+JMvPbO P6sSLjrf3RDYcnWPEboRgUFiyYZvqATngg7BE7Jd5UBaRAWwvFVcg8yQXoVo8dpFqxFe pghjdWGawkUP1Ru8/JfPmyUDF2VQ57oMp+elbwSc9M87XhlI59ZRxH+HhhWGWPiCEc5x HdkQ== X-Gm-Message-State: AOAM533K4Fn5hUnLP26vE5ILTqLfqfrigSn4IsCErWmKIinrhXwwgxqq Cb21FXAhqQS+aQpqOu/kRd084puEQRa+UQ== X-Google-Smtp-Source: ABdhPJysGiG1yQVE30Jk79ZNBCBNXu1Czcf60b0AIVJgcz/WQyJ19VOnK+aTrR+5kRTr8Xbl/Ln4KA== X-Received: by 2002:a63:8ac7:0:b0:3aa:fa62:5a28 with SMTP id y190-20020a638ac7000000b003aafa625a28mr18948223pgd.400.1652227286804; Tue, 10 May 2022 17:01:26 -0700 (PDT) Received: from localhost (76-210-143-223.lightspeed.sntcca.sbcglobal.net. [76.210.143.223]) by smtp.gmail.com with ESMTPSA id j190-20020a6380c7000000b003c14af50627sm284862pgd.63.2022.05.10.17.01.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 May 2022 17:01:26 -0700 (PDT) Date: Tue, 10 May 2022 17:01:26 -0700 (PDT) X-Google-Original-Date: Tue, 10 May 2022 17:01:23 PDT (-0700) Subject: Supporting RISC-V Vendor Extensions in the GNU Toolchain From: Palmer Dabbelt To: binutils@sourceware.org, gcc-patches@gcc.gnu.org, libc-alpha@sourceware.org, gdb-patches@sourceware.org Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2022 00:01:30 -0000 [Sorry for cross-posting to a bunch of lists, I figured it'd be best to have all the discussions in one thread.] We currently only support what is defined by official RISC-V specifications in the various GNU toolchain projects. There's certainly some grey areas there, but in general that means not taking code that relies on drafts or vendor defined extensions, even if that would result in higher performance or more featured systems for users. The original goal of these policies were to steer RISC-V implementers towards a common set of specifications, but over the last year or so it's become abundantly clear that this is causing more harm that good. All extant RISC-V systems rely on behaviors defined outside the official specifications, and while that's technically always been the case we've gotten to the point where trying to ignore that fact is impacting real users on real systems. There's been consistent feedback from users that we're not meeting their needs, which can clearly be seen in the many out of tree patch sets in common use. There's been a handful of discussions about this, but we've yet to have a proper discussion on the mailing lists. From the various discussions I've had it seems that folks are broadly in favor of supporting vendor extensions, but the devil's always in the details with this sort of thing so I thought it'd be best to write something up so we can have a concrete discussion. The idea is to start taking code that depends on vendor-defined behavior into the core GNU toolchain ports, as long as it meets the following criteria: * An ISA manual is available that can be redistributed/archived, defines the behaviors in question as one or more vendor-specific extensions, and is clearly versioned. The RISC-V foundation is setting various guidelines around how vendor-defined extensions and instructions should be named, we strongly suggest that vendors follow those conventions whenever possible (this is all new, though, so exactly what's necessary from vendor specifications will likely evolve as we learn). * There is a substantial user base that depends on the behavior in question, which probably means there is hardware in the wild that implements the extensions and users that require those extensions in order for that hardware to be useful for common applications. This is always going to be a grey area, but it's essentially the same spot everyone else is in. * There is a mechanism for testing the code in question without direct access to hardware, which in practice means a QEMU port (or whatever simulator is relevant in the space and that folks use for testing) or some community commitment to long-term availability of the hardware for testing (something like the GCC compile farm, for example). * It is possible to produce binaries that are compatible with all upstream vendors' implementations. That means we'll need mechanisms to allow extensions from multiple vendors to be linked together and then probed at runtime. That's not to say that all binaries will be compatible, as users are always free to skip the compatibility code and there will be conflicting definitions of instruction encodings, but we can at least provide users with the option of compatibility. These are pretty loosely written on purpose, both because this is all new and because each project has its own set of contribution requirements so it's going to be all but impossible to have a single concrete set of rules that applies everywhere -- that's nothing specific to the vendor extensions (or even RISC-V), it's just life. Specifically a major goal here is to balance the needs of users, both in the short term (ie, getting new hardware to work) and the long term (ie, the long term stability of their software). We're not talking about taking code that can't be tested, hasn't been reviewed, isn't going to be supported long-term, or doesn't have a stable ABI; just dropping the specific requirement that a specification must be furnished by the RISC-V foundation in order to accept code. Nothing is decided yet, so happy to hear any thought folks have. This is certainly a very different development methodology than what we've done in the past and isn't something that should be entreated into lightly, so any comments are welcome.