Re: [Lightning] About 32 and 64 bits registers

[Paulo Cesar Pereira de Andrade]

On 24-08-2010 03:59, Paolo Bonzini wrote:
> On 08/24/2010 01:44 AM, Paulo César Pereira de Andrade wrote:
> > How is it expected to handle proper sign/zero extension when there
> > are no named 8/16/32/64 bit registers, that is, there is no JIT_R0c,
> > JIT_R0s, JIT_R0i and/or JIT_R0l.
>
> That's on purpose, RISC machines do not have that.
>
> > This has a nasty side effect that some operations must be sign/zero
> > extended, for example, when loading data from a memory location. But
> > then, some operations become somewhat hard to explain, for example:
>
> Loads and stores always sign/zero-extend to _l/_ul size.

  Yes, that was also why I asked you to work on the correction of loads
of signed char, short and ints. Working this way, it makes a very
clearer interface. The problem now is that the movi_* operations also
need updates, and there is a major series of problems with _ASM_SAFETY
and 32/64 bits register in my new test cases (I got a bit confused
myself due to it :-))

> > jit_bltr_i LABEL, JIT_R0, IMMEDIATE
>
> You mean jit_blti_i.

  Yes, as explained in my other reply :-)

> > this should be understood as "treated JIT_R0 value as 32 bits, but
> > signed extend it, as well as immediate" ?
>
> Yes. Instead, blti_ui would zero extend it.
>
> > But to do an "optimized" operation, it must ensure that JIT_R0 is
> > actually holding a 64 bits value.
>
> Using _l operations for branches will usually give the fastest code.
>
> > jit_movi_i JIT_R0 IMMEDIATE
> >
> > this should be just an alias to jit_movi_l on 64 bits, or, better
> > saying, should be more like:
> >
> > jit_movi_i JIT_R0 (cast_to_int_32)IMMEDIATE
>
> Yes, it should be the latter.

  Ok, I will rework a bit on my proposed patch. For safety, I
think it should be more like:

jit_movi_i(JIT_R0, (long)(int)IMMEDIATE)

> Paolo

Paulo