Fast codegen: Implement with.

src/fast-codegen.h

Index: src/fast-codegen.h
diff --git a/src/fast-codegen.h b/src/fast-codegen.h
index 38588d159389acbc471525b8127f76d286385239..3d7a039900db0cb28e50505550ad760005ee6ddd 100644
--- a/src/fast-codegen.h
+++ b/src/fast-codegen.h
@@ -291,6 +291,15 @@ class FastCodeGenerator: public AstVisitor {
 
   MacroAssembler* masm() { return masm_; }
   static Register result_register();
+  static Register context_register();

[Kevin Millikin (Chromium), 2009/12/14 16:35:47]

This seems like going overboard to avoid platform-specific code in the backend.

But if you want do this, we have lots of explicit references to the register in
the toplevel code generator that should change to use the new abstraction.

[Lasse Reichstein, 2009/12/16 13:40:31]

The context_register() function is used in generic code (fast-codegen.cc), but
we could just as well have a SaveContextRegister function, because that's all
it's currently used for. I'll keep it for now and see if there will be more uses
for it.

The uses of this function in the backend specific files, e.g.
fast-codegen-x64.cc, is overdoing it. I'll remove those.

+
+  // Set fields in the stack frame. Offsets are the ones defined in, e.g.,
+  // StandardFrameConstants.
+  void StoreFrameField(int frame_offset, Register value);

[Kevin Millikin (Chromium), 2009/12/14 16:35:47]

Not all of the constants in frames-{arm,ia32,x64}.h are fp relative.  Probably
should mention that the offset here is fp relative.

We have a lot of uses of this pattern (and loading from a frame field, and
pushing one) in the fast code generator.  They should be rewritten.

For some reason, I like StoreTo... or Set... better as names.

[Lasse Reichstein, 2009/12/16 13:40:31]

Will mention exceptions and change name to StoreTo...

The Load/StoreTo functions are meant to be used from generic code
(fast-codegen.cc), but we can only do that when we have access to the register
being loaded/stored (currently only result_register() and context_register()). 

We can use the functions from the backend-specific code as well, but I don't
think it's really worth it. At that level, the proper abstraction would be an
Operand/MemOperand.

+
+  // Load a value from the current context. Indices are defined as an enum
+  // in v8::internal::Context.
+  void LoadContextField(Register dst, int context_index);

[Kevin Millikin (Chromium), 2009/12/14 16:35:47]

We have a lot of uses of this (or a similar) pattern too.  Search for
Context::SlotOffset and CodeGenerator::ContextOperand in the fast code
generator.

[Lasse Reichstein, 2009/12/16 13:40:31]

I actually think ContextOperand is the correct level of abstraction for the
backend specific code.

 
   // AST node visit functions.
 #define DECLARE_VISIT(type) virtual void Visit##type(type* node);