[Top][All Lists]

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

Re: [Lightning] i386 sse support

From: Paulo César Pereira de Andrade
Subject: Re: [Lightning] i386 sse support
Date: Thu, 16 Sep 2010 14:47:29 -0300

Em 16 de setembro de 2010 09:05, Paolo Bonzini <address@hidden> escreveu:
> On 09/16/2010 10:41 AM, Paulo César Pereira de Andrade wrote:
>>   What do you think would be the proper way to detect the cpu
>> features, and add support for runtime reconfiguration?
>> Maybe there should be some kind of call, like
>> jit_get_cpu_features(), that one should call before generating
>> code, so that the macros jit_sse_p(), jit_i686_p(), etc,
>> could actually be runtime flags. Also, it may be desirable
>> to allow changing these flags, mainly for testing purposes.
> Looks like a good idea.  I still haven't reviewed the branch though.

  Ok. I will verify the available possibilities. Probably I can assume CPUID
is available (i.e. lightning is not running on pre i486).

  BTW, I was about to change
because I thought it was caused by the bad jumps in the x87 and/or sse
code, but actually it still happens if used a sse instruction to add/sub/etc
vectors (using gcc __attribute__((vector_size(16)))) and generated jit
code that uses x87. Maybe it is gcc that is at fault, by not calling EMMS?
Or, it is right to assume that when compiled with -msse it should not care...
(or it is intel that is at fault for messing with x87 when using some sse
instructions :-)

  Also, it should be talked at some moment :-) I hope this code to
be included in the upstream lightning, so that others can benefit
from the changes, but I already put a lot of work, and plan to still
do a lot of extra work on it, so, it should be fair to add my name
to the sources, and update FSF copyright to 2010. I usually use
the format:
at the bottom of the header comment, is it ok?
Also, about the indentation style, I am too cool that I use my
own text editor [1] :-) (and probably I am one of the few xedit users
in the world), but not everybody likes the default indentation
style of 4 spaces, and using tabs to "compress" spaces and
tabs fixed at 8 spaces width.

  One of the next steps I plan to do, is to rework the asm*.h
code, to have more complete self documentation, and probably
add the opcode hexadecimal numbers in comment, for easier
matching what is generated when reading cpu manuals. This is
also where work should be done for source compatibility, i.e.
access to the global _jit identifier.

> Paolo



reply via email to

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