>> +
>> +assert(ctx->insn.limm_p == 0 && !in_delay_slot);
>> +
>> +if (ctx->insn.limm_p == 0 && !in_delay_slot) {
>> +in_delay_slot = true;
>> +uint32_t cpc = ctx->cpc;
>> +uint32_t pcl = ctx->pcl;
>> +insn_t insn = ctx->insn;
>> +
>> +ctx->cpc =
Seems perfectly doable, no objections.
It will probably take me longer to integrate it in the build system
then to get the scripts ready.
I will start by placing the ruby tool and documentation there, and
later on, integrate it in the build system.
Hope that you get re-motivated to review our
On 12/3/20 10:54 AM, Cupertino Miranda wrote:
> Our generation tool has different levels of verbosity, expressing
> instruction semantics from a pattern level up to what it is shown in
> as comments, which is later converted to TCG format.
> For QEMU purposes I would say that input format should
Hi Richard,
Thanks for your quick reply, and again, thanks for the reviews.
We have already started to make very significant changes to the port
based on your comments. ;-)
Our generation tool has different levels of verbosity, expressing
instruction semantics from a pattern level up to what it
On 12/2/20 6:55 AM, Cupertino Miranda wrote:
> I totally understand your concerns with generated code.
>
> To explain our decision, we have an internal database that we are able
> to describe the architecture and map encoding with hw semantics, and
> for the sake of saving us debug time
Hi Richard,
Thank you so much for your reviews.
I will start working on improving the code straight away to try to
minimize waiting times.
However lets just address the elephant in the room.
Indeed we have the TCG definitions being generated.
However we are very serious about wanting to upstream
On 11/11/20 10:17 AM, cupertinomira...@gmail.com wrote:
> +case 0x09:
> +/* (N & V & !Z) | (!N & !V & !Z) */
This is xnor(N, V) & !Z, and since as you now know xnor = eqv, you can perform
this in just two steps.
tcg_gen_eqv_tl(ret, cpu_Nf, cpu_Vf);
tcg_gen_andc_tl(ret, ret,
