From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2064.outbound.protection.outlook.com [40.107.20.64]) by sourceware.org (Postfix) with ESMTPS id 5151A3858D32 for ; Thu, 13 Apr 2023 16:34:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5151A3858D32 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qxMTyx3HN6zK1yr8qPMci1l/fsb7hPTb9A5jVZrkIyE=; b=+Bah5Wd81Ik3HyOnx1+6lw4+ScsF1ukIEmwzWJA28Jdrf9rOwThzT311rLdz/Nn+b/zOYBvDvnq4LnvFIZywOfnQ8Lz4AQHZSPqANwa4SdozVmW8/NJ+gcSGvqEfQil67QrlElD/zBqBlaPOyxeb6uwhWGAnVF8/uCM/swlddoE= Received: from DU2PR04CA0207.eurprd04.prod.outlook.com (2603:10a6:10:28d::32) by AS8PR08MB6360.eurprd08.prod.outlook.com (2603:10a6:20b:33e::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6298.30; Thu, 13 Apr 2023 16:34:29 +0000 Received: from DBAEUR03FT045.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:28d:cafe::d5) by DU2PR04CA0207.outlook.office365.com (2603:10a6:10:28d::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6298.32 via Frontend Transport; Thu, 13 Apr 2023 16:34:29 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; pr=C Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DBAEUR03FT045.mail.protection.outlook.com (100.127.142.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6298.33 via Frontend Transport; Thu, 13 Apr 2023 16:34:29 +0000 Received: ("Tessian outbound 5154e9d36775:v136"); Thu, 13 Apr 2023 16:34:28 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 8e6680db2a275715 X-CR-MTA-TID: 64aa7808 Received: from 1f0c6ac44d1f.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 38514301-EF7E-4DCE-8F7C-662DAC584DF5.1; Thu, 13 Apr 2023 16:34:22 +0000 Received: from EUR01-VE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 1f0c6ac44d1f.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 13 Apr 2023 16:34:22 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MXjOIIaUGfPAIzaaTHoyFY9scudKTzRIQSpdYWgmeWMCoZnDzfp0gk6vHl9bLXifUx/27kx6AxfdsS4SE1j8wirG5qZP65XlbHT93V68bHofEd7wHBgOpEnhDzpXaMTGJ5uXGgFObiRvrWvrmenoeV1sc2rcLvcuN8WuYtrh4ngOaBGUkvQ8iLhTAj16zeuE2S1EJUnCyDZgQ8m9MSBMSrZzvt70IwC3SFWZiFsdWWEjCRVgU1Scka1DEJ/lVv1HWlpivLLYOuud0txLAEIEAbwfVgpo6shHA9fIHRqs9PkOsEnGXFb4+3paSKum5yXrObOUdCBmjJDmqjGcodKTOw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=qxMTyx3HN6zK1yr8qPMci1l/fsb7hPTb9A5jVZrkIyE=; b=BRjiJh417TGl+UDe9XpKSn6D4qK2kl1liWZyPQwLymWb/Qtmc4Og+SBqYrqZkdvDLhGCI0+f3Vrn+hDS+d00w7LLOjzr3pTVAD2Lftiz5IBPgVieGWtk3ikfO+d0aXrAPQhp4XTo5rE345/bRwjdJcWaLUqodGaRRyfaPH/zgrJUqY5s+nIaRHtLDZUlR6FttwWq5IhlPYKV/TlFxqAvPyDJiSVPFzj9ZAKcuwxJ1fpyDNY1gQY510nWZfhPCL3QMYARUgGjYJ6hXV1Ae6ob3TNeegbttPKbaKufOgPuVoBEFtZ0Y2p+faspHpLuNFi8ukIW2VbI5SnyNmgJPqVlRA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qxMTyx3HN6zK1yr8qPMci1l/fsb7hPTb9A5jVZrkIyE=; b=+Bah5Wd81Ik3HyOnx1+6lw4+ScsF1ukIEmwzWJA28Jdrf9rOwThzT311rLdz/Nn+b/zOYBvDvnq4LnvFIZywOfnQ8Lz4AQHZSPqANwa4SdozVmW8/NJ+gcSGvqEfQil67QrlElD/zBqBlaPOyxeb6uwhWGAnVF8/uCM/swlddoE= Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; Received: from VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) by VI1PR08MB10101.eurprd08.prod.outlook.com (2603:10a6:800:1ca::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6298.30; Thu, 13 Apr 2023 16:34:20 +0000 Received: from VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::ff70:5431:70fa:34bf]) by VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::ff70:5431:70fa:34bf%5]) with mapi id 15.20.6298.030; Thu, 13 Apr 2023 16:34:20 +0000 Message-ID: <56b69866-8f70-3bed-0645-79dcc4a99f23@arm.com> Date: Thu, 13 Apr 2023 17:34:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: [PATCH,v2 17/17] [gdb/docs] sme: Document SME registers and features Content-Language: en-US To: Eli Zaretskii Cc: gdb-patches@sourceware.org References: <20230411042658.1852730-18-luis.machado@arm.com> <20230412120444.2593312-1-luis.machado@arm.com> <835ya05i4r.fsf@gnu.org> <83leiv4xsc.fsf@gnu.org> From: Luis Machado In-Reply-To: <83leiv4xsc.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P123CA0198.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:1a4::23) To VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) MIME-Version: 1.0 X-MS-TrafficTypeDiagnostic: VI1PR08MB3919:EE_|VI1PR08MB10101:EE_|DBAEUR03FT045:EE_|AS8PR08MB6360:EE_ X-MS-Office365-Filtering-Correlation-Id: a413c8e5-12c8-4d2e-44c0-08db3c3cf3ea x-checkrecipientrouted: true NoDisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: tFgOXAMYpYySD3cUUrdhYzrpeXc9RugQowLYSDToKecdJqC9uRX0J1APYrm3el6q47U9ER4wh8g9GEsaS04vaoI0O+LF0YeGDDi+AzaslHBnbkqlVNw2MwXv+Dk0QQaYNSlAo9GpSrFrPyweDxZB0SfIt4vyGkp1iD7QbXAcaJr9zMZRYgk6gdnLHl/Oknqx14i6x6Wf33qIjgeLNgbliGAEA4e871LPgs/VOrZ1lMmydwp4W8rYMpW/DEBMGnlq2PP6uSxefmeV1vutgbNbABtiivA3QDv5fm7oIhO0sZCk/70GL4mPg/1sJCPTR3urMRDQjlmkWZNG0JQVjfH6EBhQA4clLWbCwyYL8P5I1zaxWamCeo+0CpbeaZj/pzCzzejvh2xMgreimOzTmsRi1UtKroE3YjGfrdRm7aOfwCRaWpKmDiqkuHLaAY6s+dXuGo0/dXCLxYMWK5kKreAxeg0abM80XpCACz82ReleF2vMPjgkL77/QwKdzHASCzcox9Rj+39BDlFyexGlV7ERntWWt9eEgeH5IaSC8wo0TOj4Bs6a7Q43LYQa654Gz1iSB94txk0kMHPkXUFrjAFf9VmOKiGGyEHDUjgI2xFt8YZgvSLb8B6b8YcFGsKwoUVC23aFeyjc9RxqYuQ1GrEJmQ== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VI1PR08MB3919.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230028)(4636009)(136003)(366004)(396003)(346002)(39850400004)(376002)(451199021)(2616005)(6506007)(83380400001)(186003)(6486002)(6666004)(478600001)(26005)(6512007)(53546011)(316002)(44832011)(36756003)(5660300002)(2906002)(38100700002)(66556008)(6916009)(4326008)(66476007)(41300700001)(66946007)(31696002)(8676002)(8936002)(86362001)(31686004)(66899021)(45980500001)(43740500002);DIR:OUT;SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB10101 Original-Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DBAEUR03FT045.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: d0665328-261f-4e40-aa91-08db3c3cee95 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: OwMP2/wQSCaQZFlvy8KVx9qAdVmzHj38xU2lDxtUzdtOrvyz0SzIp/Z+DAy0ySFmNb8ybRFqtAsIiEZXor69unbzIYrELIPzCdN58BbC7azEIDDSTOiNAf5pQz80uen9blNQu4vtjSCUBXdpyfusOVEg1o3F+/ZFGUjUTzxiwWCQET60QZ8fyKHMAfVN2Bwkhz5IGFUGhWqBJZkJVkUhYhetDFzLNxlRkCYSLVMxXJMgODj06epoPO4cisMeQlNBooOYk4kZLCGemY47s6+FrVEcbz+wQanR0vziw36dFNot81WSNaYXZNlFUuYvFhs7BDE79/WQTMnVzZgw/ZBKrCyBS+at3D08UUBW3A4a/ZhVs3NwYrr+hSZXnHnTjif2OjWmU3Tr/TDXD7cvq5VV7d7XLF0l2pboNGW6qfbbQbBPkoUVktj0xrA/jsmDB5ge9/mSJ0Evj90lD5qZRB7+S5jIhIN7+NHWd2/QYDehRdXj/tg55YMZlMkAe1KaUFV0Djv9cba5dJm1LBikkym+aAWZNNwLflKKNpaifqa4R3Q8xQ22Yzz7w4ZI8eA6fJAQVl8Uk1cIAx1hUMqLcxlU+KgEJmwbr9PAlqKz2ksLPRNLLhBWjCTqek6eI5nFz+yUm+bX70bujPGAqkJQbENOeLU11VEypHbjzVima7ckXgUDKi0WomQFaD6i1MuaDFS8j5HmbFbdEVvualGa8PQVoYiqNWkh1ktXSX8if9N20b4= X-Forefront-Antispam-Report: CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com;CAT:NONE;SFS:(13230028)(4636009)(136003)(396003)(346002)(39860400002)(376002)(451199021)(46966006)(40470700004)(36840700001)(66899021)(31686004)(36860700001)(5660300002)(41300700001)(82740400003)(40460700003)(36756003)(2906002)(31696002)(6862004)(8676002)(86362001)(40480700001)(356005)(4326008)(8936002)(44832011)(70586007)(70206006)(81166007)(82310400005)(316002)(2616005)(83380400001)(336012)(47076005)(6506007)(6512007)(26005)(53546011)(186003)(478600001)(6486002)(6666004)(43740500002);DIR:OUT;SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Apr 2023 16:34:29.0977 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a413c8e5-12c8-4d2e-44c0-08db3c3cf3ea X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: DBAEUR03FT045.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB6360 X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,FORGED_SPF_HELO,KAM_DMARC_NONE,KAM_STOCKTIP,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE,TXREP,UNPARSEABLE_RELAY 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 4/13/23 16:16, Eli Zaretskii wrote: >> Date: Thu, 13 Apr 2023 13:17:17 +0100 >> Cc: gdb-patches@sourceware.org >> From: Luis Machado >> >>> I suggest to call these parameters @var{nvl}, @var{nvq}, and >>> @var{nvg}, respectively. That is: (1) lower-case names, (2) name them >>> differently from the corresponding register, and (3) use @var markup. >>> This could mean the names are no longer identical to what you use in >>> the GDB sources, but the text is easier to read and less confusing, >>> because, for example, the difference between SVG the parameter and SVG >>> the register name is tricky, and confused even you (or at least it >>> confused me, see below). >>> >> >> I'm not sure that would be a good idea. These definitions (VL, VG and VQ, as well as the SME counterparts SVL, SVG and SVQ) >> are supposed to provide different views into the same data, the SVE vector length or the SME vector length. >> >> They are only supposed to help describe the concept of SVE/SME. > > The problem is that they cause confusion, because the names are the > same as the registers, modulo the letter-case. > >> I may be leaking some implementation details to the user's manual. > > I care much less about divulging the implementation details than I > care about clarity of the manual text and the potential for reader > confusion. > >> Would it help if we only mention these definitions when explaining >> the concept, but then restrict ourselves to only using the vg and >> svg registers when explaining how gdb deals with SVE and SME? > > Yes, if the text will be clear enough without alluding to these > definitions, then it will avoid the potential confusion that bothers > me. > I expect it to be more clear. I may have made a few mistakes before using lower case svq and svl, which should now be fixed in the upcoming version. Before I send an update though, I'd like to clarify the terminology and how I'm using it. Just a sanity check that it isn't confusing still. SVG, SVQ and SVL (upper case) are only definitions for SME. SVL is the vector size in bytes, SVG is SVL / 8 and SVQ is SVL / 16. All of them are vector sizes, but with different granularities. GDB exposes the SME vector size SVG as the svg (lower case) register, so users can check the current vector size and change it if they want. In the end, we have 3 definitions and a register. Does that make sense? >>>> +The @code{za} register is a 2-dimensional square @code{@var{n}x@var{n}} >>>> +matrix of bytes, where @var{n} is the streaming vector length (@code{SVL}. >>> >>> Here you could use the parameter explicitly: >>> >>> The @code{za} register is a 2-dimensional square >>> @code{@var{nsvl}x@var{nsvl}} matrix of bytes. >>> >> >> I'm having a hard time seeing the benefits of renaming SVL/SVQ/SVG to nsvl, nsvq and nsvg. >> >> The definition for SVL/SVQ/SVG is made clear above, at least I see it that way. > > My main point was that it is easier and clearer to say ABCxABC than to > use some unrelated symbol N and then explain that N equals to the > parameter ABC. But it's a minor issue. > That's fair. I find that slightly confusing too. What we should say, based on the SME vector size definitions above is: The @code{za} register is a 2-dimensional square @code{@var{SVL}x@var{SVL}} matrix of bytes. That makes it clear and obvious (to me) that we have a matrix of size SVL x SVL bytes. >>>> +Setting the @code{svg} register to the same value will have no >>>> +effect. >>> >>> What do you mean by "same" here? Do you mean to say that setting SVG >>> is only meaningful if the value is different from its current value? >>> >> >> It means if svg is 2 and you attempt to set it to 2 nothing will change in the >> register state. > > Then please say that without using the word "same" on its own. "Same" > begs the question "same as what?", which doesn't have an answer in > this context. > Ok. I think something like the following might address your concerns? Attempting to set the @code{svg} register value to its current value will have no effect. Whenever the @code{svg} register is modified with a new value, the following will be observed: >>>> +The possible values for @code{svg} are 2, 4, 8, 16, 32 (1, 2, 4, 8, 16 >>>> +for svq). >>> >>> Are these values for the SVG register or for the SVG parameter? Same >>> question about the reference to "svq". >>> >> >> The svg values are for both the register and the parameter. They are the same thing. >> >> As stated before, svg (the register) is simply how gdb exposes SVG (the definition). >> >> svq is only a concept. No registers expose it directly (though gdb uses this in the code). >> >> svl is the exact same situation as svq. It is a concept and there is no register exposing its >> value directly, but we use it internally in gdb's code. >> >> This is an extension to what SVE already established with vg, vq and vl. >> >> I can see where there is some confusion with the uppercase/lowercase uses of svq/svl. I've >> rectified that. Given svq/svl don't have register counterparts, I think it is fair to always use >> SVQ/SVL. > > This is all extremely confusing. I tried to explain why and proposed > a couple of possible solutions, but if you still insist on having in > the text both SVG and svg, SVL and svl, which are the same but not > really the same, then I'm not going to fight you. Just believe me: > this text _is_ confusing the way these symbols are used > interchangeably. > I think I messed up my explanation, as I mixed lower case with upper case. Hopefully the next iteration will be better. But basically svl and svq (lower case) shouldn't exist. They should be referenced as SVL and SVQ. Personally, I don't mind using SVG (definition) throughout as opposed to svg (register), as they mean the same to me. And should mean the same to users as well. The user can control the value of SVG through the GDB register svg. If I introduce the fact GDB exposes SVG through the svg register and then only use SVG for the rest of the text, that might make things less confusing. >> I noticed I missed a part of the tile slice register naming. I've reordered this block >> and rewritten some of it. How does it look? >> >> The tile slice pseudo registers have the following naming pattern: >> @code{za<@var{tile number}><@var{direction}>@var{qualifier} >> <@var{slice number}>}. >> >> There are up to 16 tiles (0 ~ 15), the direction can be either @code{v} >> (vertical) or @code{h} (horizontal), the qualifiers can be @code{b} (byte), >> @code{h} (halfword), @code{s} (word), @code{d} (doubleword) and @code{q} >> (quadword) and there are up to 256 slices (0 ~ 255) depending on the value >> of @code{svg}. The number of slices is the same as the value of @code{SVL}. >> >> The number of available tile slice pseudo-registers can be large. For a >> minimum @code{SVL} of 16 bytes, there are 5 (number of qualifiers) x >> 2 (number of directions) x 16 (@code{SVL}) pseudo registers. For the >> maximum @code{SVL} of 256 bytes, there are 5 x 2 x 256 pseudo registers. > > It's OK. > > Thanks.