Message ID | 20250124115209.3287742-1-jremus@linux.ibm.com |
---|---|
Headers |
Return-Path: <binutils-bounces~patchwork=sourceware.org@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id DCD083858417 for <patchwork@sourceware.org>; Fri, 24 Jan 2025 11:55:45 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DCD083858417 Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=ibm.com header.i=@ibm.com header.a=rsa-sha256 header.s=pp1 header.b=YHPV/zl1 X-Original-To: binutils@sourceware.org Delivered-To: binutils@sourceware.org Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id CCF183858D1E for <binutils@sourceware.org>; Fri, 24 Jan 2025 11:52:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CCF183858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=linux.ibm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linux.ibm.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org CCF183858D1E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=148.163.156.1 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1737719561; cv=none; b=oo+cOdHteMgfGRwM7aIqWTMdE6aQyV4dlEja/wc0ZtmBs4YQj7/VwE3nrq1sbqpfonVHmABLObwjjZqxsk1o04l1QoA/FjgWV0rzyP0Hl2ZEcPu0P1JX8untj47/GXoMFVmII6QYioNDZBKW5T2Itwz4DXaZts4phw+wzJ9EEvM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1737719561; c=relaxed/simple; bh=t+JPeyR0L59QFP0q4w4bYwpFl6MIm0FZTTLA+IxCmnE=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=nRxJfF89xEBQntTNbSDg3L/Mlt+Id9fGZt5g79mA3bqcTmcxkqiUaE5YbqVpbs3cja0l9sw/NdlUNhWi+A2tJGBGz33Bk4/BDAy1r5AY18ie8yXE+eKgqDyZ8uT9/Nvwd0jxj3XL6x+LfXi3gMD2u3bPOdd2qcpTGeMJvgxnPIU= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CCF183858D1E Received: from pps.filterd (m0360083.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 50O9WncU019254; Fri, 24 Jan 2025 11:52:37 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc :content-transfer-encoding:date:from:message-id:mime-version :subject:to; s=pp1; bh=w3Fkd3T0TvIg3qnGOJKfy3GwPNG8eQLcj9i0/rpqf T4=; b=YHPV/zl16J/WHbCqtwr/9uqj3L/b+pIQOhCt9G2T77KjzjkP4fKJmAHwD 9wZDaRlWWNAY4lhSRfN2v0j0m1SexBa3ymJTY7brN3rC14Ra9tDSVaLdV6HUQrxv tK+CBxMn/AEB09RpXQpOo+vR5PrdY3ZYH48ZT/6SArZJzHtQNqLmOJ5spCJuvGve BhL+tvyl5KgxzaUzSRHsdHWODpwVIPIM1sJfg/SL2UgPcxivQlpMv19zzLr8njf4 2kaSQ1zofHP/KruX7xScp3WW/7wnRIHREF3MQDVJIIYJqf9aDNnLfu5CI+pkD7GF to+TB+3vjR8z9b13Ov9zRxczw7EAw== Received: from ppma22.wdc07v.mail.ibm.com (5c.69.3da9.ip4.static.sl-reverse.com [169.61.105.92]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 44c0x93hs9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 24 Jan 2025 11:52:36 +0000 (GMT) Received: from pps.filterd (ppma22.wdc07v.mail.ibm.com [127.0.0.1]) by ppma22.wdc07v.mail.ibm.com (8.18.1.2/8.18.1.2) with ESMTP id 50O7oTDg024231; Fri, 24 Jan 2025 11:52:35 GMT Received: from smtprelay04.fra02v.mail.ibm.com ([9.218.2.228]) by ppma22.wdc07v.mail.ibm.com (PPS) with ESMTPS id 448q0ykc5a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 24 Jan 2025 11:52:35 +0000 Received: from smtpav03.fra02v.mail.ibm.com (smtpav03.fra02v.mail.ibm.com [10.20.54.102]) by smtprelay04.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 50OBqSpe33489652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 24 Jan 2025 11:52:28 GMT Received: from smtpav03.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 758DA200A2; Fri, 24 Jan 2025 11:52:28 +0000 (GMT) Received: from smtpav03.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 54B462009E; Fri, 24 Jan 2025 11:52:28 +0000 (GMT) Received: from tuxmaker.lnxne.boe (unknown [9.152.85.9]) by smtpav03.fra02v.mail.ibm.com (Postfix) with ESMTP; Fri, 24 Jan 2025 11:52:28 +0000 (GMT) From: Jens Remus <jremus@linux.ibm.com> To: binutils@sourceware.org, Andreas Krebbel <krebbel@linux.ibm.com> Cc: Jens Remus <jremus@linux.ibm.com>, Florian Krohm <flo2030@eich-krohm.de>, Ilya Leoshkevich <iii@linux.ibm.com>, Dominik Steenken <dost@de.ibm.com>, Ulrich Weigand <ulrich.weigand@de.ibm.com> Subject: [PATCH 0/4] s390: Make vector index register operands mandatory Date: Fri, 24 Jan 2025 12:52:05 +0100 Message-ID: <20250124115209.3287742-1-jremus@linux.ibm.com> X-Mailer: git-send-email 2.45.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-Proofpoint-GUID: cW1QAVvqefIsCvSTMfO5W22yd15ebhaO X-Proofpoint-ORIG-GUID: cW1QAVvqefIsCvSTMfO5W22yd15ebhaO X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1057,Hydra:6.0.680,FMLib:17.12.68.34 definitions=2025-01-24_04,2025-01-23_01,2024-11-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 adultscore=0 phishscore=0 mlxlogscore=999 priorityscore=1501 impostorscore=0 bulkscore=0 lowpriorityscore=0 malwarescore=0 mlxscore=0 suspectscore=0 spamscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2411120000 definitions=main-2501240084 X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, 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 X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Binutils mailing list <binutils.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/binutils>, <mailto:binutils-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/binutils/> List-Post: <mailto:binutils@sourceware.org> List-Help: <mailto:binutils-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/binutils>, <mailto:binutils-request@sourceware.org?subject=subscribe> Errors-To: binutils-bounces~patchwork=sourceware.org@sourceware.org |
Series |
[1/4] s390: Additional tests for omitted base register operands
|
|
Message
Jens Remus
Jan. 24, 2025, 11:52 a.m. UTC
Index register operands in a conventional displacement D, index X, and base (B) triplet "D(X,B)" are treated as optional. This is because register 0 contents are not used in conventional addressing computations. Instead a value of zero is implied. The assembler therefore implies register 0, if an index/base register is omitted (e.g. when coding "D(,B)" or "D(B)"). The disassembler disassembles index/base register 0 as "0" instead of "%r0", as this clarifies that a value of zero is implied instead of using the contents of register 0. Vector index register operands, so far only used in the VRV instruction format, are different though. Vector index register 0 contents are used in the addressing computation: "For VRV format instructions, a vector element is used in the formation of the intermediate value. This vector element is an unsigned binary integer value that is added to the base address and 12-bit displacement to form a 64-bit intermediate sum. The vector element is designated by a vector register and an element index. A zero V field accesses the element in vector register zero and does not imply a zero value." [1] Therefore make the following changes to the assembler and disassembler: Patch 2 changes the disassembler to no longer omit vector index register 0 operands in disassembly. Furthermore it disassembles them as "%v0" instead of "0" to clarify, that the vector register 0 value is used in the addressing computation. Patch 3 changes the assembler not to warn about vector index register 0 being used. Patch 4 changes the assembler to require the specification of vector index register operands. That is they may no longer be omitted. This is a non-backward compatible change. The rationale is that any (very unlikely) existing assembler code that omits the specification of vector index register 0, may potentially be in error, as the programmer may likely have assumed a value of zero to be implied instead of vector register 0 contents to be used. Regards, Jens Jens Remus (4): s390: Additional tests for omitted base register operands s390: Do not omit vector index register 0 in disassembly s390: Do not warn about vector index register 0 in assembly s390: Error if vector index register omitted in assembly gas/config/tc-s390.c | 13 ++++- .../gas/s390/zarch-base-index-0-err.l | 18 ++++-- .../gas/s390/zarch-base-index-0-err.s | 10 +++- gas/testsuite/gas/s390/zarch-base-index-0.d | 26 +++------ gas/testsuite/gas/s390/zarch-base-index-0.s | 18 +++--- .../gas/s390/zarch-omitted-base-index-err.l | 37 ++++++------ .../gas/s390/zarch-omitted-base-index-err.s | 3 + .../gas/s390/zarch-omitted-base-index.d | 5 +- .../gas/s390/zarch-omitted-base-index.s | 6 +- gas/testsuite/gas/s390/zarch-warn-areg-zero.l | 16 +++--- gas/testsuite/gas/s390/zarch-warn-areg-zero.s | 56 +++++++++---------- opcodes/s390-dis.c | 13 ++--- 12 files changed, 121 insertions(+), 100 deletions(-)
Comments
Hi Jens, the patches are ok. Thanks for taking care of this! Clearly an oversight in my initial implementation :( Bye, Andreas On 1/24/25 12:52 PM, Jens Remus wrote: > Index register operands in a conventional displacement D, index X, and > base (B) triplet "D(X,B)" are treated as optional. This is because > register 0 contents are not used in conventional addressing > computations. Instead a value of zero is implied. > The assembler therefore implies register 0, if an index/base register > is omitted (e.g. when coding "D(,B)" or "D(B)"). > The disassembler disassembles index/base register 0 as "0" instead of > "%r0", as this clarifies that a value of zero is implied instead of > using the contents of register 0. > > Vector index register operands, so far only used in the VRV instruction > format, are different though. Vector index register 0 contents are used > in the addressing computation: > > "For VRV format instructions, a vector element is used in the formation > of the intermediate value. This vector element is an unsigned binary > integer value that is added to the base address and 12-bit displacement > to form a 64-bit intermediate sum. The vector element is designated by > a vector register and an element index. A zero V field accesses the > element in vector register zero and does not imply a zero value." [1] > > Therefore make the following changes to the assembler and disassembler: > > Patch 2 changes the disassembler to no longer omit vector index > register 0 operands in disassembly. Furthermore it disassembles them > as "%v0" instead of "0" to clarify, that the vector register 0 value is > used in the addressing computation. > > Patch 3 changes the assembler not to warn about vector index register 0 > being used. > > Patch 4 changes the assembler to require the specification of vector > index register operands. That is they may no longer be omitted. This > is a non-backward compatible change. The rationale is that any (very > unlikely) existing assembler code that omits the specification of > vector index register 0, may potentially be in error, as the programmer > may likely have assumed a value of zero to be implied instead of vector > register 0 contents to be used. > > Regards, > Jens > > Jens Remus (4): > s390: Additional tests for omitted base register operands > s390: Do not omit vector index register 0 in disassembly > s390: Do not warn about vector index register 0 in assembly > s390: Error if vector index register omitted in assembly > > gas/config/tc-s390.c | 13 ++++- > .../gas/s390/zarch-base-index-0-err.l | 18 ++++-- > .../gas/s390/zarch-base-index-0-err.s | 10 +++- > gas/testsuite/gas/s390/zarch-base-index-0.d | 26 +++------ > gas/testsuite/gas/s390/zarch-base-index-0.s | 18 +++--- > .../gas/s390/zarch-omitted-base-index-err.l | 37 ++++++------ > .../gas/s390/zarch-omitted-base-index-err.s | 3 + > .../gas/s390/zarch-omitted-base-index.d | 5 +- > .../gas/s390/zarch-omitted-base-index.s | 6 +- > gas/testsuite/gas/s390/zarch-warn-areg-zero.l | 16 +++--- > gas/testsuite/gas/s390/zarch-warn-areg-zero.s | 56 +++++++++---------- > opcodes/s390-dis.c | 13 ++--- > 12 files changed, 121 insertions(+), 100 deletions(-) >
Thanks! Committed to mainline. Regards, Jens On 27.01.2025 10:39, Andreas Krebbel wrote: > Hi Jens, > > the patches are ok. Thanks for taking care of this! Clearly an oversight in my initial implementation :( > > Bye, > > Andreas > > > On 1/24/25 12:52 PM, Jens Remus wrote: >> Index register operands in a conventional displacement D, index X, and >> base (B) triplet "D(X,B)" are treated as optional. This is because >> register 0 contents are not used in conventional addressing >> computations. Instead a value of zero is implied. >> The assembler therefore implies register 0, if an index/base register >> is omitted (e.g. when coding "D(,B)" or "D(B)"). >> The disassembler disassembles index/base register 0 as "0" instead of >> "%r0", as this clarifies that a value of zero is implied instead of >> using the contents of register 0. >> >> Vector index register operands, so far only used in the VRV instruction >> format, are different though. Vector index register 0 contents are used >> in the addressing computation: >> >> "For VRV format instructions, a vector element is used in the formation >> of the intermediate value. This vector element is an unsigned binary >> integer value that is added to the base address and 12-bit displacement >> to form a 64-bit intermediate sum. The vector element is designated by >> a vector register and an element index. A zero V field accesses the >> element in vector register zero and does not imply a zero value." [1] >> >> Therefore make the following changes to the assembler and disassembler: >> >> Patch 2 changes the disassembler to no longer omit vector index >> register 0 operands in disassembly. Furthermore it disassembles them >> as "%v0" instead of "0" to clarify, that the vector register 0 value is >> used in the addressing computation. >> >> Patch 3 changes the assembler not to warn about vector index register 0 >> being used. >> >> Patch 4 changes the assembler to require the specification of vector >> index register operands. That is they may no longer be omitted. This >> is a non-backward compatible change. The rationale is that any (very >> unlikely) existing assembler code that omits the specification of >> vector index register 0, may potentially be in error, as the programmer >> may likely have assumed a value of zero to be implied instead of vector >> register 0 contents to be used. >> >> Regards, >> Jens >> >> Jens Remus (4): >> s390: Additional tests for omitted base register operands >> s390: Do not omit vector index register 0 in disassembly >> s390: Do not warn about vector index register 0 in assembly >> s390: Error if vector index register omitted in assembly >> >> gas/config/tc-s390.c | 13 ++++- >> .../gas/s390/zarch-base-index-0-err.l | 18 ++++-- >> .../gas/s390/zarch-base-index-0-err.s | 10 +++- >> gas/testsuite/gas/s390/zarch-base-index-0.d | 26 +++------ >> gas/testsuite/gas/s390/zarch-base-index-0.s | 18 +++--- >> .../gas/s390/zarch-omitted-base-index-err.l | 37 ++++++------ >> .../gas/s390/zarch-omitted-base-index-err.s | 3 + >> .../gas/s390/zarch-omitted-base-index.d | 5 +- >> .../gas/s390/zarch-omitted-base-index.s | 6 +- >> gas/testsuite/gas/s390/zarch-warn-areg-zero.l | 16 +++--- >> gas/testsuite/gas/s390/zarch-warn-areg-zero.s | 56 +++++++++---------- >> opcodes/s390-dis.c | 13 ++--- >> 12 files changed, 121 insertions(+), 100 deletions(-) >>