Yes, let's talk about it tonight (tomorrow morning).
FrameElements were always conceived as an internal utility class for the
frame, not something that would be exposed (and definitely not
manipulated) from outside the frame. We have called the thing that can
be manipulated from outside the frame "Result"---but currently it has no
connection to the frame at all.
As for the naming ("Load..."), I agree with you. However, in the
context of the existing code generator, "Load" already implicitly means
"evaluate to the top of the stack" where the cc register is a possible
top of stack. It may seem that using it on something that is not an
Expression is an abuse of terminology, but we already use it that way,
ie, in LoadGlobal.
As for the load/store asymmetry, we have been discovering frame
operations as we go along with converting the code generator. The
result is that the frame abstraction is quite closely tailored to the
needs of the V8 code generator. We *could* make store symmetrical with
load and implement the current store as a more RISCy duplicate followed
by store, but then I'm concerned that we don't actually need all that
generality and may miss some chances to generate good code (effectively
require peephole optimization of virtual frame operations).
http://codereview.chromium.org/11023
--~--~---------~--~----~------------~-------~--~----~
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
-~----------~----~----~----~------~----~------~--~---
