From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) by sourceware.org (Postfix) with ESMTPS id 24DF63858D37 for ; Fri, 28 Apr 2023 20:14:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 24DF63858D37 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-x42a.google.com with SMTP id d2e1a72fcca58-63f273b219eso342537b3a.1 for ; Fri, 28 Apr 2023 13:14:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dabbelt-com.20221208.gappssmtp.com; s=20221208; t=1682712894; x=1685304894; h=message-id:to:from:cc:in-reply-to:subject:date:from:to:cc:subject :date:message-id:reply-to; bh=q+8OIdM1HOnqm3owWnVZc/nbhDwkDPqxq2fStx2m0i4=; b=Lx9NbrUB59z+KdpfcPuBQNxjSuCQaO6FW2rNjWxbQUuEiBGodUwNmWXYmdsJdZ1Rmn 8yqPAbs69D2fscxXz+6+0qy1Ac342JKtWD7e5ZV8dtnz2NkMT0NCAWXTgv9KTUmcZq6Y pFTMr6Q+gWP6BNtCqxTmw4iEVV+ucGelJmuxQCleR0QOz5idZ/hNz4NqHJrmkS+MgSsd kfLZHc7Jxiw8AiqxhIWWE2B9v2s/XQfKtPIAcrxkQALmLUbQfe+7lyZJ7UMkDpIuwLaq 2RGjMuZHhyI9skxrlKXD2Ml72l6/wQyn9FxPH119b/2TYgmJ1Gf1SsUrakvBekF6rNLR 70mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682712894; x=1685304894; h=message-id:to:from:cc:in-reply-to:subject:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=q+8OIdM1HOnqm3owWnVZc/nbhDwkDPqxq2fStx2m0i4=; b=P0hgZJgBysJNukBgHKOKcZlF0PgiROJdiaVjVzEPoiVPot2EeSW2gc/P9mMG+nuDT3 bGxSF+RlMX68YmFpfuxzUb4UTOkbUQIo/lZAlvuhlmO9zcAOJtzVOmeGvKq+O0Cyqb5h cYd6xLYIuMrbuF8q4DGwrwg2/44/tvIJWj2gRqNPtjIM79N2pyOMFKKlyS941tRPcO4t vfUP7ocYV2oXqZ1m+zEuyfZDund9zCQL6k/BOfaMlihCdjchF6uHB5fYFufl/SClB6jV EW9YxePwMBXyn2HbEHC4EbCEl1l6T1U58Ans1hLJH6XXAZH9OhawlMoFaSQio4imYx19 OD8g== X-Gm-Message-State: AC+VfDyXTSpst/5nx/QWJ7XaqMxXVcPzAJbLFH43eB1GFzclOIZYUEVb +ijxFHBZbE0UTwQ24GAUioVA+IrvFoSpB6zOj1A= X-Google-Smtp-Source: ACHHUZ60cAG37Ej6b4Ef60SlxoTm4Y1kfhM5kjF76fjZpcjpXCvKSzYR6UDgqKOC6/XwPFeeeKwI0w== X-Received: by 2002:a17:90a:db0b:b0:247:a22d:2a41 with SMTP id g11-20020a17090adb0b00b00247a22d2a41mr6321846pjv.13.1682712893828; Fri, 28 Apr 2023 13:14:53 -0700 (PDT) Received: from localhost ([135.180.227.0]) by smtp.gmail.com with ESMTPSA id 19-20020a17090a195300b0023a84911df2sm1842474pjh.7.2023.04.28.13.14.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 28 Apr 2023 13:14:53 -0700 (PDT) Date: Fri, 28 Apr 2023 13:14:53 -0700 (PDT) X-Google-Original-Date: Fri, 28 Apr 2023 13:14:50 PDT (-0700) Subject: Re: [committed] RISC-V: XVentanaCondops support In-Reply-To: <30d1db6e-ab86-8eb5-2e26-d39b193f206f@gmail.com> CC: Jeff Law , binutils@sourceware.org From: Palmer Dabbelt To: jeffreyalaw@gmail.com Message-ID: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,PP_MIME_FAKE_ASCII_TEXT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no 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 Fri, 28 Apr 2023 11:43:50 PDT (-0700), jeffreyalaw@gmail.com wrote: > > > 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. That's probably how it looks publicly, but it's not how it happens in practice. Essentially we have an off-list discussion with the various maintainers/contributors who do RISC-V stuff, and then go post the result of that on the list. I actually don't like doing things that way, I'd prefer to do things in public. That's how we used to do it, but we ended up with so much trouble from the folks at the RISC-V foundation that we stopped. I'm not opposed to trying to have the discussions in public again, though. It doesn't really impact me personally because I take all the heat for posting these publicly, so it's really up to everyone else. > 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. There's a thread here: https://inbox.sourceware.org/gcc-patches/mhng-289aa2f5-86f4-4cdb-bed5-1ce130ddc841@palmer-mbp2014/ It doesn't look like we came to an agreement, though. The only concrete place we wrote things down was in Linux: . That's stricter than the toolchain side of things, though, as it specifically requires vendors to have a history of shipping before we take pre-publicly-availiable hardware. >> 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". IIRC the core of it was this "we'll take the support, but if the hardware doesn't show up on whatever timeline was announced then we'll aggressively remove it". That said, I can't find anything. >> 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. I'm fine with that.