Closed
Bug 673864
Opened 14 years ago
Closed 14 years ago
IonMonkey: Introduce MacroAssembler abstraction
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: dvander, Assigned: dvander)
References
Details
Attachments
(2 files)
28.66 KB,
patch
|
ascheff
:
review+
|
Details | Diff | Splinter Review |
18.00 KB,
patch
|
ascheff
:
review+
|
Details | Diff | Splinter Review |
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)
![]() |
Assignee | |
Comment 1•14 years ago
|
||
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•14 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•14 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+
![]() |
Assignee | |
Comment 4•14 years ago
|
||
http://hg.mozilla.org/projects/ionmonkey/rev/ab9123c68044
http://hg.mozilla.org/projects/ionmonkey/rev/7b704fb3b421
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•