Closed Bug 607225 Opened 14 years ago Closed 14 years ago

nanojit: add MODRM() and SIB() to Nativei386.cpp, plus other clean-ups

Categories

(Core Graveyard :: Nanojit, defect)

x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: n.nethercote, Assigned: n.nethercote)

Details

(Whiteboard: fixed-in-nanojit, fixed-in-tamarin)

Attachments

(1 file)

This patch cleans up the i386 back-end some more.

- Introduces MODRM() and SIB() functions.  The old MODRM() function was
  renamed MODRMr() to match MODRMm() et al.  Several assertions could be
  removed because MODRM() and SIB() do the relevant assertions now.

- Documents the possible lengths of various instruction fragments.

- Documents the addressing mode encoded by each MODRM() call.  (Diligent
  checking of these would be welcome :)

- Inlines PUSHi32() to its one call-site, removing an excess call to
  count_push() in the process.

- Fixes printing of the SIBIDX(scale) param in several places -- uses %c
  instead of %d.

- Better distinguished functions that write whole instructions vs. functions
  that write instruction fragments.

BTW, I'm planning to add OPCODE()/OPCODE2()/OPCODE3() functions, but I
didn't want to put too much in a single patch.
Attachment #485978 - Flags: review?(rreitmai)
sorry for delay nick ... reviewing later this eve.
Comment on attachment 485978 [details] [diff] [review]
patch (against TM 56282:d217b7dccfc6)

R+ nice cleanup with a couple of nits that are optional:

(1) I'm rather attached to "Table 2-2. 32-Bit Addressing Forms with the ModR/M Byte" of the intel doc.  This table displays the order of the ModRM bits as 'Mod R/M Reg'.   Although this order differs from bit order it makes decoding and comparison much easier.  

(2) In MODRMr() should we replace the code with a direct call out to MODRM() ?
Attachment #485978 - Flags: review?(rreitmai) → review+
(In reply to comment #2)
> 
> (1) I'm rather attached to "Table 2-2. 32-Bit Addressing Forms with the ModR/M
> Byte" of the intel doc.  This table displays the order of the ModRM bits as
> 'Mod R/M Reg'.   Although this order differs from bit order it makes decoding
> and comparison much easier.  

I'd prefer to keep the existing order if that's ok!  :)
http://hg.mozilla.org/tracemonkey/rev/afcdb9b4bb04
http://hg.mozilla.org/mozilla-central/rev/afcdb9b4bb04
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: