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=-1.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE, MAILING_LIST_MULTI,PDS_BAD_THREAD_QP_64,SPF_HELO_NONE,SPF_PASS, T_KAM_HTML_FONT_INVALID 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 EB7BBC433B4 for ; Thu, 22 Apr 2021 12:41:06 +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 03191610E6 for ; Thu, 22 Apr 2021 12:41:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 03191610E6 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=eldorado.org.br Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:37720 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lZYdk-0006kj-LL for qemu-devel@archiver.kernel.org; Thu, 22 Apr 2021 08:41:04 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:54022) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lZYY2-0002wa-0y; Thu, 22 Apr 2021 08:35:10 -0400 Received: from mail-eopbgr790134.outbound.protection.outlook.com ([40.107.79.134]:2800 helo=NAM03-CO1-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lZYXu-0007RI-4w; Thu, 22 Apr 2021 08:35:09 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=K4kVALI8Y4f/58KdpHJoAMkCVw5E0lXzjf2RXjzfoiztm2fE6p9GfoO+IMIEysTxJMlHpuq1LpmGBGlakFipx6OHKHfI8y+mm0GU5Hj+5jMMpXENQ4lXvKoS9vmXrNhqVEeEtC/lKFVG0aNk5gfu5hzpeuo9anap8WjmoessfZRYgEGd+vXLL7+mxGLz18kKPYdVQnDAyJY6PaLHRSZDKXepjo2hzcoi/LjTh0bSaf9iz3oO/pXuD7lDRSl5KbFJdBZ2kJFhbfyKIIDK7mD5JncpHvEgQJUIjC1X9rbqP+A1ZZkW4qkEsU3ubiaSaBJcJSyaTLmMa2mdEoNUSMweCQ== 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-SenderADCheck; bh=S2wKbQuD25O4Opc00A9MOlNjixI/OB8/E1ryfJgNR1k=; b=fUoy6B7nUgR3aJ3TLhEvRGsMYRoSCWo5ptRVpfZG5srxigIMVGybfvmXynluIWYhg+hPOChKYP1+7xJVRE+0V6UumeHc7SXvob8gWHGAosiMai/QvgDm2O2ZJT4JXpG6VCV7UiBl+rOYoaku3D0JuMDRxraB+3gpL0mrHYGmS+/TQHLMuWPnrZQnOhbpGHG6Oy3HUqYi3hXIeB/gj7h2xjJ2a3m9cx9vL0ewbzCFbeKMkvowZdyIWoTZLXodAldzTVrJHInoDKmut4kx3VUk4QpZwTfd7EArnj32NkyS6Az640VpaSmSTx2CRqxqwUpYYrzGOYdK5lPDOivaJGll+Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=eldorado.org.br; dmarc=pass action=none header.from=eldorado.org.br; dkim=pass header.d=eldorado.org.br; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eldorado.org.br; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=S2wKbQuD25O4Opc00A9MOlNjixI/OB8/E1ryfJgNR1k=; b=igcWjTTA2lJ9EE35dH//4/cs12KpjgkzoZ+AvepFkOZHreflSKGoTYDzLLdKcEBosw4zIJkG+79mD/B35cfNx0UQ9Wm8c+fC1rTEoWyDJ+33gpGZCTB9bXwgHe+LUqPNG7fn1FvpPnk+TKNlcpM8zx4H0fshHMPa3Pz8yImzN1cjHaz1EOcOIW+IsxdykfIdAehMnhcoBDA/2ZIKaPj1f9c6r4H/eCH9dfIhfALlwb0VykClF307km+qvOluHKLQWWPl9qRXnvxznEU7Yw4E8rybMRO7e6vlXD6Vv/dyukBhRQ3j8KeBLX1akcntxRPNyl9pm4uzjp2KdGjm+N13pQ== Received: from CP2PR80MB4499.lamprd80.prod.outlook.com (2603:10d6:102:45::19) by CPXPR80MB4967.lamprd80.prod.outlook.com (2603:10d6:103:9::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.21; Thu, 22 Apr 2021 12:34:56 +0000 Received: from CP2PR80MB4499.lamprd80.prod.outlook.com ([fe80::8c79:76c:3d1f:d59b]) by CP2PR80MB4499.lamprd80.prod.outlook.com ([fe80::8c79:76c:3d1f:d59b%7]) with mapi id 15.20.4065.020; Thu, 22 Apr 2021 12:34:55 +0000 From: Bruno Piazera Larsen To: David Gibson Subject: RE: [PATCH 1/4] target/ppc: Code motion required to build disabling tcg Thread-Topic: [PATCH 1/4] target/ppc: Code motion required to build disabling tcg Thread-Index: AQHXN2hQ+6ch1mzZa0+go8E8CBF19A== Date: Thu, 22 Apr 2021 12:34:55 +0000 Message-ID: Accept-Language: pt-BR, en-US Content-Language: pt-BR X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gibson.dropbear.id.au; dkim=none (message not signed) header.d=none; gibson.dropbear.id.au; dmarc=none action=none header.from=eldorado.org.br; x-originating-ip: [2804:14c:482:7ed1:450e:1599:3947:d5be] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b063325e-e8d5-4ba4-0186-08d9058b08fa x-ms-traffictypediagnostic: CPXPR80MB4967: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: x9TW1zeORI7YmYwolfIJnGpw29AG5RoYwLW7NE0qvuaKU5TAcv9tpAc3J6q6ERwxMCd3CAn+S2oF0Hdazzs+EexkX2xFfu3v3wppfLGRs4BPxZT5bDMCW7WAV3w6QqYYQmzZvvsYdrmkVcYQZnqxLIlfnwtd69UgejqHNdfbg+4Vj48eW9+xLjxGfdDjVFVFqrdHpFPfnnfQrnSK3a4qZiRcDWNbl+oOnPpzaPs13ArZ92jlHZ+3dvrj3YbiIglzzA234nCfcc7H/wLygfoCZbX3QGg0ToPyab9XmkvEdu2IaZs7HFqexCmhIdHXvKCj7F0DLXdSpOM+NEs+n7lSZPip3C7BG4eR+Vlek0Q9/PJJEF73ugwepKV3q9wGORXzbzwTtCBQC9TQr0oUh29e5dXLwvWWBFUzfkI/YHQyrteH8Q+OXQm0ae+c+W5LhUjj8DRQ5ytM5TyBLSkVCy4C0ELVqt56bxQmk3hyxhwg8TmVa954EgP3wj3wu2NGCzvSHCFhp50lnnLdQvpOs06RhRbciNf2q1VBjAEkMTlzJZ1WvjmCrrTvh+FHI3KIeftucwxkBdO9GnhvWBM8bdCBCFnS6mMq02024Yc5Ca+5Y+m8u92B9iIglCdGWirV18rsR/JhAzziP/eJW4Ny7EvR/Brcb80JxWyInhELXOUiGEfVG25eoRPHXUQj9Z29pJl6 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CP2PR80MB4499.lamprd80.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(366004)(39840400004)(396003)(376002)(346002)(8676002)(54906003)(21615005)(83380400001)(107886003)(122000001)(4326008)(316002)(166002)(7696005)(6916009)(478600001)(66446008)(66476007)(186003)(2906002)(86362001)(64756008)(9686003)(66556008)(6506007)(5660300002)(52536014)(966005)(76116006)(33656002)(71200400001)(8936002)(38100700002)(19627405001)(66946007)(55016002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?C2W5+b+7q+EMA5eCJwujvSyhpSCV0dAe31Uv4X2qHZGo8S1Ya3uBough51?= =?iso-8859-1?Q?wKDufsoGwRIC/QQObiuPRYhnFerCjwb34ATJFY/hs8DybX0d60e0GwoHgw?= =?iso-8859-1?Q?v31xmJcc52a+pfb69pf0qCP0ap1580E1oI+2JiDNDbQTIWucNcQzKZJMk0?= =?iso-8859-1?Q?PeEScLF/TZuna8U0qpfMEIPiCeyYZ/cSvs9Z13oSOZm5j7XDMyUGlxSgR9?= =?iso-8859-1?Q?jgNm5WgbOObcZMqwxvRltcQ6GovCj6lTF48xmXbb6lbJyxejezVVr/2EtQ?= =?iso-8859-1?Q?BHfM++fwOhcY3SC0NWT/drQgfqqVzsVKu2MpTGJZWsQ8srTBbqYrhkOX+4?= =?iso-8859-1?Q?yMooYnG9uJhHMzSL/j9Zj6EH52WQDoMU+TWE8karq9BUYlQwfwYXRrL3qr?= =?iso-8859-1?Q?xOWx2KbX75bgj26yiUyL0SXCeV1gT4Bxc4hprmN5poEYOusWykZSXjwVwJ?= =?iso-8859-1?Q?+7AzBeZ/iVYZG2exfzibkwf+LthvmsUz/Vpiru2b6c2VXanlz1FG1INaF9?= =?iso-8859-1?Q?IPhpg1l3jCGSaL8uqfpvt8X4bCtAomvgFr41SmGvuYLW2kcLtdAzvLjPb0?= =?iso-8859-1?Q?OCTaAY9PusICFVmr/MmQcrDUDfICJh5y3ziamqDntWF8841B+oKgl+nIj+?= =?iso-8859-1?Q?vjpkkG8zXivkaQC55fahrLYCfCY5pO3FkeFC2TYNSiSf1ebdhRkrZoJogt?= =?iso-8859-1?Q?TG3yXEtpi6mCrFq3I6Ie2lzwPEYJp6S4KdrLn8PQVrXQ4yYDlFMFuPUdHf?= =?iso-8859-1?Q?DE/1ShwibFIbjddHgMI77ABQZzfyk+Zx2t8dH/nkCo/GX0mzaokwojWXG1?= =?iso-8859-1?Q?pXUofm5azZGsf9IoGP+jOT4pSldNL5sAgVNQLbyjlybntEDJOJIARm8jF7?= =?iso-8859-1?Q?vxDvIazcey40fpVv83M2WTnUCa2odi2GKXKdNpg9kvdrCEy9H9sOw31jhi?= =?iso-8859-1?Q?SKYeUaIY/q89kB/tT+K4pMXpsoTJYXJFCseUbW3skheQmtgJgSMzge2QzD?= =?iso-8859-1?Q?CDtp1P4Il/NWvoaUiQjH5G+BV8rT8X4jIJfZlpbDUSg2I/YC7tWvWFlUKE?= =?iso-8859-1?Q?4+rGCKtXaUWJvV5hjH1AW+ZjaoDFzRIO6Vlz0AS9LeN+D160M4UR3S4j6Z?= =?iso-8859-1?Q?rSk4JyzxOTavSVoeDrBXSdZQLbY1CNjB93HawOSkPx/gT9pl65t0qv5R3y?= =?iso-8859-1?Q?H/GQxD0X+xCQ5FLY8XYFOsde9fZAl8brKZE2dqzjECxYA//su31sMCCmud?= =?iso-8859-1?Q?3mavqrnnWWYHgwLZm7b9TDIZSbB8DqJkmX9steF27u1OgQsKfAyPj5ZuDv?= =?iso-8859-1?Q?x8/Ok0W506wNgkdx7jCTJA4wPeR3+s1SQcwjeCUKnJTNAa3ubA84qjcg4w?= =?iso-8859-1?Q?3JLEHPTKxzTHrsBTbzcrbvCh9tJU1C66WGJfroKJxsUg+0tATK7CQ=3D?= Content-Type: multipart/alternative; boundary="_000_CP2PR80MB44990338BCF641993404B901C7469CP2PR80MB4499lamp_" MIME-Version: 1.0 X-OriginatorOrg: eldorado.org.br X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CP2PR80MB4499.lamprd80.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b063325e-e8d5-4ba4-0186-08d9058b08fa X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Apr 2021 12:34:55.5872 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b9397c69-e827-4afc-a365-ab275e41638f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: tNqx9TUGysdRSK96ot+WzyW0lWdEJZ3Jm10wE7b07A3qboDmgc5dN1Sd5UXg6LOhM5nfn0pijmRmdIOGO4iph86wunfz4W8buBBRUORIszc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CPXPR80MB4967 Received-SPF: pass client-ip=40.107.79.134; envelope-from=bruno.larsen@eldorado.org.br; helo=NAM03-CO1-obe.outbound.protection.outlook.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01 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: , Cc: Thomas Huth , Fabiano Rosas , "qemu-devel@nongnu.org" , Andre Fernando da Silva , Lucas Mateus Martins Araujo e Castro , Fernando Eckhardt Valle , "qemu-ppc@nongnu.org" , "lagarcia@br.ibm.com" , Matheus Kowalczuk Ferst , Luis Fernando Fujita Pires Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" --_000_CP2PR80MB44990338BCF641993404B901C7469CP2PR80MB4499lamp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > > You are correct! I've just tweaked the code that defines spr_register a= nd > > it should be working now. I'm still working in splitting the SPR functi= ons > > from translate_init, since I think it would make it easier to prepare t= he > > !TCG case and for adding new architectures in the future, and I found a > > few more problems: > > Actually looking at the stuff below, I suspect that separating our > "spr" logic specifically might be a bad idea. At least some of the > SPRs control pretty fundamental things about how the processor > operates, and I suspect separating it from the main translation logic > may be more trouble than it's worth. Well, all the errors that I got were related to to read/write functions, wh= ich I was already separating into a spr_tcg file. The solutions I can see are t= o include this file in translate.c, and either have the read/write functions = not be static, or include the spr_common.c in translate as well, but only for TCG builds. Both solutions sound pretty bad imo, but the first sounds less bad, because it's a bit less complexity in the build process. Other than that, I don't really see how we can support a !TCG build without separating SPR, exactly because they are very fundamental to the processor. Am I missing something? I fully expect to be, at this point, things are turning out even more complicated than I expected Bruno Piazera Larsen Instituto de Pesquisas ELDORADO Departamento Computa=E7=E3o Embarcada Analista de Software Trainee Aviso Legal - Disclaimer ________________________________ De: David Gibson Enviadas: Quarta-feira, 21 de Abril de 2021 02:13 Para: Bruno Piazera Larsen Cc: Fabiano Rosas; Thomas Huth; qemu-devel@nongnu.org; lagarcia@br.ibm.com;= Lucas Mateus Martins Araujo e Castro; Fernando Eckhardt Valle; qemu-ppc@no= ngnu.org; Andre Fernando da Silva; Matheus Kowalczuk Ferst; Luis Fernando F= ujita Pires Assunto: Re: [PATCH 1/4] target/ppc: Code motion required to build disablin= g tcg On Tue, Apr 20, 2021 at 07:02:36PM +0000, Bruno Piazera Larsen wrote: > > > What I was doing was to only register the spr once, and use the > > > accel-specific functions to set the relevant attributes, so spr_commo= n > > > wouldn't need to where (and if) spr_read_* exists or not. > > > Would this work? > > > > > > Just ignoring the read and write functions means we still need > > > to compile them, or at least stub them, otherwise we'd get linker > > > problems. > > > > Not if you use a macro which will simply elide the references in the > > !TCG case. Actually I think even an inline wrapper will do it, I'm > > pretty sure the compiler is smart enough to optimize the references > > out in that case. > > You are correct! I've just tweaked the code that defines spr_register and > it should be working now. I'm still working in splitting the SPR function= s > from translate_init, since I think it would make it easier to prepare the > !TCG case and for adding new architectures in the future, and I found a > few more problems: Actually looking at the stuff below, I suspect that separating our "spr" logic specifically might be a bad idea. At least some of the SPRs control pretty fundamental things about how the processor operates, and I suspect separating it from the main translation logic may be more trouble than it's worth. > 1. Global variables being defined in translate.c and used both there and > in spr functions. The variables in question are: cpu_gpr, cpu_so, cpu_ov, > cpu_ca, cpu_ov32, cpu_ca32, cpu_xer, cpu_lr and cpu_ctr. The easy way > out is to have global "getters" and "setters" for those, but I'm not sure > it's a good solution. Yeah, that seems really messy, plus those are special variables used by TCG generated code whose operation I don't really understand. > 2. Static functions defined in translate.c, used there and TCG-related > spr functions. They are: gen_load_spr, gen_store_spr, gen_stop_exception, > gen_inval_exception. The easy solution is adding a prototype to internal.= h > and removing the static, but again, not sure it's a good solution I think gen_*() functions should stay in translate.c, since they are, explicitly, about translation ("gen" for "generating code"). > 3. gen_read_xer (currently in spr_common) calls is_isa300, defined in > include/disas/disas.h, which is a macro that dereferences DisasContext. > However, the struct is defined in translate.c. This one is pretty easy, I= think, > it's just turning the macro into a function, but since I'm already e-mail= ing, > I figured I might as weel ask. > > Finally, since most read and write functions are static, I added them to > spr_tcg.c.inc to be included only with TCG, as a quick fix, but I would r= eally > prefer some other solution if there is anything better. Any thoughts on t= his? > > IIRC, this is the last thing holding me back from an RFC with this motion > patch > > > Bruno Piazera Larsen > > Instituto de Pesquisas ELDORADO > > Departamento Computa=E7=E3o Embarcada > > Analista de Software Trainee > > Aviso Legal - Disclaimer -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson --_000_CP2PR80MB44990338BCF641993404B901C7469CP2PR80MB4499lamp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
> > You are correct! = I've just tweaked the code that defines spr_register and
> > it should be working now. I'm still working in splitting the SPR = functions
> > from translate_init, since I think it would make it easier to pre= pare the
> > !TCG case and for adding new architectures in the future, and I f= ound a
> > few more problems:
>
> Actually looking at the stuff below, I suspect that separating our
> "spr" logic specifically might be a bad idea.  At least= some of the
> SPRs control pretty fundamental things about how the processor
> operates, and I suspect separating it from the main translation logic<= br> > may be more trouble than it's worth.

Well, all the errors that I= got were related to to read/write functions, which
I was already separating in= to a spr_tcg file. The solutions I can see are to
include this file in transl= ate.c, and either have the read/write functions not be
static, or include <= /font>the spr_common.c in translate as well, but only for TCG
builds. Both solutions sound pretty bad imo, but the first sounds less bad,=
because it's a bit less complexity in the build process.

Other than that, I don't really see how we can support a !TCG build without=
separating SPR, exactly because they are very fundamental to the processor.=
Am I missing something? I fully expect to be, at this point, things are
turning out even more complicated than I expected


Bruno Piazer= a Larsen

Instituto de Pesquisas ELDORADO

Departamento= Computa=E7=E3o Embarcada

Analista de = Software Trainee

Aviso Legal - Disclaimer


De: David Gibson
Enviadas: Quarta-feira, 21 de Abril de 2021 02:13
Para: Bruno Piazera Larsen
Cc: Fabiano Rosas; Thomas Huth; qemu-devel@nongnu.org; lagarcia@br.i= bm.com; Lucas Mateus Martins Araujo e Castro; Fernando Eckhardt Valle; qemu= -ppc@nongnu.org; Andre Fernando da Silva; Matheus Kowalczuk Ferst; Luis Fer= nando Fujita Pires
Assunto: Re: [PATCH 1/4] target/ppc: Code motion required to build d= isabling tcg

On Tue, Apr 20, 2021 at 07:02:36PM +0000, Bruno Pi= azera Larsen wrote:
> > > What I was doing was to only register the spr once, and use = the
> > > accel-specific functions to set the relevant attributes, so = spr_common
> > > wouldn't need to where (and if) spr_read_* exists or not. > > > Would this work?
> > >
> > > Just ignoring the read and write functions means we still ne= ed
> > > to compile them, or at least stub them, otherwise we'd get l= inker
> > > problems.
> >
> > Not if you use a macro which will simply elide the references in = the
> > !TCG case.  Actually I think even an inline wrapper will do = it, I'm
> > pretty sure the compiler is smart enough to optimize the referenc= es
> > out in that case.
>
> You are correct! I've just tweaked the code that defines spr_register = and
> it should be working now. I'm still working in splitting the SPR funct= ions
> from translate_init, since I think it would make it easier to prepare = the
> !TCG case and for adding new architectures in the future, and I found = a
> few more problems:

Actually looking at the stuff below, I suspect that separating our
"spr" logic specifically might be a bad idea.  At least some= of the
SPRs control pretty fundamental things about how the processor
operates, and I suspect separating it from the main translation logic
may be more trouble than it's worth.

> 1. Global variables being defined in translate.c and used both there a= nd
> in spr functions. The variables in question are: cpu_gpr, cpu_so, cpu_= ov,
> cpu_ca, cpu_ov32, cpu_ca32, cpu_xer, cpu_lr and cpu_ctr. The easy way<= br> > out is to have global "getters" and "setters" for = those, but I'm not sure
> it's a good solution.

Yeah, that seems really messy, plus those are special variables used
by TCG generated code whose operation I don't really understand.

> 2. Static functions defined in translate.c, used there and TCG-related=
> spr functions. They are: gen_load_spr, gen_store_spr, gen_stop_excepti= on,
> gen_inval_exception. The easy solution is adding a prototype to intern= al.h
> and removing the static, but again, not sure it's a good solution

I think gen_*() functions should stay in translate.c, since they are,
explicitly, about translation ("gen" for "generating code&qu= ot;).

> 3. gen_read_xer (currently in spr_common) calls is_isa300, defined in<= br> > include/disas/disas.h, which is a macro that dereferences DisasContext= .
> However, the struct is defined in translate.c. This one is pretty easy= , I think,
> it's just turning the macro into a function, but since I'm already e-m= ailing,
> I figured I might as weel ask.
>
> Finally, since most read and write functions are static, I added them = to
> spr_tcg.c.inc to be included only with TCG, as a quick fix, but I woul= d really
> prefer some other solution if there is anything better. Any thoughts o= n this?
>
> IIRC, this is the last thing holding me back from an RFC with this mot= ion
> patch
>
>
> Bruno Piazera Larsen
>
> Instituto de Pesquisas ELDORADO<http://clickemailmkt.eldorado.org.br/ls/click?upn=3DUPoxpeIcHnAcbUZyo7TTas= wyiVb1TXP3jEbQqiiJKKGsxOn8hBEs5ZsMLQfXkKuKXZ7MVDg0ij9eG8HV4TXI75dBzDiNGLxQ8= Xx5PzCVNt6TpGrzBbU-2Biu0o69X5ce-2FW-2FOk1uUipuK0fZnWXJEgbRw-3D-3DJY4T_wWk-2= BG6VvNBoa1YzxYjhCdFS9IfANIaBzDSklR1NyyrKOI1wj0P-2BdBFcuO4FnHcsA1MyHu0ly1Yt3= oDMp7KKdJPM68iKuI2jiRH5v4B0d8wf3chU3qy5n5iXWnW1QjSaNFHOgELzxaP-2FnesTeBgJ5d= FkjH4f279sVQpOtyjw5xAqj34M6pgNRAxVvuXif4IWDcVzXg1FzfYlEfkKzr9vvpA3Hg8kitwMt= lU3zwbQUBCgL30fQoJPcRPMGKyOY8RmoAlXNqTJYDYIvqmfnI7KLUvw6vKB5R-2B5q1FJRAzX7H= -2BmF0NnDET6jMLuIqtCcVIch>
>
> Departamento Computa=E7=E3o Embarcada
>
> Analista de Software Trainee
>
> Aviso Legal - Disclaimer<https://www.eldorado.org.br/disclaimer.html>

--
David Gibson          &nb= sp;         | I'll have my music ba= roque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _th= e_ _other_
            &nb= sp;            =        | _way_ _around_!
http://www.ozlabs.org/~dgibson
--_000_CP2PR80MB44990338BCF641993404B901C7469CP2PR80MB4499lamp_--