IonMonkey: Introduce MacroAssembler abstraction

RESOLVED FIXED

Status

()

RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: dvander, Assigned: dvander)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

Created attachment 548118 [details] [diff] [review]
part 1: add the files

This patch introduces a new abstraction, MacroAssembler. The raw Assembler types are designed to be thin wrappers around the Nitro backend assemblers, providing some type safety and IonMonkey-desirable API. Their intention is that each function emits exactly one, predictable machine instruction.

The MacroAssembler provides a platform-generic API on top of the backend assembler. MacroAssembler functions may emit more than one instruction per function, as needed. Aside from each platform implementing a conforming MacroAssembler, there is a final MacroAssembler that will provide common functionality based on the features that must be exposed on each platform.

The difference between working with these two APIs is not entirely clear yet - in this patch, the classes are all empty and I'm filling them in incrementally in my queue. We may not know for sure until we are writing entirely platform generic code.

Here is one idea in how the API might differ. On purely x86 code:
  masm.movl(Operand(esp, 4), eax);
  masm.addl(Imm32(20), eax);

Whereas using the MacroAssembler portion of the API might look like:
  masm.load32(Address(StackPointer, 4), reg);
  masm.add32(Imm32(20), reg);

The separate concept of "Operand" is probably the right idea if we want to be rigorous about our low-level assembler's intentions. For example, Sparc's Operand does not natively have a (Base, Index, Scale, Offset) form. ARM only has a (Base, Index, Scale) form. We could put these in anyway, keep a global scratch register, and make it work - but in our design, the Assembler is the wrong level for that.
Attachment #548118 - Flags: review?(ascheff)
Created attachment 548119 [details] [diff] [review]
part 2: move framePushed_

This patch does two things:
 * Moves framePushed_ out of CodeGenerator and into MacroAssembler$CPU
 * To make stack balancing easier, visitReturn() now jumps to a common
   epilogue.

This is a prerequisite to a new API in MacroAssembler for calling C functions, where knowing the state of the stack is really useful.
Attachment #548119 - Flags: review?(ascheff)

Comment 2

7 years ago
Comment on attachment 548118 [details] [diff] [review]
part 1: add the files

Review of attachment 548118 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good.  r=me after you come into our conference room and put a class hierarchy diagram on the whiteboard :)
Attachment #548118 - Flags: review?(ascheff) → review+

Comment 3

7 years ago
Comment on attachment 548119 [details] [diff] [review]
part 2: move framePushed_

Review of attachment 548119 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good.
Attachment #548119 - Flags: review?(ascheff) → review+
You need to log in before you can comment on or make changes to this bug.