mirror of
https://github.com/Mercury-Language/mercury.git
synced 2025-12-19 15:54:18 +00:00
2498d9d3fd
Estimated hours taken: 36 Instead of generating the layout structures of labels, procs and modules as rvals, generate them almost entirely as C structures. This will make future modifications much easier, since mismatches between what the runtime expects and what the compiler generates will now be pointed out by the C compiler. (It also reduces the size of the C source files generated with debugging enabled by about 5%.) Layout structures contain a few components that are not well-typed in C; we continue to generate these as rvals. Closure layout structures used to have a well-typed part and a non-well-typed part. We now generate the well-typed part as a separate structure, pointed to from the other. We also extend the well-typed part, so that instead of just giving the name the called procedure, it also identifies the source location where the closure was constructed. This could be useful for the debugger and for deep profiling. This diff also includes a change to get the compiler to bootstrap with lcc in grade none.gc.debug.tr: initializing the string tables in module layouts not as a string but as an array of characters. runtime/mercury_stack_layout.h: Reorganize the definitions of layout structures. Rename Stack_Layout_Entry structures as Proc_Layout structures, and Stack_Layout_Label structures as Label_Layout structures. (The debugger paper refers to the structures by the new names.) Fold the Stack_Layout_Vars structure into the structure that contains it, the Label_Layout structure. Add a Closure_Id structure that contains a Proc_Id structure as well as extra information identifying the source location where the closure was created. Create "short" versions of the Proc_Layout structures, which contain only the first one or two of the three groups of fields. Previously, the Mercury compiler would define new C types when it generated such short structures. Since we are not defining new C types anymore, there must be a C type for every kind of structure the Mercury compiler can generate. We now also have separate variants for the layouts of user-defined and compiler-generated procedures, since the format of their procedure id information is different. While the runtime system refers to their procedure id information through a union, the C types of the structures generated by the Mercury compiler do not use a union, since a union cannot be initialized through its second member. Make the constant fields of structures const, since we now generate values of those structure types, and initialize them with constant data. Move the documentation of layout structures here from stack_layout.m. runtime/mercury_ho_call.h: Instead of bodily including an MR_Proc_Id structure in closures, include a pointer to the more detailed MR_Closure_Id structure. runtime/mercury_accurate_gc.c: runtime/mercury_agc_debug.c: runtime/mercury_init.h: runtime/mercury_label.[ch]: runtime/mercury_layout_util.[ch]: Minor updates to conform to changes in mercury_stack_layout.h. runtime/mercury_goto.h: Use separate naming schemes for label layout structures and proc layout structures. library/exception.m: Minor updates to conform to changes in mercury_stack_layout.h. compiler/layout.m: A new module that defines data structures for label, proc and module layout structures and for closure id structures. compiler/layout_out.m: A new module that converts the Mercury data structures of layout.m into declarations and definitions of C data structures. compiler/stack_layout.m: Generate the new layout structures instead of rvals. Move the documentation of layout structures from here to runtime/mercury_stack_layout.h, since this module is no longer aware of some of their details. compiler/llds.m: Make layout structures a separate kind of compiler-generated data. compiler/llds_out.m: Remove the code for the output of layout structures; call layout_out.m instead. compiler/llds_out.m: compiler/rtti_out.m: Turn some predicates into functions. compiler/code_gen.m: compiler/code_info.m: compiler/llds.m: compiler/mercury_compile.m: compiler/unify_gen.m: Instead of handling closure layouts like other static data, handle them separately. Add a counter to the code_info structure in order to allow closure id structures to be identified uniquely by a pair consisting of the id of the procedure that generates them and a closure sequence number within that procedure. compiler/llds_common.m: Look for common rvals among the rvals in layout structures. compiler/opt_debug.m: Generate developer-friendly names for layout structure references. browser/dl.m: Update the code for constructing closure layouts.
145 lines
4.7 KiB
Mathematica
145 lines
4.7 KiB
Mathematica
%-----------------------------------------------------------------------------%
|
|
% Copyright (C) 2001 The University of Melbourne.
|
|
% This file may only be copied under the terms of the GNU General
|
|
% Public License - see the file COPYING in the Mercury distribution.
|
|
%-----------------------------------------------------------------------------%
|
|
%
|
|
% Definitions of Mercury types for representing layout structures within
|
|
% the compiler. Layout structures are generated by the compiler, and are
|
|
% used by the parts of the runtime system that need to look at the stacks
|
|
% (and sometimes the registers) and make sense of their contents. The parts
|
|
% of the runtime system that need to do this include exception handling,
|
|
% the debugger, and (eventually) the accurate garbage collector.
|
|
%
|
|
% When output by layout_out.m, values of most these types will correspond to
|
|
% the C types defined in runtime/mercury_stack_layout.h; the documentation of
|
|
% those types can be found there. The names of the C types are listed next to
|
|
% the function symbol whose arguments represent their contents.
|
|
%
|
|
% The code to generate values of these types is in stack_layout.m.
|
|
%
|
|
% This module is should be, but as yet isn't, independent of whether we are
|
|
% compiling to LLDS or MLDS.
|
|
%
|
|
% Author: zs.
|
|
|
|
%-----------------------------------------------------------------------------%
|
|
|
|
:- module layout.
|
|
|
|
:- interface.
|
|
|
|
:- import_module prog_data, trace_params, llds.
|
|
:- import_module std_util, list, assoc_list.
|
|
|
|
:- type layout_data
|
|
---> label_layout_data( % defines MR_Label_Layout
|
|
label :: label,
|
|
proc_layout_name :: layout_name,
|
|
maybe_port :: maybe(trace_port),
|
|
maybe_goal_path :: maybe(int), % offset
|
|
maybe_var_info :: maybe(label_var_info)
|
|
)
|
|
; proc_layout_data( % defines MR_Proc_Layout
|
|
proc_label,
|
|
proc_layout_stack_traversal,
|
|
maybe_proc_id_and_exec_trace
|
|
)
|
|
; module_layout_data( % defines MR_Module_Layout
|
|
module_name :: module_name,
|
|
string_table_size :: int,
|
|
string_table :: string,
|
|
proc_layout_names :: list(layout_name),
|
|
file_layouts :: list(file_layout_data),
|
|
trace_level :: trace_level
|
|
)
|
|
; closure_proc_id_data( % defines MR_Closure_Id
|
|
caller_proc_label :: proc_label,
|
|
caller_closure_seq_no :: int,
|
|
closure_proc_label :: proc_label,
|
|
closure_module_name :: module_name,
|
|
closure_file_name :: string,
|
|
closure_line_number :: int,
|
|
closure_goal_path :: string
|
|
).
|
|
|
|
:- type label_var_info
|
|
---> label_var_info( % part of MR_Label_Layout
|
|
encoded_var_count :: int,
|
|
locns_types :: rval,
|
|
var_nums :: rval,
|
|
type_params :: rval
|
|
).
|
|
|
|
:- type proc_layout_stack_traversal % defines MR_Stack_Traversal
|
|
---> proc_layout_stack_traversal(
|
|
entry_label :: maybe(label),
|
|
% The proc entry label; will be
|
|
% `no' if we don't have static
|
|
% code addresses.
|
|
succip_slot :: maybe(int),
|
|
stack_slot_count :: int,
|
|
detism :: determinism
|
|
).
|
|
|
|
:- type maybe_proc_id_and_exec_trace
|
|
---> no_proc_id
|
|
; proc_id_only
|
|
; proc_id_and_exec_trace(proc_layout_exec_trace).
|
|
|
|
:- type proc_layout_exec_trace % defines MR_Exec_Trace
|
|
---> proc_layout_exec_trace(
|
|
call_label_layout :: layout_name,
|
|
proc_body :: maybe(rval),
|
|
var_names :: list(int), % offsets
|
|
max_var_num :: int,
|
|
max_r_num :: int,
|
|
maybe_from_full_slot :: maybe(int),
|
|
maybe_io_seq_slot :: maybe(int),
|
|
maybe_trail_slot :: maybe(int),
|
|
maybe_maxfr_slot :: maybe(int),
|
|
eval_method :: eval_method,
|
|
maybe_call_table_slot :: maybe(int),
|
|
maybe_decl_debug_slot :: maybe(int)
|
|
).
|
|
|
|
:- type file_layout_data
|
|
---> file_layout_data(
|
|
file_name :: string,
|
|
line_no_label_list :: assoc_list(int, layout_name)
|
|
).
|
|
|
|
%-----------------------------------------------------------------------------%
|
|
|
|
:- type layout_name
|
|
---> label_layout(label, label_vars)
|
|
; proc_layout(proc_label, proc_layout_kind)
|
|
% A proc layout structure for stack tracing, accurate gc
|
|
% and/or execution tracing.
|
|
; proc_layout_var_names(proc_label)
|
|
% A vector of variable names (represented as offsets into
|
|
% the string table) for a procedure layout structure.
|
|
; closure_proc_id(proc_label, int, proc_label)
|
|
; file_layout(module_name, int)
|
|
; file_layout_line_number_vector(module_name, int)
|
|
; file_layout_label_layout_vector(module_name, int)
|
|
; module_layout_string_table(module_name)
|
|
; module_layout_file_vector(module_name)
|
|
; module_layout_proc_vector(module_name)
|
|
; module_layout(module_name).
|
|
|
|
:- type label_vars
|
|
---> label_has_var_info
|
|
; label_has_no_var_info.
|
|
|
|
:- type proc_layout_kind
|
|
---> proc_layout_traversal
|
|
; proc_layout_proc_id(proc_layout_user_or_compiler)
|
|
; proc_layout_exec_trace(proc_layout_user_or_compiler).
|
|
|
|
:- type proc_layout_user_or_compiler
|
|
---> user
|
|
; compiler.
|
|
|
|
%-----------------------------------------------------------------------------%
|