Per jandem,
Subject: Re: off bug from 857845
Hi,
Baseline and IonMonkey share the same MacroAssembler and frame infrastructure.
Baseline is an easier target mainly because it's a much simpler compiler. Many
Ion instructions, Ion bailouts/invalidation, etc all require platform-dependent
code. With Baseline we have *some* platform-dependent code (see
ion/arm/Baseline*) and some files are shared with Ion, but most of it is shared
(see BaselineCompiler.cpp, BaselineIC.cpp). Also unlike Ion and JM, Baseline
code will never bailout or be invalidated.
So I think I'd concentrate on Baseline first (run the shell with --no-jm
--no-ion). Ion will still be compiled since we don't have separate Ion/Baseline
#ifdef's, so you will probably want to use JS_NOT_REACHED(...) for anything
that's Ion-only so that you can implement it later.
What you need for Baseline is:
(*) MacroAssembler-*.{h, cpp}. The x86/x64 macro-assemblers are built on top of
the JSC assemblers. We don't reuse JSC's macro-assemblers, but we do reuse the
lower-level instruction-emitting code. The ARM assembler was written from
scratch I think.
(*) Trampolines:
- EnterJIT is used to enter both Ion and Baseline code. Initially you're only
interested in the case where type == EnterJitBaseline. For baseline code, the
trampoline also handles OSR from the interpreter: it reserves size for the
frame by updating the stack pointer, calls into the VM to initialize that frame
based on the interpreter StackFrame, then jumps into the JIT code. If I were
you I'd get the non-OSR case working first, because it's simpler. To do that
you can run with --baseline-eager and add the following to CanEnterBaselineJIT:
if (JSOp(*cx->regs().pc) == JSOP_LOOPENTRY)
return Method_Skipped;
- Invalidator: Ion-only, just add JS_NOT_REACHED or something.
- Arguments rectifier: Used by both Ion and Baseline. If we have a function
call where the callee has more formal arguments than the caller passes in, the
JITs call the arguments-rectifier instead. It just pushes some |undefined|
values and re-pushes the other arguments on top of it (arguments are pushed
last-to-first).
- Bailout thunk: Ion-only.
- Bailout handler: Ion-only.
- generateVMWrapper: generates some wrapper code Baseline and Ion use when
calling into C++.
- generatePreBarrier: used by both Baseline and Ion for incremental GC.
- generateDebugTrapHandler: used by Baseline only, in debug mode. It gets
called when a bytecode op has a breakpoint, or step mode is enabled. Not too
complicated, but initially I'd just add a check for
cx->compartment->debugMode() to CanEnterBaselineJIT and implement it after
everything else works.
(*) Bailouts-*.cpp, CodeGenerator-*.cpp, Lowering-*, MoveEmitter-*, LIR-*: all
Ion-only.
(*) Architecture-*.h, BaselineRegisters-*.h: you will need to implement these.
(*) IonFrames-*.h you will need, I think you can just copy IonFrames-arm.h We
should probably combine it with x86/x64 at some point since I don't think
there's much/any difference.
That's the high-level view. Let me know if you want me to go into anything in
particular. You can use IONFLAGS=help to see which spew channels are available
for baseline code. You probably want bl-scripts at least to show which scripts
are compiled.
Jan
The overwhelming good news is that most of this has already been written.
Original issue reported on code.google.com by
classi...@floodgap.comon 17 May 2013 at 4:38