[m-rev.] diff: documentation and hlds_dump fixes
Zoltan Somogyi
zs at csse.unimelb.edu.au
Fri Sep 28 16:46:47 AEST 2007
compiler/llds.m:
Improve some old documentation.
compiler/hlds_out.m:
Fix some formatting problems in the output.
Zoltan.
Index: hlds_out.m
===================================================================
RCS file: /home/mercury/mercury1/repository/mercury/compiler/hlds_out.m,v
retrieving revision 1.435
diff -u -b -r1.435 hlds_out.m
--- hlds_out.m 25 Sep 2007 04:56:38 -0000 1.435
+++ hlds_out.m 28 Sep 2007 06:26:09 -0000
@@ -1392,11 +1392,11 @@
;
Purity = purity_semipure,
write_indent(Indent, !IO),
- io.write_string("% semipure\n ", !IO)
+ io.write_string("% semipure\n", !IO)
;
Purity = purity_impure,
write_indent(Indent, !IO),
- io.write_string("% impure\n ", !IO)
+ io.write_string("% impure\n", !IO)
)
;
true
@@ -2434,7 +2434,7 @@
;
ConstructHow = construct_in_region(RegVar),
write_indent(Indent, !IO),
- io.write_string(" construct in region: ", !IO),
+ io.write_string("% construct in region: ", !IO),
mercury_output_var(ProgVarSet, AppendVarNums, RegVar, !IO),
io.write_string("\n", !IO)
).
Index: llds.m
===================================================================
RCS file: /home/mercury/mercury1/repository/mercury/compiler/llds.m,v
retrieving revision 1.352
diff -u -b -r1.352 llds.m
--- llds.m 20 Aug 2007 03:35:57 -0000 1.352
+++ llds.m 28 Sep 2007 03:36:47 -0000
@@ -326,15 +326,19 @@
; incr_hp(lval, maybe(tag), maybe(int), rval, string,
may_use_atomic_alloc, maybe(rval))
- % Get a memory block of a size given by an rval and put its address
- % in the given lval, possibly after incrementing it by N words
- % (if the maybe(int) is bound to `yes(N)') and/or after tagging it
- % with a given tag. The string gives the name of the type
+ % incr_hp(Target, MaybeTag, MaybeOffset, SizeRval, TypeMsg,
+ % MayUseAtomicAlloc, MaybeRegionId)
+ %
+ % Get a memory block of a size given by SizeRval and put its
+ % address in Target, possibly after incrementing it by Offset words
+ % (if MaybeOffset = yes(Offset)) and/or after tagging it with Tag
+ % (if MaybeTag = yes(Tag)). TypeMsg gives the name of the type
% constructor of the memory cell for use in memory profiling.
- % The may_use_atomic_alloc argument says whether we can use the
- % atomic variants of the Boehm gc allocator calls. The last
- % argument says if the memory block is from a region or not, and
- % if yes, from which region.
+ % MayUseAtomicAlloc says whether we can use the atomic variants
+ % of the Boehm gc allocator calls. If MaybeRegionId =
+ % yes(RegionId), then the block should be allocated in the region
+ % identified by RegionId (i.e. in the region whose header RegionId
+ % points to).
; mark_hp(lval)
% Tell the heap sub-system to store a marker (for later use in
@@ -353,9 +357,9 @@
; push_region_frame(region_stack_id, embedded_stack_frame_id)
% push_region_frame(RegionStackId, EmbeddedStackId)
%
- % Set the stack pointer of the region stack identified by the
- % first argument to point to the group of stack slots identified
- % by the second argument (which specifies to the new top embedded
+ % Set the stack pointer of the region stack identified by
+ % RegionStackId to point to the group of stack slots identified
+ % by EmbeddedStackId (which specifies the new top embedded
% stack frame on that stack) *after* saving the old value of the
% stack pointer in the fixed slot reserved for this purpose in
% the new frame.
@@ -506,44 +510,48 @@
fproc_stack_slot_ref :: bool,
fproc_maybe_dupl :: proc_may_duplicate
)
- % The first argument says what local variable declarations
- % are required for the following components, which in turn
- % can specify how the inputs should be placed in their
- % variables, how the outputs should be picked up from their
- % variables, and C code both from the program and the compiler.
- % These components can be sequenced in various ways. This
- % flexibility is needed for nondet pragma C codes, which
- % need different copies of several components for different
- % paths through the code.
+ % foreign_proc_code(Decls, Components. MayCallMercury,
+ % FixNoLayout, FixLayout, FixOnlyLayout, NoFix, StackSlotRef,
+ % MayBeDupl)
+ %
+ % Decls says what local variable declarations are required for
+ % Components, which in turn can specify how the inputs should be
+ % placed in their variables, how the outputs should be picked up
+ % from their variables, and C code both from the source program
+ % and generated by the compiler. These components can be sequenced
+ % in various ways. This flexibility is needed for nondet
+ % foreign_procs, which need different copies of several components
+ % for different paths through the code.
%
- % The third argument says whether the user C code components
+ % MayCallMercury says whether the user C code components
% may call Mercury; certain optimizations can be performed
% across foreign_proc_code instructions that cannot call Mercury.
%
% Some components in some foreign_proc_code instructions refer to
% a Mercury label. If they do, we must prevent the label
% from being optimized away. To make it known to labelopt,
- % we mention it in the fourth, fifth or sixth arg. The fourth
- % argument may give the name of a label whose name is fixed
+ % we mention it in the FixNoLayout, FixLayout or FixOnlyLayout
+ % fields.
+ %
+ % FixNoLayout may give the name of a label whose name is fixed
% because it embedded in raw C code, and which does not have
- % a layout structure. The fifth and sixth arguments may give
- % the names of labels whose names are fixed because they do
- % have an associated label layout structure. The label in the
- % fifth argument may appear in C code; the label in the sixth
- % argument may not (such a label may therefore may be deleted
- % from the LLDS code if it is not referred to from anywhere
- % else). The seventh argument may give the name of a label
- % that can be changed (because it is not mentioned in C code
- % and has no associated layout structure, being mentioned only
- % in foreign_proc_fail_to components).
- %
- % The stack_slot_ref argument says whether the contents of the
- % pragma C code can refer to stack slots. User-written
- % shouldn't refer to stack slots, the question is whether
- % the compiler-generated C code does.
+ % a layout structure. FixLayout and FixOnlyLayout may give
+ % the names of labels whose names are fixed because they *do*
+ % have an associated label layout structure. The label in FixLayout
+ % may appear in C code; the label in FixOnlyLayout argument may not
+ % (such a label may therefore may be deleted from the LLDS code
+ % if it is not referred to from anywhere else). The NoFix field
+ % may give the name of a label that can be changed (because it is
+ % not mentioned in C code and has no associated layout structure,
+ % being mentioned only in foreign_proc_fail_to components).
+ %
+ % StackSlotRef says whether the contents of the foreign_proc
+ % C code can refer to stack slots. User-written shouldn't refer
+ % to stack slots, the question is whether any compiler-generated
+ % C code does.
%
- % The maybe_dupl says whether this instruction may be
- % duplicated by jump optimization.
+ % MayBeDupl says whether this instruction may be duplicated
+ % by jump optimization.
; init_sync_term(lval, int)
% Initialize a synchronization term. The first argument contains
--------------------------------------------------------------------------
mercury-reviews mailing list
Post messages to: mercury-reviews at csse.unimelb.edu.au
Administrative Queries: owner-mercury-reviews at csse.unimelb.edu.au
Subscriptions: mercury-reviews-request at csse.unimelb.edu.au
--------------------------------------------------------------------------
More information about the reviews
mailing list