[Qemu-devel] Add ARM920T to ARM emulation

[Qemu-devel] Add ARM920T to ARM emulation

[Vincent Sanders]

This adds the ARM920T to the ARM supported processor cores. It also
alters the default emulated instruction set to the version 4t set and
adds a feature flag for the v5 features.

I have used the ARM Architecture Reference Manual (version I) as the
source of the v4/v5 differences. Page 14 of the ARM-ARM ("New features
in version 5T") gives an overview of the v5 features.

The primary differences are related to the "Control and DSP
instruction extension space" range of which v4t implements only a
subset. These are described on page 144 (A3.16.3) of the ARM-ARM

Other extensions (such as preloading) were added in the old NV opcode
range and are ignored by the current emulation already.

There was some discussion of the differences between v4 and v5 with
respect to LDR behaviour manipulating the program counter when the
bottom bit of an adress is set. The ARM-ARM clearly defines such
behaviour as "unpredicatble" (section A2.4.3 page 48) where it says
"In all variants of ARMv4 and ARMv5, bits[1:0] of a value written to
R15 in ARM state must be 0b00. If they are not, the results are
UNPREDICTABLE." .

As such the emulation remains correct whatever the specific result of
such program counter manipulation. I could alter the emulation
behaviour to follow the expected physical behaviour of some version
4/5 implementations. This would complicate the code for very little
aparient gain and I have been unable to find any code which uses this
construct despite scanning the entire arm and armel repositories of
Debian.

[Qemu-devel] [PATCH 1/1] Update ARM emulation to be version 4t by default

[Vincent Sanders]

Update ARM emulation to be version 4t by default and add v5 as a
 feature. Implementation is very similar to the way the v6 features are
 presented.

Signed-off-by: Vincent Sanders <vince@simtec.co.uk>
---
 target-arm/cpu.h       |    2 ++
 target-arm/helper.c    |   16 ++++++++++++++++
 target-arm/translate.c |   16 ++++++++++------
 3 files changed, 28 insertions(+), 6 deletions(-)

diff --git a/target-arm/cpu.h b/target-arm/cpu.h
index f98655f..61df46e 100644
--- a/target-arm/cpu.h
+++ b/target-arm/cpu.h
@@ -331,6 +331,7 @@ enum arm_features {
     ARM_FEATURE_AUXCR,  /* ARM1026 Auxiliary control register.  */
     ARM_FEATURE_XSCALE, /* Intel XScale extensions.  */
     ARM_FEATURE_IWMMXT, /* Intel iwMMXt extension.  */
+    ARM_FEATURE_V5,
     ARM_FEATURE_V6,
     ARM_FEATURE_V6K,
     ARM_FEATURE_V7,
@@ -370,6 +371,7 @@ void cpu_arm_set_cp_io(CPUARMState *env, int cpnum,
 #define ARM_CPUID_ARM1026     0x4106a262
 #define ARM_CPUID_ARM926      0x41069265
 #define ARM_CPUID_ARM946      0x41059461
+#define ARM_CPUID_ARM920T     0x41129200
 #define ARM_CPUID_TI915T      0x54029152
 #define ARM_CPUID_TI925T      0x54029252
 #define ARM_CPUID_PXA250      0x69052100
diff --git a/target-arm/helper.c b/target-arm/helper.c
index 701629a..214cbf1 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -37,18 +37,25 @@ static void cpu_reset_model_id(CPUARMState *env, uint32_t id)
 {
     env->cp15.c0_cpuid = id;
     switch (id) {
+    case ARM_CPUID_ARM920T:
+        env->cp15.c0_cachetype = 0x0d172172;
+        env->cp15.c1_sys = 0x00000078;
+        break;
     case ARM_CPUID_ARM926:
+        set_feature(env, ARM_FEATURE_V5);
         set_feature(env, ARM_FEATURE_VFP);
         env->vfp.xregs[ARM_VFP_FPSID] = 0x41011090;
         env->cp15.c0_cachetype = 0x1dd20d2;
         env->cp15.c1_sys = 0x00090078;
         break;
     case ARM_CPUID_ARM946:
+        set_feature(env, ARM_FEATURE_V5);
         set_feature(env, ARM_FEATURE_MPU);
         env->cp15.c0_cachetype = 0x0f004006;
         env->cp15.c1_sys = 0x00000078;
         break;
     case ARM_CPUID_ARM1026:
+        set_feature(env, ARM_FEATURE_V5);
         set_feature(env, ARM_FEATURE_VFP);
         set_feature(env, ARM_FEATURE_AUXCR);
         env->vfp.xregs[ARM_VFP_FPSID] = 0x410110a0;
@@ -57,6 +64,7 @@ static void cpu_reset_model_id(CPUARMState *env, uint32_t id)
         break;
     case ARM_CPUID_ARM1136_R2:
     case ARM_CPUID_ARM1136:
+        set_feature(env, ARM_FEATURE_V5);
         set_feature(env, ARM_FEATURE_V6);
         set_feature(env, ARM_FEATURE_VFP);
         set_feature(env, ARM_FEATURE_AUXCR);
@@ -68,6 +76,7 @@ static void cpu_reset_model_id(CPUARMState *env, uint32_t id)
         env->cp15.c0_cachetype = 0x1dd20d2;
         break;
     case ARM_CPUID_ARM11MPCORE:
+        set_feature(env, ARM_FEATURE_V5);
         set_feature(env, ARM_FEATURE_V6);
         set_feature(env, ARM_FEATURE_V6K);
         set_feature(env, ARM_FEATURE_VFP);
@@ -80,6 +89,7 @@ static void cpu_reset_model_id(CPUARMState *env, uint32_t id)
         env->cp15.c0_cachetype = 0x1dd20d2;
         break;
     case ARM_CPUID_CORTEXA8:
+        set_feature(env, ARM_FEATURE_V5);
         set_feature(env, ARM_FEATURE_V6);
         set_feature(env, ARM_FEATURE_V6K);
         set_feature(env, ARM_FEATURE_V7);
@@ -101,6 +111,7 @@ static void cpu_reset_model_id(CPUARMState *env, uint32_t id)
         env->cp15.c0_ccsid[2] = 0xf0000000; /* No L2 icache. */
         break;
     case ARM_CPUID_CORTEXM3:
+        set_feature(env, ARM_FEATURE_V5);
         set_feature(env, ARM_FEATURE_V6);
         set_feature(env, ARM_FEATURE_THUMB2);
         set_feature(env, ARM_FEATURE_V7);
@@ -108,6 +119,7 @@ static void cpu_reset_model_id(CPUARMState *env, uint32_t id)
         set_feature(env, ARM_FEATURE_DIV);
         break;
     case ARM_CPUID_ANY: /* For userspace emulation.  */
+        set_feature(env, ARM_FEATURE_V5);
         set_feature(env, ARM_FEATURE_V6);
         set_feature(env, ARM_FEATURE_V6K);
         set_feature(env, ARM_FEATURE_V7);
@@ -120,6 +132,7 @@ static void cpu_reset_model_id(CPUARMState *env, uint32_t id)
         break;
     case ARM_CPUID_TI915T:
     case ARM_CPUID_TI925T:
+        set_feature(env, ARM_FEATURE_V5);
         set_feature(env, ARM_FEATURE_OMAPCP);
         env->cp15.c0_cpuid = ARM_CPUID_TI925T; /* Depends on wiring.  */
         env->cp15.c0_cachetype = 0x5109149;
@@ -132,6 +145,7 @@ static void cpu_reset_model_id(CPUARMState *env, uint32_t id)
     case ARM_CPUID_PXA260:
     case ARM_CPUID_PXA261:
     case ARM_CPUID_PXA262:
+        set_feature(env, ARM_FEATURE_V5);
         set_feature(env, ARM_FEATURE_XSCALE);
         /* JTAG_ID is ((id << 28) | 0x09265013) */
         env->cp15.c0_cachetype = 0xd172172;
@@ -143,6 +157,7 @@ static void cpu_reset_model_id(CPUARMState *env, uint32_t id)
     case ARM_CPUID_PXA270_B1:
     case ARM_CPUID_PXA270_C0:
     case ARM_CPUID_PXA270_C5:
+        set_feature(env, ARM_FEATURE_V5);
         set_feature(env, ARM_FEATURE_XSCALE);
         /* JTAG_ID is ((id << 28) | 0x09265013) */
         set_feature(env, ARM_FEATURE_IWMMXT);
@@ -277,6 +292,7 @@ struct arm_cpu_t {
 };
 
 static const struct arm_cpu_t arm_cpu_names[] = {
+    { ARM_CPUID_ARM920T, "arm920t"},
     { ARM_CPUID_ARM926, "arm926"},
     { ARM_CPUID_ARM946, "arm946"},
     { ARM_CPUID_ARM1026, "arm1026"},
diff --git a/target-arm/translate.c b/target-arm/translate.c
index adac19a..a294f3a 100644
--- a/target-arm/translate.c
+++ b/target-arm/translate.c
@@ -35,6 +35,7 @@
 #define GEN_HELPER 1
 #include "helpers.h"
 
+#define ENABLE_ARCH_5     arm_feature(env, ARM_FEATURE_V5)
 #define ENABLE_ARCH_5J    0
 #define ENABLE_ARCH_6     arm_feature(env, ARM_FEATURE_V6)
 #define ENABLE_ARCH_6K   arm_feature(env, ARM_FEATURE_V6K)
@@ -5995,7 +5996,7 @@ static void disas_arm_insn(CPUState * env, DisasContext *s)
                 tmp = load_reg(s, rm);
                 gen_bx(s, tmp);
             } else if (op1 == 3) {
-                /* clz */
+                ARCH(5); /* clz */
                 rd = (insn >> 12) & 0xf;
                 tmp = load_reg(s, rm);
                 gen_helper_clz(tmp, tmp);
@@ -6018,14 +6019,15 @@ static void disas_arm_insn(CPUState * env, DisasContext *s)
             if (op1 != 1)
               goto illegal_op;
 
-            /* branch link/exchange thumb (blx) */
+            ARCH(5); /* branch link/exchange thumb (blx) */
             tmp = load_reg(s, rm);
             tmp2 = new_tmp();
             tcg_gen_movi_i32(tmp2, s->pc);
             store_reg(s, 14, tmp2);
             gen_bx(s, tmp);
             break;
-        case 0x5: /* saturating add/subtract */
+        case 0x5:
+            ARCH(5); /* saturating add/subtract */
             rd = (insn >> 12) & 0xf;
             rn = (insn >> 16) & 0xf;
             tmp = load_reg(s, rm);
@@ -6039,16 +6041,18 @@ static void disas_arm_insn(CPUState * env, DisasContext *s)
             dead_tmp(tmp2);
             store_reg(s, rd, tmp);
             break;
-        case 7: /* bkpt */
+        case 7:
+            ARCH(5); /* bkpt */
             gen_set_condexec(s);
             gen_set_pc_im(s->pc - 4);
             gen_exception(EXCP_BKPT);
             s->is_jmp = DISAS_JUMP;
             break;
-        case 0x8: /* signed multiply */
+        case 0x8:
         case 0xa:
         case 0xc:
         case 0xe:
+            ARCH(5); /* signed multiply */
             rs = (insn >> 8) & 0xf;
             rn = (insn >> 12) & 0xf;
             rd = (insn >> 16) & 0xf;
@@ -7099,7 +7103,7 @@ static int disas_thumb2_insn(CPUState *env, DisasContext *s, uint16_t insn_hw1)
         if (insn & (1 << 22)) {
             /* Other load/store, table branch.  */
             if (insn & 0x01200000) {
-                /* Load/store doubleword.  */
+                ARCH(5); /* Load/store doubleword.  */
                 if (rn == 15) {
                     addr = new_tmp();
                     tcg_gen_movi_i32(addr, s->pc & ~3);
-- 
1.6.0.4

Re: [Qemu-devel] [PATCH 1/1] Update ARM emulation to be version 4t by default

[Paul Brook]

On Friday 29 May 2009, Vincent Sanders wrote:
> Update ARM emulation to be version 4t by default and add v5 as a
>  feature. Implementation is very similar to the way the v6 features are
>  presented.

You really need to distinguish between v5t and v5te.

You've also missed the different load behavior, which is probably the most 
important difference.

Paul

Re: [Qemu-devel] [PATCH 1/1] Update ARM emulation to be version 4t by default

[Vincent Sanders]

On Fri, May 29, 2009 at 10:59:49PM +0100, Paul Brook wrote:
> On Friday 29 May 2009, Vincent Sanders wrote:
> > Update ARM emulation to be version 4t by default and add v5 as a
> >  feature. Implementation is very similar to the way the v6 features are
> >  presented.
> 
> You really need to distinguish between v5t and v5te.
> 

This was intended to be a minimum change alteration. The current
implementation does not make this distinction and I dont feel it is my
place to alter core semantics in this way. 

I am unaware of the specifics of these differences as the ARM ARM is
unrevealing on the subject. It tends to imply there is ARMv4t and
ARMv5te. If you feel the need to add this distinction please feel free
and I will rebase my patches upon that work.

> You've also missed the different load behavior, which is probably the most 
> important difference.
> 

Please can you provide a reference to what you mean by this? I thought
I had provided all the relevant sections. If I have missed something
please can you spell it out (preferably by reference to the ARM ARM)
as I do not have the ARM ARM commited to memory and lack your insigt
on this issue.

Please can you confirm that there is nothing erroneous about this
patch or approach, just that it is missing some corner cases with
respect to loading into the program counter.

I would also repeat my previous query asking if I am wasting my time?
You appear to go silent on this whenever I ask you directly. No doubt
I will bump into you again during the forthcoming months and can ask
you face to face but I would prefer if your comments were on record.

-- 
Regards Vincent
http://www.kyllikki.org/

Re: [Qemu-devel] Add ARM920T to ARM emulation

[Paul Brook]

> There was some discussion of the differences between v4 and v5 with
> respect to LDR behaviour manipulating the program counter when the
> bottom bit of an adress is set. The ARM-ARM clearly defines such
> behaviour as "unpredicatble" (section A2.4.3 page 48) where it says
> "In all variants of ARMv4 and ARMv5, bits[1:0] of a value written to
> R15 in ARM state must be 0b00. If they are not, the results are
> UNPREDICTABLE." .

This statement is only applies to instructions that do not have explicit 
semantics for r15. Use of r15 as a destination in load/pop instructions is 
well defined.

Paul

Re: [Qemu-devel] Add ARM920T to ARM emulation

[Jamie Lokier]

Paul Brook wrote:
> > There was some discussion of the differences between v4 and v5 with
> > respect to LDR behaviour manipulating the program counter when the
> > bottom bit of an adress is set. The ARM-ARM clearly defines such
> > behaviour as "unpredicatble" (section A2.4.3 page 48) where it says
> > "In all variants of ARMv4 and ARMv5, bits[1:0] of a value written to
> > R15 in ARM state must be 0b00. If they are not, the results are
> > UNPREDICTABLE." .
> 
> This statement is only applies to instructions that do not have explicit 
> semantics for r15. Use of r15 as a destination in load/pop instructions is 
> well defined.

I notice that ARMv4T adds the BX instruction, implying that B isn't
able to switch to Thumb mode although it can in later architectures (I
never saw the point in BX, and I guess ARM ended up the same :-)

Is the behaviour defined to _not_ switch to Thumb when using B to an
address with the low order bit set, or does it trap, or is it unpredictable?

(While we're here, I would quite like to see the distinction between
ARMv4 and ARMv4T for testing of userspace interworking code, but I'll
add that myself if I need it - as far as I know, the difference would
just be BX/BLX being an illegal instruction, and low-order bit in R15
being ignored.)

-- Jamie

Re: [Qemu-devel] Add ARM920T to ARM emulation

[Paul Brook]

> I notice that ARMv4T adds the BX instruction, implying that B isn't
> able to switch to Thumb mode although it can in later architectures (I
> never saw the point in BX, and I guess ARM ended up the same :-)
>
> Is the behaviour defined to _not_ switch to Thumb when using B to an
> address with the low order bit set, or does it trap, or is it
> unpredictable?

You need to look again at the B instruction. Hopefully then you'll realise why 
you're talking nonsense.

B is a direct branch that never changes mode. BX is an indirect branch that 
mode switches based on the low address bit.
BL and BLX(register) are exactly the same as B/BX except they also set LR.
BLX(immediate) is a direct mode switching call.
loads into the PC either ignore(v4t) or mode switch (v5) on the low address 
bit.
ALU writes to the PC always ignore the low bit in Thumb mode. In ARM mode the 
low bit is either ignored(v6) or used to mode switch (v7).

BX was introduced in v4t, BLX was introduced in v5.

Paul

Re: [Qemu-devel] Add ARM920T to ARM emulation

[Avi Kivity]

Paul Brook wrote:
> B is a direct branch that never changes mode. BX is an indirect branch that 
> mode switches based on the low address bit.
> BL and BLX(register) are exactly the same as B/BX except they also set LR.
> BLX(immediate) is a direct mode switching call.
> loads into the PC either ignore(v4t) or mode switch (v5) on the low address 
> bit.
> ALU writes to the PC always ignore the low bit in Thumb mode. In ARM mode the 
> low bit is either ignored(v6) or used to mode switch (v7).
>
> BX was introduced in v4t, BLX was introduced in v5.
>   

Does no sane instruction set exist?

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] Add ARM920T to ARM emulation

[Tristan Gingold]

On Jun 1, 2009, at 3:29 PM, Avi Kivity wrote:

> Paul Brook wrote:
>> B is a direct branch that never changes mode. BX is an indirect  
>> branch that mode switches based on the low address bit.
>> BL and BLX(register) are exactly the same as B/BX except they also  
>> set LR.
>> BLX(immediate) is a direct mode switching call.
>> loads into the PC either ignore(v4t) or mode switch (v5) on the low  
>> address bit.
>> ALU writes to the PC always ignore the low bit in Thumb mode. In  
>> ARM mode the low bit is either ignored(v6) or used to mode switch  
>> (v7).
>>
>> BX was introduced in v4t, BLX was introduced in v5.
>>
>
> Does no sane instruction set exist?

What is wrong with Alpha (or to a lesser extent PowerPc) ? & ;-)

Re: [Qemu-devel] Add ARM920T to ARM emulation

[Avi Kivity]

Tristan Gingold wrote:
>> Does no sane instruction set exist?
>
> What is wrong with Alpha 

It's dead.

> (or to a lesser extent PowerPc) ? & ;-)

I'm not familiar with ppc, but as an IBM creation, it's bound to be 
incredibly complicated.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] Add ARM920T to ARM emulation

[Paul Brook]

On Monday 01 June 2009, Avi Kivity wrote:
> Paul Brook wrote:
> > B is a direct branch that never changes mode. BX is an indirect branch
> > that mode switches based on the low address bit.
> > BL and BLX(register) are exactly the same as B/BX except they also set
> > LR. BLX(immediate) is a direct mode switching call.
> > loads into the PC either ignore(v4t) or mode switch (v5) on the low
> > address bit.
> > ALU writes to the PC always ignore the low bit in Thumb mode. In ARM mode
> > the low bit is either ignored(v6) or used to mode switch (v7).
> >
> > BX was introduced in v4t, BLX was introduced in v5.
>
> Does no sane instruction set exist?

Thumb mode definitely has several "entertaining" aspects, but ARM mode is 
generally fairly sane.

Paul

Re: [Qemu-devel] Add ARM920T to ARM emulation

[Jamie Lokier]

Paul Brook wrote:
> > I notice that ARMv4T adds the BX instruction, implying that B isn't
> > able to switch to Thumb mode although it can in later architectures (I
> > never saw the point in BX, and I guess ARM ended up the same :-)
> >
> > Is the behaviour defined to _not_ switch to Thumb when using B to an
> > address with the low order bit set, or does it trap, or is it
> > unpredictable?
> 
> You need to look again at the B instruction. Hopefully then you'll realise why 
> you're talking nonsense.

Ach, sorry.

My head's been buried in FDPIC, where BX is only used on ARMvT; on
everything else, LDR/LDM does the job.  So I inconveniently forgot
what you cluebricked me about.

> loads into the PC either ignore(v4t) or mode switch (v5) on the low
> address bit.  ALU writes to the PC always ignore the low bit in
> Thumb mode. In ARM mode the low bit is either ignored(v6) or used to
> mode switch (v7).

Thanks, it's what I've found too. from reading the 2005 ARM ARM just now.

I'll add that ARM-mode ALU writes to the PC on (v4/v4t/v5) (and loads
on v4/v4t), "bits[1:0] must be 0b00, if they are not, the results are
UNPREDICTABLE".  Whereas for (v6), the bits are ignored, and as you
say for (v7) the least-significant bit is meaningful.

-- Jamie