From: Alex Bennée <alex.bennee@linaro.org>
> I have no particular comment to make about the PPC stuff but with the common
> translator loop we have hooks across all converted front ends to identify the
> start of each instruction. It's needed for the TCG plugin instrumentation and we
> could in theory use it for more integrated stats across the board.
> 
> Out of interest what was the main aim of this code - a view of total executed
> instructions or something more detailed like a breakdown of types and ops?

The legacy instruction decoding logic in the PPC implementation uses a table that maps opcode patterns (based on different parts of the instructions) to handlers that actually implement each instruction. 
The code that is being removed would list how many times each specific handler was invoked, so it had more information than just the total count of executed instructions.

That being said, the code probably wasn't being used for a while now, as it didn't even compile.

--
Luis Pires
Instituto de Pesquisas ELDORADO <http://www.eldorado.org.br>
Departamento de Computação Embarcada
Aviso Legal - Disclaimer <https://www.eldorado.org.br/disclaimer.html>

Luis Fernando Fujita Pires <luis.pires@eldorado.org.br> writes:

> From: Alex Bennée <alex.bennee@linaro.org>
>> I have no particular comment to make about the PPC stuff but with the common
>> translator loop we have hooks across all converted front ends to identify the
>> start of each instruction. It's needed for the TCG plugin instrumentation and we
>> could in theory use it for more integrated stats across the board.
>> 
>> Out of interest what was the main aim of this code - a view of total executed
>> instructions or something more detailed like a breakdown of types and ops?
>
> The legacy instruction decoding logic in the PPC implementation uses a
> table that maps opcode patterns (based on different parts of the
> instructions) to handlers that actually implement each instruction.
> The code that is being removed would list how many times each specific handler was invoked, so it had more information than just the total count of executed instructions.
>
> That being said, the code probably wasn't being used for a while now,
> as it didn't even compile.

Ahh OK. If you wanted to you could probably re-create that information
using the howvec plugin (see contrib/plugins/howvec) if the decode
tables where added for PPC.

-- 
Alex Bennée

From: Alex Bennée <alex.bennee@linaro.org>
> Ahh OK. If you wanted to you could probably re-create that information using
> the howvec plugin (see contrib/plugins/howvec) if the decode tables where
> added for PPC.

Interesting. I hadn't looked at the plugin mechanism before. In this hypothetical case, if we wanted to get the execution count for each instruction, we could also automatically generate the instruction decoding code based on decodetree. Then it would work for any architecture that uses decodetree.

I just realized that the ppc code wasn't counting instruction executions, but translations. A slightly modified version of howvec would also take care of that by counting the instructions directly in vcpu_tb_trans(), without even registering execution callbacks. Again, all hypothetical - but neat. :)

--
Luis Pires
Instituto de Pesquisas ELDORADO <http://www.eldorado.org.br>
Aviso Legal - Disclaimer <https://www.eldorado.org.br/disclaimer.html>