[Top][All Lists]

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

[Lightning] About work on possible mips port

From: Paulo César Pereira de Andrade
Subject: [Lightning] About work on possible mips port
Date: Wed, 6 Oct 2010 01:31:09 -0300


  First sorry for the previous email :-) Some comments about the work.
  I have only a alpha/beta sample, and I am hoping to not fry it before
having an usable port (need to be patient because it has overheating
problems and powers off aleatorily, but if things go bad probably can
finish the port on an emulator).

  Well, I did not open the mips64 pdf manual yet, but from the mips32
documentation I managed to get a simple initial work going that can
already execute a small subset of lightning.

  At first I am thinking about using the approach I used, but reverted to
not make default, for function calls, that is to patch a stack pointer
adjustment on demand, i.e. as result of jit_allocai or function calls
that require arguments on stack. There is no push/pop opcodes
anyway, but would need to assert that no more than 32767 bytes
are allocated, to make patching possible.

  I am unsure if should add some kind of jit_flags for some code,
for example, jit_jmpi and jit_calli could either:
1. move pointer to register and to indirect jump/call
2. limit to 256Mb segment
3. both of above, with fatal error if patch does not fit
  Problem is that the jump or "jump and link" with immediate
has 26 bits (extended to 28 as address are multiple of 4).
  Probably option 3 would require a flag, but also need to find
out if there is some good performance benefit, space there is
for sure, and in 99% of the cases both jit pointer and jump
address would already be in the same 256Mb segment.

  Conditional branches must be limited to 18 bits distance, or, add
a jump over with an inverse condition and implement an unconditional

  Still also need to find out how to properly implement carry
primitives, as there is only add/sub without side effects, and
signed add/sub that generate a trap on overflow.

  Some other features make me consider suggesting adding
more lightning primitives, that should not be too hard to implement
as "composed" sequences if not available, e.g. multiply+add,
conditional move, branch with likely hint, etc.


reply via email to

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