Re: [Qemu-devel] [PATCH 05/10] qemu-tech: document lazy condition code evaluation in cpu.h

2016-10-07 Thread Paolo Bonzini 


On 06/10/2016 20:45, Peter Maydell wrote:
> On 6 October 2016 at 16:24, Paolo Bonzini  wrote:
>> Unlike the other sections, they are pretty specific to a particular CPU.
>>
>> Signed-off-by: Paolo Bonzini 
>> ---
>>  qemu-tech.texi | 25 -
>>  target-cris/cpu.h  |  7 +++
>>  target-i386/cpu.h  |  7 +++
>>  target-m68k/cpu.h  |  8 
>>  target-sparc/cpu.h |  5 +
>>  5 files changed, 27 insertions(+), 25 deletions(-)
> 
> target-s390x/ also seems to have the CC optimization...

Indeed:

diff --git a/target-s390x/cpu.h b/target-s390x/cpu.h
index 4fb34b5..4e58cde 100644
--- a/target-s390x/cpu.h
+++ b/target-s390x/cpu.h
@@ -671,6 +671,13 @@ ObjectClass *s390_cpu_class_by_name(const char *name);
 
 /* CC optimization */
 
+/* Instead of computing the condition codes after each x86 instruction,
+ * QEMU just stores the result (called CC_DST), the type of operation
+ * (called CC_OP) and whatever operands are needed (CC_SRC and possibly
+ * CC_VR). When the condition codes are needed, the condition codes can
+ * be calculated using this information. Condition codes are not generated
+ * if they are only needed for conditional branches.
+ */
 enum cc_op {
 CC_OP_CONST0 = 0,   /* CC is 0 */
 CC_OP_CONST1,   /* CC is 1 */

Paolo

Re: [Qemu-devel] [PATCH 05/10] qemu-tech: document lazy condition code evaluation in cpu.h

2016-10-06 Thread Peter Maydell 
On 6 October 2016 at 16:24, Paolo Bonzini  wrote:
> Unlike the other sections, they are pretty specific to a particular CPU.
>
> Signed-off-by: Paolo Bonzini 
> ---
>  qemu-tech.texi | 25 -
>  target-cris/cpu.h  |  7 +++
>  target-i386/cpu.h  |  7 +++
>  target-m68k/cpu.h  |  8 
>  target-sparc/cpu.h |  5 +
>  5 files changed, 27 insertions(+), 25 deletions(-)

target-s390x/ also seems to have the CC optimization...

thanks
-- PMM

Re: [Qemu-devel] [PATCH 05/10] qemu-tech: document lazy condition code evaluation in cpu.h

2016-10-06 Thread Paolo Bonzini 


On 06/10/2016 18:18, Emilio G. Cota wrote:
> On Thu, Oct 06, 2016 at 17:24:18 +0200, Paolo Bonzini wrote:
>> Unlike the other sections, they are pretty specific to a particular CPU.
>>
>> Signed-off-by: Paolo Bonzini 
>> ---
>>  qemu-tech.texi | 25 -
>>  target-cris/cpu.h  |  7 +++
>>  target-i386/cpu.h  |  7 +++
>>  target-m68k/cpu.h  |  8 
>>  target-sparc/cpu.h |  5 +
>>  5 files changed, 27 insertions(+), 25 deletions(-)
> (snip)
>> diff --git a/target-cris/cpu.h b/target-cris/cpu.h
>> index 7d7fe6e..6d3de56 100644
>> --- a/target-cris/cpu.h
>> +++ b/target-cris/cpu.h
>> @@ -223,6 +223,13 @@ int cpu_cris_signal_handler(int host_signum, void 
>> *pinfo,
>>  void cris_initialize_tcg(void);
>>  void cris_initialize_crisv10_tcg(void);
>>  
>> +/* Instead of computing the condition codes after each x86 instruction,
>> + * QEMU just stores one operand (called CC_SRC), the result
>> + * (called CC_DST) and the type of operation (called CC_OP). When the
>> + * condition codes are needed, the condition codes can be calculated
>> + * using this information. Condition codes are not generated if they
>> + * are only needed for conditional branches.
>> + */
> 
> This text doesn't seem to be cris-specific, e.g.:
> - "each x86 instruction"
> - CC_SRC (git grep CC_SRC here doesn't return anything)
> - CC_DST (ditto)

Yeah, it's cc_src and cc_dest.  The uppercase is a relic of dyngen
(pre-TCG).  Same for m68k.

Paolo

> 
>>  enum {
>>  CC_OP_DYNAMIC, /* Use env->cc_op  */
>>  CC_OP_FLAGS,
>> diff --git a/target-i386/cpu.h b/target-i386/cpu.h
>> index 6d028aa..f606f15 100644
>> --- a/target-i386/cpu.h
>> +++ b/target-i386/cpu.h
>> @@ -698,6 +698,13 @@ typedef uint32_t FeatureWordArray[FEATURE_WORDS];
>>  /* Use a clearer name for this.  */
>>  #define CPU_INTERRUPT_INIT  CPU_INTERRUPT_RESET
>>  
>> +/* Instead of computing the condition codes after each x86 instruction,
>> + * QEMU just stores one operand (called CC_SRC), the result
>> + * (called CC_DST) and the type of operation (called CC_OP). When the
>> + * condition codes are needed, the condition codes can be calculated
>> + * using this information. Condition codes are not generated if they
>> + * are only needed for conditional branches.
>> + */
>>  typedef enum {
>>  CC_OP_DYNAMIC, /* must use dynamic code to get cc_op */
>>  CC_OP_EFLAGS,  /* all cc are explicitly computed, CC_SRC = flags */
>> diff --git a/target-m68k/cpu.h b/target-m68k/cpu.h
>> index c2d40cb..ccc7157 100644
>> --- a/target-m68k/cpu.h
>> +++ b/target-m68k/cpu.h
>> @@ -154,6 +154,14 @@ int cpu_m68k_signal_handler(int host_signum, void 
>> *pinfo,
>> void *puc);
>>  void cpu_m68k_flush_flags(CPUM68KState *, int);
>>  
>> +
>> +/* Instead of computing the condition codes after each x86 instruction,
>> + * QEMU just stores one operand (called CC_SRC), the result
>> + * (called CC_DST) and the type of operation (called CC_OP). When the
>> + * condition codes are needed, the condition codes can be calculated
>> + * using this information. Condition codes are not generated if they
>> + * are only needed for conditional branches.
>> + */
> 
> Same as above:
> - "each x86 instruction"
> - no CC_DST
> 
>   Emilio
>

Re: [Qemu-devel] [PATCH 05/10] qemu-tech: document lazy condition code evaluation in cpu.h

2016-10-06 Thread Emilio G. Cota 
On Thu, Oct 06, 2016 at 17:24:18 +0200, Paolo Bonzini wrote:
> Unlike the other sections, they are pretty specific to a particular CPU.
> 
> Signed-off-by: Paolo Bonzini 
> ---
>  qemu-tech.texi | 25 -
>  target-cris/cpu.h  |  7 +++
>  target-i386/cpu.h  |  7 +++
>  target-m68k/cpu.h  |  8 
>  target-sparc/cpu.h |  5 +
>  5 files changed, 27 insertions(+), 25 deletions(-)
(snip)
> diff --git a/target-cris/cpu.h b/target-cris/cpu.h
> index 7d7fe6e..6d3de56 100644
> --- a/target-cris/cpu.h
> +++ b/target-cris/cpu.h
> @@ -223,6 +223,13 @@ int cpu_cris_signal_handler(int host_signum, void *pinfo,
>  void cris_initialize_tcg(void);
>  void cris_initialize_crisv10_tcg(void);
>  
> +/* Instead of computing the condition codes after each x86 instruction,
> + * QEMU just stores one operand (called CC_SRC), the result
> + * (called CC_DST) and the type of operation (called CC_OP). When the
> + * condition codes are needed, the condition codes can be calculated
> + * using this information. Condition codes are not generated if they
> + * are only needed for conditional branches.
> + */

This text doesn't seem to be cris-specific, e.g.:
- "each x86 instruction"
- CC_SRC (git grep CC_SRC here doesn't return anything)
- CC_DST (ditto)

>  enum {
>  CC_OP_DYNAMIC, /* Use env->cc_op  */
>  CC_OP_FLAGS,
> diff --git a/target-i386/cpu.h b/target-i386/cpu.h
> index 6d028aa..f606f15 100644
> --- a/target-i386/cpu.h
> +++ b/target-i386/cpu.h
> @@ -698,6 +698,13 @@ typedef uint32_t FeatureWordArray[FEATURE_WORDS];
>  /* Use a clearer name for this.  */
>  #define CPU_INTERRUPT_INIT  CPU_INTERRUPT_RESET
>  
> +/* Instead of computing the condition codes after each x86 instruction,
> + * QEMU just stores one operand (called CC_SRC), the result
> + * (called CC_DST) and the type of operation (called CC_OP). When the
> + * condition codes are needed, the condition codes can be calculated
> + * using this information. Condition codes are not generated if they
> + * are only needed for conditional branches.
> + */
>  typedef enum {
>  CC_OP_DYNAMIC, /* must use dynamic code to get cc_op */
>  CC_OP_EFLAGS,  /* all cc are explicitly computed, CC_SRC = flags */
> diff --git a/target-m68k/cpu.h b/target-m68k/cpu.h
> index c2d40cb..ccc7157 100644
> --- a/target-m68k/cpu.h
> +++ b/target-m68k/cpu.h
> @@ -154,6 +154,14 @@ int cpu_m68k_signal_handler(int host_signum, void *pinfo,
> void *puc);
>  void cpu_m68k_flush_flags(CPUM68KState *, int);
>  
> +
> +/* Instead of computing the condition codes after each x86 instruction,
> + * QEMU just stores one operand (called CC_SRC), the result
> + * (called CC_DST) and the type of operation (called CC_OP). When the
> + * condition codes are needed, the condition codes can be calculated
> + * using this information. Condition codes are not generated if they
> + * are only needed for conditional branches.
> + */

Same as above:
- "each x86 instruction"
- no CC_DST

Emilio

[Qemu-devel] [PATCH 05/10] qemu-tech: document lazy condition code evaluation in cpu.h

2016-10-06 Thread Paolo Bonzini 
Unlike the other sections, they are pretty specific to a particular CPU.

Signed-off-by: Paolo Bonzini 
---
 qemu-tech.texi | 25 -
 target-cris/cpu.h  |  7 +++
 target-i386/cpu.h  |  7 +++
 target-m68k/cpu.h  |  8 
 target-sparc/cpu.h |  5 +
 5 files changed, 27 insertions(+), 25 deletions(-)

diff --git a/qemu-tech.texi b/qemu-tech.texi
index 082b62c..75ceea4 100644
--- a/qemu-tech.texi
+++ b/qemu-tech.texi
@@ -214,7 +214,6 @@ SH4
 @menu
 * QEMU compared to other emulators::
 * Portable dynamic translation::
-* Condition code optimisations::
 * CPU state optimisations::
 * Translation cache::
 * Direct block chaining::
@@ -290,30 +289,6 @@ performances.
 QEMU's dynamic translation backend is called TCG, for "Tiny Code
 Generator". For more information, please take a look at @code{tcg/README}.
 
-@node Condition code optimisations
-@section Condition code optimisations
-
-Lazy evaluation of CPU condition codes (@code{EFLAGS} register on x86)
-is important for CPUs where every instruction sets the condition
-codes. It tends to be less important on conventional RISC systems
-where condition codes are only updated when explicitly requested. On
-Sparc64, costly update of both 32 and 64 bit condition codes can be
-avoided with lazy evaluation.
-
-Instead of computing the condition codes after each x86 instruction,
-QEMU just stores one operand (called @code{CC_SRC}), the result
-(called @code{CC_DST}) and the type of operation (called
-@code{CC_OP}). When the condition codes are needed, the condition
-codes can be calculated using this information. In addition, an
-optimized calculation can be performed for some instruction types like
-conditional branches.
-
-@code{CC_OP} is almost never explicitly set in the generated code
-because it is known at translation time.
-
-The lazy condition code evaluation is used on x86, m68k, cris and
-Sparc. ARM uses a simplified variant for the N and Z flags.
-
 @node CPU state optimisations
 @section CPU state optimisations
 
diff --git a/target-cris/cpu.h b/target-cris/cpu.h
index 7d7fe6e..6d3de56 100644
--- a/target-cris/cpu.h
+++ b/target-cris/cpu.h
@@ -223,6 +223,13 @@ int cpu_cris_signal_handler(int host_signum, void *pinfo,
 void cris_initialize_tcg(void);
 void cris_initialize_crisv10_tcg(void);
 
+/* Instead of computing the condition codes after each x86 instruction,
+ * QEMU just stores one operand (called CC_SRC), the result
+ * (called CC_DST) and the type of operation (called CC_OP). When the
+ * condition codes are needed, the condition codes can be calculated
+ * using this information. Condition codes are not generated if they
+ * are only needed for conditional branches.
+ */
 enum {
 CC_OP_DYNAMIC, /* Use env->cc_op  */
 CC_OP_FLAGS,
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index 6d028aa..f606f15 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -698,6 +698,13 @@ typedef uint32_t FeatureWordArray[FEATURE_WORDS];
 /* Use a clearer name for this.  */
 #define CPU_INTERRUPT_INIT  CPU_INTERRUPT_RESET
 
+/* Instead of computing the condition codes after each x86 instruction,
+ * QEMU just stores one operand (called CC_SRC), the result
+ * (called CC_DST) and the type of operation (called CC_OP). When the
+ * condition codes are needed, the condition codes can be calculated
+ * using this information. Condition codes are not generated if they
+ * are only needed for conditional branches.
+ */
 typedef enum {
 CC_OP_DYNAMIC, /* must use dynamic code to get cc_op */
 CC_OP_EFLAGS,  /* all cc are explicitly computed, CC_SRC = flags */
diff --git a/target-m68k/cpu.h b/target-m68k/cpu.h
index c2d40cb..ccc7157 100644
--- a/target-m68k/cpu.h
+++ b/target-m68k/cpu.h
@@ -154,6 +154,14 @@ int cpu_m68k_signal_handler(int host_signum, void *pinfo,
void *puc);
 void cpu_m68k_flush_flags(CPUM68KState *, int);
 
+
+/* Instead of computing the condition codes after each x86 instruction,
+ * QEMU just stores one operand (called CC_SRC), the result
+ * (called CC_DST) and the type of operation (called CC_OP). When the
+ * condition codes are needed, the condition codes can be calculated
+ * using this information. Condition codes are not generated if they
+ * are only needed for conditional branches.
+ */
 enum {
 CC_OP_DYNAMIC, /* Use env->cc_op  */
 CC_OP_FLAGS, /* CC_DEST = CVZN, CC_SRC = unused */
diff --git a/target-sparc/cpu.h b/target-sparc/cpu.h
index a3d64a4..646a103 100644
--- a/target-sparc/cpu.h
+++ b/target-sparc/cpu.h
@@ -102,6 +102,11 @@
 #define CC_DST (env->cc_dst)
 #define CC_OP  (env->cc_op)
 
+/* Even though lazy evaluation of CPU condition codes tends to be less
+ * important on RISC systems where condition codes are only updated
+ * when explicitly requested, SPARC uses it to update 32-bit and 64-bit
+ * condition codes.
+ */
 enum {
 CC_OP_DYNAMIC, /* must use dynamic code to get cc_op */
 CC_OP_FLAGS,   /*