[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