Opened 10 years ago

Closed 10 years ago

#860 closed task (fixed)

32-bit x86 assembler uses sib byte encoding for 32-bit displacements

Reported by: rme Owned by: rme
Priority: minor Milestone:
Component: Compiler Version: trunk
Keywords: x86 Cc:


r11754 is workaround for a bug in how the lisp assembler encodes memory operands that are just a displacement.

To elaborate on that commit message, there are two ways on 32-bit x86 to encode a memory operand that's just a displacement.

For example, take the instruction:

0x806e6db:	mov    %fs:0x84,%ecx

The lisp assembler encodes this as:

0x806e6db:	0x64	0x8b	0x0c	0x25	0x84	0x00	0x00	0x00

Note that the modrm byte of 0x0c (00 001 100) means that a sib byte follows.

This could also be encoded as this shorter sequence (and the Unix assembler does so):

0x806e6db:	0x64	0x8b	0x0d	0x84	0x00	0x00	0x00

The modrm byte of 0x0d (00 001 101) here means that the displacement follows.

The reason that the lisp assembler selects the longer encoding is because it targeted x86-64 first. On x86-64, the modrm byte in the shorter sequence is redefined to mean that the displacement is RIP-relative. Therefore, the longer sib byte encoding is used to specify just a displacement.

The lisp assembler needs to be persuaded to emit the shorter encoding for 32-bit x86. When it does, we can recompile and bump fasl versions, etc., and remove the workaround in pc_luser_xp().

Change History (4)

comment:1 Changed 10 years ago by rme

(In [14852]) When assembling for a 32-bit x86 target, use the modrm encoding (and not a sib) to specify a memory address that is just a displacement.

See ticket:860.

comment:2 Changed 10 years ago by rme

  • Owner set to rme

comment:3 Changed 10 years ago by rme

(In [14868]) Shouldn't need LISP_ASSEMBLER_EXTRA_SIB_BYTE in pc_luser_xp() any more. See ticket:860.

comment:4 Changed 10 years ago by rme

  • Resolution set to fixed
  • Status changed from new to closed

(In [14871]) Remove the LISP_ASSEMBLER_EXTRA_SIB_BYTE code from pc_luser_xp() and friends. Finally closes ticket:860.

Also, the consing sequence used to branch around the alloc trap with a "jg" instruction. We haven't done that for a long time, so don't check for that any more, either.

Note: See TracTickets for help on using tickets.