FR2 affects how arguments are passed to functions. Without the flag, a
reference to the function is placed in stack[i] followed by parameters in
stack[i+1], stack[i+2], etc. With FR2, there’s a gap preceding the first
argument, arguments are layed out sequentially starting with stack[i+2].
LJ doesn’t copy function arguments. The called function stack frame partially
overlaps with the parent. LJ has to put the frame link somewhere, more bits are
necessary in 64 bit mode, hence the gap.
On 31 Dec 2020, at 00:04, Spar <developspartv@xxxxxxxxx> wrote:
Opcodes are changed but for different reason.
Your bytecode must have FR2 flag if you want to load it on 64-bit builds. FR2
stands for FRame size 2 (As I understand). This flag as I know is set on
64-bit builds only, but maybe you can set it flag freely. It's used on 64-bit
to optimize space for TValues, probably because of minimal alignment.
However, I'm not sure if this affects bytecode storage in GCk or others.
On 30 Dec 2020, 23:50 +0300, Petri Häkkinen <petrih3@xxxxxxxxx>, wrote:
On 30 Dec 2020, at 21.17, Spar <developspartv@xxxxxxxxx> wrote:
The version byte is also changed. 64-bit versions requires FR2 flag and
*probably* different TValue format.
Thanks! I'm diffing lj_bcread.c between v1 and v2 bytecode formats and I'm
not seeing any relevant changes.
But there's this:
if ((flags & BCDUMP_F_FR2) != LJ_FR2*BCDUMP_F_FR2) return 0;
So it's erroring if the FR2 flag is not what's expecting it to be. Any ideas
why? The dump file seems to have the exact same format regardless of the FR2
flag... So I'm guessing FR2 requires something special in the emitted
bytecode?
Petri
