[Top][All Lists]

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

Re: [Qemu-devel] [PATCH] target-tilegx: Execute _start and reach to __li

From: Richard Henderson
Subject: Re: [Qemu-devel] [PATCH] target-tilegx: Execute _start and reach to __libc_start_main successfully
Date: Wed, 25 Feb 2015 07:19:47 -1000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0

On 02/24/2015 05:40 PM, Chen Gang S wrote:
>>> +static int gen_shl16insli(struct DisasContext *dc,
>>> +                          unsigned char rdst, unsigned char rsrc, short 
>>> im16)
>> Use uint16_t, as the field is not signed.
> objdump print it as signed, e.g. "shl16insli r32, r32, -30680"

I think you've just found a bug in objdump.  ;-)

>> Use the extract64 and sextract64 functions instead of bare shifts and masks.
> OK, thanks What you said above sounds reasonable to me. But if we use
> "arch/opcode_tilegx.h" next, we can use their own related inline
> functions instead of.

Yes, using the opcode_tilegx.h functions is a good idea.  I didn't know about
those before.  I've looked through that file now and using them will make
reviewing this code much easier.

>>> +    /* For can regress completely, it must be y0 -> y1 -> y2, or x0 -> x1. 
>>> */
>> I don't know what this sentence means.
> I guess, it needs more contents:
>   y2 and x1 may contents st instruction (x1 may also contents 'jal'),
>   which should be executed at last, or when exception raised, we can
>   not be sure each bundle must be atomic (none pipes should execute).

How about something like:

        Only pipelines X1 and Y2 can issue branches, memory ops, or
        issue trapping instructions like system calls.  As these
        operations cannot be buffered, it is convenient to translate
        those pipelines last.

After all, we're already buffering the output of all of the pipes.  If the
memory op succeeds, then all of the rest of the arithmetic will succeed, so it
doesn't really matter that much what ordering we give the pipes.  No state will
change until we reach the end of the bundle and write back the results.

>> You don't need these gotos.  If a given pipeline raises an invalid 
>> instruction
>> exception, then it's true that all code emitted afterward is dead.  But 
>> that's
>> ok, since it simply won't be executed.  Invalid instructions are exceedingly
>> unlikely and it's silly to optimize for that case.
> OK, thanks. I guess your meaning is: we need not check the return value
> for each pipe, just raise exception is enough. e.g.
>  - Add a flag in DisasContext.
>  - When exception happens, set the flag.
>  - In main looping gen_intermediate_code_internal(), if the flag is set,
>    we need break the tb block, and return.

Yes, that will be fine.


reply via email to

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