Fixes to run "Hello, world!" on arm64 hardware.

Fixes to run "Hello, world!" on arm64 hardware.

Primarily, in Dart code, instead of using R31 as our
stack pointer, on entry we copy it into a second
register (R18) and use that as our stack pointer after
moving R31 to the Dart stack limit. On calling back
into C++ from Dart code, R31 is restored, and R18 is
cached in the callee-saved register R26.

R=regis@google.com

Committed: https://code.google.com/p/dart/source/detail?r=36930

[regis, 2014-06-03 17:38:22]

LGTM, but see my question about the system possibly trashing the stack.

https://codereview.chromium.org/311903004/diff/1/runtime/vm/simulator_arm64.cc
File runtime/vm/simulator_arm64.cc (right):

https://codereview.chromium.org/311903004/diff/1/runtime/vm/simulator_arm64.c...
runtime/vm/simulator_arm64.cc:679: if ((instr != NULL) && (reg == R31) &&
((value & 0x7) != 0)) {
Why are you testing for 8-byte aligned?
It would be clearer to use Utils::IsAligned(value, 16)

https://codereview.chromium.org/311903004/diff/1/runtime/vm/stub_code_arm64.cc
File runtime/vm/stub_code_arm64.cc (right):

https://codereview.chromium.org/311903004/diff/1/runtime/vm/stub_code_arm64.c...
runtime/vm/stub_code_arm64.cc:780: __ mov(SP, CSP);
From this point on, CSP will not be updated anymore until we return from Dart
code into C code. Dart code will effectively use the stack space below the stack
pointer known to the system. Are we sure this is safe? What about interrupts
that could use the stack? The system usually keeps a red zone below the stack
pointer that it will not touch, but Dart code will definitely use the stack
below the red zone.

[zra, 2014-06-03 18:09:49]

https://codereview.chromium.org/311903004/diff/1/runtime/vm/simulator_arm64.cc
File runtime/vm/simulator_arm64.cc (right):

https://codereview.chromium.org/311903004/diff/1/runtime/vm/simulator_arm64.c...
runtime/vm/simulator_arm64.cc:679: if ((instr != NULL) && (reg == R31) &&
((value & 0x7) != 0)) {
On 2014/06/03 17:38:22, regis wrote:
> Why are you testing for 8-byte aligned?
> It would be clearer to use Utils::IsAligned(value, 16)

Whoops. Done.

https://codereview.chromium.org/311903004/diff/1/runtime/vm/stub_code_arm64.cc
File runtime/vm/stub_code_arm64.cc (right):

https://codereview.chromium.org/311903004/diff/1/runtime/vm/stub_code_arm64.c...
runtime/vm/stub_code_arm64.cc:780: __ mov(SP, CSP);
On 2014/06/03 17:38:22, regis wrote:
> From this point on, CSP will not be updated anymore until we return from Dart
> code into C code. Dart code will effectively use the stack space below the
stack
> pointer known to the system. Are we sure this is safe? What about interrupts
> that could use the stack? The system usually keeps a red zone below the stack
> pointer that it will not touch, but Dart code will definitely use the stack
> below the red zone.

See comment below.

https://codereview.chromium.org/311903004/diff/1/runtime/vm/stub_code_arm64.c...
runtime/vm/stub_code_arm64.cc:823: __ LoadFromOffset(CSP, R5,
Isolate::stack_limit_offset(), PP);
CSP is updated here to be the isolate's stack limit. Except for the frame setup
code above, the Dart stack pointer SP will never go below the system stack
pointer. I could move this up before we use the stack to save the callee-saved
registers, but since this arrangement hasn't caused problems, I thought it would
be best to perturb the frame setup code as little as possible.

[zra, 2014-06-03 18:38:36]

Committed patchset #3 manually as r36930 (presubmit successful).

[regis, 2014-06-03 18:52:15]

https://codereview.chromium.org/311903004/diff/1/runtime/vm/stub_code_arm64.cc
File runtime/vm/stub_code_arm64.cc (right):

https://codereview.chromium.org/311903004/diff/1/runtime/vm/stub_code_arm64.c...
runtime/vm/stub_code_arm64.cc:823: __ LoadFromOffset(CSP, R5,
Isolate::stack_limit_offset(), PP);
On 2014/06/03 18:09:49, zra wrote:
> CSP is updated here to be the isolate's stack limit. Except for the frame
setup
> code above, the Dart stack pointer SP will never go below the system stack
> pointer. I could move this up before we use the stack to save the callee-saved
> registers, but since this arrangement hasn't caused problems, I thought it
would
> be best to perturb the frame setup code as little as possible.

I had missed this write to CSP. This is good. I would still protect the stack up
to this point by subtracting the frame size from CSP before the EnterFrame
above. An estimated size is good enough, i.e. a constant multiple of 16 and
larger than the size of all registers you are pushing.

To be safe, you should do the same in all tests copying CSP to SP. Maybe you
could have a new EnterFrame flavor (EnterSafeFrame?) that takes a size to
reserve. You could use it here too.