From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) by sourceware.org (Postfix) with ESMTPS id 5A18A3858D37 for ; Fri, 28 Apr 2023 18:43:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5A18A3858D37 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pf1-x436.google.com with SMTP id d2e1a72fcca58-63b46186c03so381320b3a.3 for ; Fri, 28 Apr 2023 11:43:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682707432; x=1685299432; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=QKA7eNPr0ngm0AaPbKTrsCf6CDzRQEF9kkxqlZZ9DSc=; b=SjI+4luQKldW0HBb7sKgnqCo1Fxh8xdktBn2gAsBuH4IkflgDjKZTxSSdOhAwwZJXe 0KYiV/x3wRPfM7B54cLhI3QJaQ79B+PR+BoHVOvp6yQnW3v/y6svpIm+0iRIkOYki2i7 /nG/9S2jgQBrmlxgahkA1MoXVYrowSZUMzTUxE3sa8+5w6eln2Y7X0uxb0oV5x3+oPp7 cpCK+2kHe7nzba09/xQxyZftiNb3XnLqzrolqZkanShLeusQ3uZn6VMXPhNqDUJP+AZK CBqFjUGoyl64oQCD44hfT1EAIuxbedOj6szvCSIR8uGBqvFkR/fxHQRIB6eOTyxltMDA cu6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682707432; x=1685299432; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=QKA7eNPr0ngm0AaPbKTrsCf6CDzRQEF9kkxqlZZ9DSc=; b=Gg0ddTkvnMc9rd0HDn9ns47F4KRf9NZLjTRviay3cDz2Vv474RjUlSwk3rUwfbnzg1 qHNByJ0tk7G9sOwEvf3Rhz0k6f8Z9xI0HKrjGkhy7svYMTeJwWb8rf4cWAJBeuIMHN/m ZAptrQXv7QmgUFKxt2w7uRih0PTWyPh10ED1rA3BN+IEGrBhueZyRlJf2XISGfviRb0B sLG0CxuMyY4gPygnXpStLIj4EyklGpNYFQVeM+tgMg7S0ki3S9e3vmFVubHEXqP0PqTt 5LvgjTRGJ2F0iFOvN+AIKQdZpiFwQpLpYoT1AmaaLzMNFxng8E+Y7Z1ByBsBm4W3hpUB xr+A== X-Gm-Message-State: AC+VfDwVvlGN/p26hBui0QyzOygdIrjtmSYletlnjn/u5H45sZ8uMGSp FdaoS+n/9RJaySmqR+BtADw= X-Google-Smtp-Source: ACHHUZ4OxioLS/RsMtH1ERpifYUn58jbf6AxZv27nQsFEZZhCqV++eW6yFEBeYUKd5ks1p9jYk7log== X-Received: by 2002:a05:6a00:2d0c:b0:63f:2f00:c6d with SMTP id fa12-20020a056a002d0c00b0063f2f000c6dmr9511459pfb.2.1682707432220; Fri, 28 Apr 2023 11:43:52 -0700 (PDT) Received: from ?IPV6:2601:681:8600:13d0::99f? ([2601:681:8600:13d0::99f]) by smtp.gmail.com with ESMTPSA id g13-20020aa7874d000000b0063b8f17768dsm15526704pfo.129.2023.04.28.11.43.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 28 Apr 2023 11:43:51 -0700 (PDT) Message-ID: <30d1db6e-ab86-8eb5-2e26-d39b193f206f@gmail.com> Date: Fri, 28 Apr 2023 12:43:50 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 Subject: Re: [committed] RISC-V: XVentanaCondops support Content-Language: en-US To: Palmer Dabbelt , Jeff Law Cc: binutils@sourceware.org References: From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 4/26/23 15:42, Palmer Dabbelt wrote: > We had the various RISC-V port maintainers and long-term contributors in > FSF toolchain land (ie, binutils/GCC/glibc) agree on something posted to > the mailing list. > > Philipp and I certainly talked about it, but there's no private > agreements or anything like that -- it's just what we discuss on the > mailing lists.  Unfortunately he has along history of misrepresenting > things, but that's really why we're so careful about making sure that > all the decisions are talked about on the lists. I wasn't implying any private communications. It was more a reflection that you and Philipp seemed to be the principals in the overall discussion. My recollection from the discussion back in Nov/Dec was that the only thing we were still waiting on for xventanacondops to move forward was an announcement of the chip. My understanding was the chip didn't need to actually be available yet. Maybe I'm mis-remembering, and if so, I've got no problem pulling this out. Perhaps the requirements should be posted somewhere so that gcc, binutils, gdb, glibc, etc can all refer to and follow the same procedures for accepting vendor specific bits. > > The idea was to have some sort of timeline around availability of the > hardware -- essentially the goal is to avoid being stuck supporting > stuff that doesn't actually make it out of the lab.  I can't find > anything that actually says that, but then also I'm pretty much allergic > to chip company marketing material these days so I sort of stay out of > it ;) I don't recall a timeline in the requirements. But again, it's been months since we kicked this stuff around. I can't speak to timelines other than "we're waiting on hardware to start bring-up". > > The best I've been able to find is this "Veyron V1 is Highest > Performance RISC-V Processor running at 3.6GHz in 5nm" [1].  The > big-ticket ones like an SDK and dev board don't seem to exist anywhere > outside of press releases, though (there's a github [2], but no SDK). I don't think we've released our SDK to anyone except partners. So no surprise you can't find an SDK :) > > I know it's kind of pedantic, but we've had a lot of issues in the past > with RISC-V folks making stuff up and trying to push around upstream. > I'm not saying you're doing that, you've been around long enough that if > you say you have a chip I believe you.  The goal is to be fair to > everyone, though -- essentially the same as what happened for the GCC > patches. No worries. As I've noted in the past, I'm keenly aware of the desire to avoid even the appearance of unfairness or someone taking advantage of their position in the communities. It's something that's been important to me personally for decades in the GCC space, so you don't ever have to worry about explaining it to me or offending me by being pedantic in this space. I'm not going to lose any sleep if we need to delay bits for veyron-v1, I just want to make sure we have an agreed upon process so that we know when things can go forward across the various tools. I'm actually more concerned about this for gcc than binutils/gdb as we have scheduler models, costing models, etc that I'd like to get submitted. I've held off doing that for the duration of the gcc-13 cycle, but very much want to see those things move forward in the gcc-14 cycle. So in summary, let's get the agreement/policy posted in a easily found location. I'll suggest the GCC wiki, but I'm certainly not wed to that idea. jeff