From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 73410C11F66 for ; Tue, 29 Jun 2021 14:29:03 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 0565F61DC2 for ; Tue, 29 Jun 2021 14:29:03 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0565F61DC2 Authentication-Results: mail.kernel.org; dmarc=pass (p=none dis=none) header.from=nongnu.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:53020 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lyEjW-0000r6-5a for qemu-devel@archiver.kernel.org; Tue, 29 Jun 2021 10:29:02 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:54554) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lyEhY-0005pu-0y for qemu-devel@nongnu.org; Tue, 29 Jun 2021 10:27:00 -0400 Received: from rev.ng ([5.9.113.41]:45393) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lyEhW-0007nx-4e for qemu-devel@nongnu.org; Tue, 29 Jun 2021 10:26:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=rev.ng; s=dkim; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References: In-Reply-To:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=C0oNNss3yk+MPdbWuF9cAwJF9lFiz1Hhr600QnRL5us=; b=XY2vxAGqwq1F8PdB5tbicKJyWF T5gqGYxnaeDWoDL1yBKXLcmJ4q6pdSOewkuGwyfSjxZCBqP8/MHL8FtK5dx5x1EykW0DdkeP75tRc 5+OJbWxq5U/n1rILqQoIKrXnWeVzM0VihsrE6MzMQF09s6cMQxCWtSKoz/bUV+Zp6in0=; Date: Tue, 29 Jun 2021 16:26:38 +0200 To: "qemu-devel@nongnu.org" Cc: Taylor Simpson , Brian Cain , "babush@rev.ng" , "nizzo@rev.ng" , "philmd@redhat.com" , "richard.henderson@linaro.org" Subject: Re: [PATCH v5 10/14] target/hexagon: import parser for idef-parser Message-ID: <20210629162638.2db6fd62@orange> In-Reply-To: References: <20210619093713.1845446-1-ale.qemu@rev.ng> <20210619093713.1845446-11-ale.qemu@rev.ng> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=5.9.113.41; envelope-from=ale@rev.ng; helo=rev.ng X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" Reply-to: Alessandro Di Federico From: Alessandro Di Federico via On Thu, 24 Jun 2021 03:55:35 +0000 Taylor Simpson wrote: > > + | rvalue '[' rvalue ']' > > + { > > + @1.last_column = @4.last_column; > > + if ($3.type == IMMEDIATE) { > > + $$ = gen_tmp(c, &@1, $1.bit_width); > > + OUT(c, &@1, "tcg_gen_extract_i", &$$.bit_width, > > "("); > > + OUT(c, &@1, &$$, ", ", &$1, ", ", &$3, ", 1);\n"); > > + } else { > > + HexValue one = gen_imm_value(c, &@1, 1, > > $3.bit_width); > > + HexValue tmp = gen_bin_op(c, &@1, ASR_OP, &$1, > > &$3); > > + $$ = gen_bin_op(c, &@1, ANDB_OP, &tmp, &one); > > Can this be done with a tcg_gen_extract_tl or tcg_gen_sextract_tl? Those require translation-time constants as offsets while we need TCGv: tcg_gen_extract_i32(TCGv_i32 ret, TCGv_i32 arg, unsigned int ofs, unsigned int len); > Do you need to worry about signed-ness? `gen_bin_op` should take care of that. On Thu, 24 Jun 2021 03:55:35 +0000 Taylor Simpson wrote: > > +void imm_print(Context *c, YYLTYPE *locp, HexImm *imm) > > +{ > > + switch (imm->type) { > > + case I: > > + EMIT(c, "i"); > > + break; > > + case VARIABLE: > > + EMIT(c, "%ciV", imm->id); > > + break; > > + case VALUE: > > + EMIT(c, "((int64_t)%" PRIu64 "ULL)", (int64_t)imm->value); > > + break; > > + case QEMU_TMP: > > + EMIT(c, "qemu_tmp_%" PRIu64, imm->index); > > + break; > > + case IMM_PC: > > + EMIT(c, "ctx->base.pc_next"); > > + break; > > + case IMM_NPC: > > + EMIT(c, "ctx->npc"); > > + break; > > + case IMM_CONSTEXT: > > + EMIT(c, "insn->extension_valid"); > > The extension_valid field is a bool indicating if the instruction has > a constant extender. Don't you want the actual value here? No, this maps to Constant_extended: #define fREAD_GP() (Constant_extended ? (0) : GP) Constant extensions is handle for us externally. On Thu, 24 Jun 2021 03:55:35 +0000 Taylor Simpson wrote: > > + if (dest->bit_width != res.bit_width) { > > + res = rvalue_truncate(c, locp, &res); > > + } > > + > > + HexValue zero = gen_tmp_value(c, locp, "0", res.bit_width); > > + OUT(c, locp, "tcg_gen_movcond_i", &res.bit_width, > > "(TCG_COND_NE, ", dest); > > + OUT(c, locp, ", ", &width_orig, ", ", &zero, ", ", &res, ", ", > > dest, > > + ");\n"); > > + > > + rvalue_free(c, locp, &zero); > > + rvalue_free(c, locp, width); > > + rvalue_free(c, locp, &res); > > +} > > + > > +void gen_deposit_op(Context *c, > > + YYLTYPE *locp, > > + HexValue *dest, > > + HexValue *value, > > + HexValue *index, > > + HexCast *cast) > > What's the difference between this and the gen_rdeposit_op above? `gen_rdeposit_op` is general purpose, it takes start and width of the deposit. `gen_deposit_op` is more tailored to handle `fINSERT_BITS`. We will improve `gen_rdeposit_op` in order to handle the immediate case efficiently and then implement `gen_deposit_op` with `gen_rdeposit_op`. -- Alessandro Di Federico rev.ng