All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Edgar E. Iglesias" <edgar.iglesias@gmail.com>
To: "Philippe Mathieu-Daudé" <philmd@linaro.org>
Cc: Richard Henderson <richard.henderson@linaro.org>,
	qemu-devel@nongnu.org,
	"Edgar E. Iglesias" <edgar.iglesias@amd.com>,
	Luc Michel <luc.michel@amd.com>,
	Sai Pavan Boddu <sai.pavan.boddu@amd.com>,
	Michal Simek <michal.simek@amd.com>
Subject: Re: [PATCH 0/9] target/microblaze: Always use TARGET_LONG_BITS == 32
Date: Wed, 30 Apr 2025 12:38:45 +0200	[thread overview]
Message-ID: <aBH9tQyUQH6ucVBE@zapote> (raw)
In-Reply-To: <d57e4f5c-a677-4cba-bbe6-85b997a3b57a@linaro.org>

On Wed, Apr 30, 2025 at 08:26:23AM +0200, Philippe Mathieu-Daudé wrote:
> Hi,
> 
> On 13/2/25 13:37, Philippe Mathieu-Daudé wrote:
> > +AMD folks
> > 
> > On 12/2/25 23:01, Richard Henderson wrote:
> > > Use out-of-line helpers to implement extended address memory ops.
> > > With this, we can reduce TARGET_LONG_BITS to the more natural 32
> > > for this 32-bit cpu.
> > 
> > I thought about something similar 2 months ago, but then realized
> > MicroBlaze cores can be synthetized in 64-bit, and IIRC there is
> > not much missing (I'd say effort would be to add 20% more of what
> > we currently have). Just wanted to mention before taking the
> > decision to restrict to 32-bit. OTOH if there are no plan for
> > adding 64-bit support at AMD, then I'm more than happy to simplify
> > by considering only 32-bit.
> 
> I gave this series another go, and figured the microblaze target
> addition was done way before the 64-bit. C_DATA_SIZE value was fixed
> as 32, and C_ADDR_SIZE was not mentioned. Later C_DATA_SIZE became
> configurable as [32, 64] and C_ADDR_SIZE appeared.
> 
> Indeed what this series does is correctly implement the current
> target as C_DATA_SIZE=32 (C_ADDR_SIZE=32 implied).
> 
> I had a quick look at what is missing for C_DATA_SIZE > 32 and it
> is more than the 20% I first roughly estimated. So with the current
> implementation, this series is doing the right thing IMHO.
>


Hi,

Seems I lost track of this series. I agree that Richard's series looks good.

At the time I may have had some idea of prepping for full 64bit support,
I don't remember. If we ever add full 64bit support we can have have
another look and see how it makes sense to change things.

Cheers,
Edgar


  parent reply	other threads:[~2025-04-30 10:39 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-12 22:01 [PATCH 0/9] target/microblaze: Always use TARGET_LONG_BITS == 32 Richard Henderson
2025-02-12 22:01 ` [PATCH 1/9] target/microblaze: Split out mb_unaligned_access_internal Richard Henderson
2025-02-12 22:01 ` [PATCH 2/9] target/microblaze: Split out mb_transaction_failed_internal Richard Henderson
2025-02-13 12:59   ` Philippe Mathieu-Daudé
2025-02-12 22:01 ` [PATCH 3/9] target/microblaze: Implement extended address load/store out of line Richard Henderson
2025-02-12 22:01 ` [PATCH 4/9] target/microblaze: Use uint64_t for CPUMBState.ear Richard Henderson
2025-02-13 12:42   ` Philippe Mathieu-Daudé
2025-02-13 16:11     ` Richard Henderson
2025-04-30  8:46   ` Philippe Mathieu-Daudé
2025-02-12 22:01 ` [PATCH 5/9] target/microblaze: Use TCGv_i64 for compute_ldst_addr_ea Richard Henderson
2025-02-13 12:49   ` Philippe Mathieu-Daudé
2025-02-12 22:01 ` [PATCH 6/9] target/microblaze: Fix printf format in mmu_translate Richard Henderson
2025-02-12 22:01 ` [PATCH 7/9] target/microblaze: Use TARGET_LONG_BITS == 32 for system mode Richard Henderson
2025-02-12 22:01 ` [PATCH 8/9] target/microblaze: Drop DisasContext.r0 Richard Henderson
2025-02-13 12:51   ` Philippe Mathieu-Daudé
2025-02-12 22:01 ` [PATCH 9/9] target/microblaze: Simplify compute_ldst_addr_type{a,b} Richard Henderson
2025-02-13 12:56   ` Philippe Mathieu-Daudé
2025-02-13 12:37 ` [PATCH 0/9] target/microblaze: Always use TARGET_LONG_BITS == 32 Philippe Mathieu-Daudé
2025-03-05  0:21   ` Philippe Mathieu-Daudé
2025-04-30  6:26   ` Philippe Mathieu-Daudé
2025-04-30  7:29     ` Philippe Mathieu-Daudé
2025-04-30 10:54       ` Edgar E. Iglesias
2025-04-30 10:38     ` Edgar E. Iglesias [this message]
2025-04-30 11:09 ` Edgar E. Iglesias
2025-04-30 12:45   ` Philippe Mathieu-Daudé

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aBH9tQyUQH6ucVBE@zapote \
    --to=edgar.iglesias@gmail.com \
    --cc=edgar.iglesias@amd.com \
    --cc=luc.michel@amd.com \
    --cc=michal.simek@amd.com \
    --cc=philmd@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=sai.pavan.boddu@amd.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.