qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 2/4] target/m68k: increase size of m68k CPU features from uin


From: Laurent Vivier
Subject: Re: [PATCH 2/4] target/m68k: increase size of m68k CPU features from uint32_t to uint64_t
Date: Wed, 21 Sep 2022 15:14:19 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.1

Le 20/09/2022 à 18:30, Mark Cave-Ayland a écrit :
On 17/09/2022 23:27, Philippe Mathieu-Daudé via wrote:

On 17/9/22 14:09, BALATON Zoltan wrote:
On Sat, 17 Sep 2022, Mark Cave-Ayland wrote:
There are already 32 feature bits in use, so change the size of the m68k
CPU features to uint64_t (allong with the associated m68k_feature()
functions) to allow up to 64 feature bits to be used.

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
---
target/m68k/cpu.c | 4 ++--
target/m68k/cpu.h | 6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/target/m68k/cpu.c b/target/m68k/cpu.c
index f681be3a2a..7b4797e2f1 100644
--- a/target/m68k/cpu.c
+++ b/target/m68k/cpu.c
@@ -38,12 +38,12 @@ static bool m68k_cpu_has_work(CPUState *cs)

static void m68k_set_feature(CPUM68KState *env, int feature)
{
-    env->features |= (1u << feature);
+    env->features |= (1ul << feature);

         env->features = deposit64(env->features, feature, 1, 1);

}

static void m68k_unset_feature(CPUM68KState *env, int feature)
{
-    env->features &= (-1u - (1u << feature));
+    env->features &= (-1ul - (1ul << feature));

         env->features = deposit64(env->features, feature, 1, 0);

Should these be ull instead of ul?

Yes. Not needed if using the <qemu/bitops.h> extract/deposit API.

I must admit I find the deposit64() variants not particularly easy to read: if we're considering alterations rather than changing the constant suffix then I'd much rather go for:

     env->features |= (1ULL << feature);

and:

     env->features &= ~(1ULL << feature);

Laurent, what would be your preference?

I have no preference, do as you prefer.


}

static void m68k_cpu_reset(DeviceState *dev)
diff --git a/target/m68k/cpu.h b/target/m68k/cpu.h
index 67b6c12c28..d3384e5d98 100644
--- a/target/m68k/cpu.h
+++ b/target/m68k/cpu.h
@@ -154,7 +154,7 @@ typedef struct CPUArchState {
    struct {} end_reset_fields;

    /* Fields from here on are preserved across CPU reset. */
-    uint32_t features;
+    uint64_t features;
} CPUM68KState;

/*
@@ -539,9 +539,9 @@ enum m68k_features {
    M68K_FEATURE_TRAPCC,
};

-static inline int m68k_feature(CPUM68KState *env, int feature)
+static inline uint64_t m68k_feature(CPUM68KState *env, int feature)

Why uint64_t? Can we simplify using a boolean?

I don't really feel strongly either way here. Again I'm happy to go with whatever Laurent would prefer as maintainer.

A boolean seems more logic, I think.

Thanks,
Laurent



reply via email to

[Prev in Thread] Current Thread [Next in Thread]