Previous Up Next

14  Frames


The implementation of the access is architecture-dependent, the interface here is architecture-independent. Creating a new frame, one specifies for each formal parameter whether it escapes or not.

Note that, unlike for most other modules, we do not rely here on the connection of module types and modules with mli- and ml-files. The reason is that there will be more than one implementation for the FRAME module type, namely one for each machine architecture.

[Structure] Is the solution for separating the the architecture dependent and independent parts for the frames? Perhaps here, the functors could be useful and not an overkill, after all? See also the remark at page 155 of [App98b].

Currently, it’s not possible to provide a module Frame as manchine-dependent implemetation of FRAME within the[i]-module, since the specific implementation already needs to refer to the FRAME-module type, which introduces a cyclic dependency. Currently, I directly incorporate the architecture dependant module, for instance, Pentium.Frame, as module Translate.Frame, as proposed on page 155.

[Structure] Is it intended, that the type access is implemented newly for each architecture and not shared?

[Exp] What is the function exp good for? Why is the function exp (cf. page 156) not shown on page 260?

See page 156. The client of the function is the Translate-module.

The full Frame-interface is shown on page 260 of [App98b].

To do:
What is the type of new_frame? The information differs from page 134 to page 260. Why is the type access which is shown on page 134 not shown on page 260?

What’s the type of alloc_local? The information differs from page 260 vs. page 137.

The implementation of the type access for the mips-architecture is shown on 135.

[View shift] What is meant by the view shift? It is said that the frame object must contain code to implement the view shift, this is currently not the case, I guess, unless the Frame.exp-function is meant, but this function is not per instance. Is the view-shift per instance? Why is it architecture dependent.

Some explanation is on pages 135 and 169. The shift-of-view is the implementation of the calling conventions for parameter passing.

Part of the space of an activation record are the formal parameters, which are accessed from the caller as well as from the callee, but both access them in a different way, at least if they are passed on the stack and not in registers. The callee, for whom the parameters are incoming, accesses them via the frame pointer, the caller via the stack pointer, both with positive offsets.

The default view in a frame is how they are accessed from within the function, i.e., as incoming arguments relative to the frame pointer. Those are directly represented as Frame.accesses.

There are of course two inverse versions of the view-shift, one at procedure entry and one for returning (cf. also pages 168 and 261). The proc_entry_exit1 seems to implement the view shift. the view shift comes early and invoked by the

For variables passed in registers

[Formal parameters] Why do the formal parameters for the Pentium-architecture at 8 and not at 4 (cf. page 137)?

[Fragment] What are fragments?

Previous Up Next