Re: [PATCH] Document jit_align.

[Paulo César Pereira de Andrade]

Em ter., 16 de ago. de 2022 às 15:25, Marc Nieper-Wißkirchen
<marc@nieper-wisskirchen.de> escreveu:
>
> Am Di., 16. Aug. 2022 um 20:14 Uhr schrieb Paulo César Pereira de
> Andrade <paulo.cesar.pereira.de.andrade@gmail.com>:
> >
> > Em dom., 14 de ago. de 2022 às 13:09, Marc Nieper-Wißkirchen
> > <marc@nieper-wisskirchen.de> escreveu:
> > >
> > > I just noticed that the argument to jit_align is asserted to be at most 
> > > as large as the size of a word in jit_x86.c (line 1596).  To make 
> > > jit_align suitable for what the documentation was written for, the limit 
> > > should be increased to, say, jit_get_max_instr().  For that, the nop 
> > > generator in jit_x86-cpu.c has to be modified to allow longer sequences 
> > > of nop (e.g. by iterating).
> >
> >   The idea for jit_align was indeed just to make it just align jump targets
> > or function prologs.
> >   Usually jumps to aligned addresses are faster.
> >
> >   The assertions should be changed.
>
> I am going to put this on my TODO list as this involves improving the
> nop-generators in the jit_xxx-cpu.c files. For that, I need the
> 128-bit opcode for a NOP on ia64.

  First need to call sync(), which is commented a bit before the jit_code_align
switch. The sync() function will flush any pending code generation. I do not
recall checking this, but maybe should always do it in a jit_code_align().
  It already calls sync() for jit_code_label, so, should not be required.

  About a 128 bit NOP, it should be, after a sync(), the sequence:
NOP_M(0), NOP_I(0), NOP_I(0)
some other variants should work, but the above should be the simplest.
Obviously, need to fool proof check it.

> Marc