Home My Page Projects Code Snippets Project Openings SML/NJ
Summary Activity Forums Tracker Lists Tasks Docs Surveys News SCM Files

SCM Repository

[smlnj] Diff of /sml/trunk/src/system/README
ViewVC logotype

Diff of /sml/trunk/src/system/README

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 568, Tue Mar 7 03:59:09 2000 UTC revision 569, Tue Mar 7 04:01:07 2000 UTC
# Line 61  Line 61 
61    
62          CM.autoload "host-cmb.cm";          CM.autoload "host-cmb.cm";
63    
64  after you start sml.  after you start sml.  Alternatively -- and perhaps more conveniently --
65    you can provide "host-cmb.cm" as a command-line argument to sml:
66    
67  * Compiling the compiler -- a two-step procedure        $ sml host-cmb.cm
68  ------------------------------------------------  
69    * Compiling the compiler
70    ------------------------
71    
72  Until now (with the old CM), once we managed to run CMB.make() to  We are now back to the old scheme where a call to CMB.make() suffices to
73  completion we had a directory full of binfiles that were ready to be  build a bootable set of files (libraries in our case).  CMB.make maintains
74  used by the boot procedure.  This is no longer the case.  two parallel hierarchies of derived files:
75    
76  The boot procedure now wants to use stable libraries (except for the    1. the binfile hierarchy ("binfiles"), containing compiled objects for
77  part that makes up the pervasive environment).  Having stable       each individual ML source file; this hierarchy is rooted at
78  libraries around during development of these very libraries would be a        <prefix>.bin.<arch>-<opsys>
79  bit annoying because if CM sees a stable library it will no longer    2. the stable library hierarchy ("boot files"), containing library files
80  bother to check the corresponding source files -- even if they have       for each library that participates in building SML/NJ; this hierarchy
81  changed.  Therefore, libraries are not stabilized until you think you       is rooted at
82  are ready for that.  Thus, you should run:        <prefix>.boot.<arch>-<opsys>
83    
84          CMB.make ();  The default for <prefix> is "sml".  It can be changed by using
85    CMB.make' with the new <prefix> as the optional string argument.
86  until you no longer get compile errors.  CMB.make will return true in  
87  this case.  Then you say:  CMB.make uses bootfiles after it has verified that they are consistent
88    with their corresponding binfiles.  Bootfiles do not need to be
89          CMB.deliver ();  deleted in order for CMB.make to work correctly.
90    
91  This command creates a second directory parallel to the "bin"  To bootstrap a new system (using the runtime system boot loader), the
92  directory -- the "boot" directory.  It will hold everything necessary  bootfiles _must_ be present, the binfiles need not be present (but
93  to bootstrap a new heap image.  You will probably find that  their presence does not hurt either).
 CMB.deliver() compiles a number of additional files even though  
 CMB.make completed successfully.  This is because CMB.make compiles  
 just those modules that will actually go into the heap image, but  
 CMB.deliver must also build the remaining files -- files that are part  
 of libraries to be stabilized but which are not used by the compiler.  
94    
95  You can reduce the number of extra files compiled and stabilized  You can reduce the number of extra files compiled and stabilized
96  during CMB.deliver at the expense of not building any cross-compilers.  during CMB.make at the expense of not building any cross-compilers.
97  For that, say  For that, say
98          #set (CMB.symval "LIGHT") (SOME 1);          #set (CMB.symval "LIGHT") (SOME 1);
99  before running CMB.deliver.  before running CMB.make.
   
 After you have made the boot directory, if you want to continue  
 developing the compiler (i.e., make changes to some sources,  
 recompile, etc.), you must first get rid of that boot directory.  
 Running the "makeml" script (see below) will automatically remove the  
 boot directory.  
   
 The names of "bin" and "boot" directories are  
   
         <prefix>.bin.<arch>-<os>  
   
 and  
   
         <prefix>.boot.<arch>-<os>  
   
 respectively, with "sml" being the default for <prefix>.  To change  
 the prefix, use CMB.make' and CMB.deliver' with the new prefix  
 provided as the optional string argument to these functions.  
100    
101  * Making the heap image  * Making the heap image
102  -----------------------  -----------------------
# Line 129  Line 109 
109  The "feel" of using makeml should be mostly as it used to.  However,  The "feel" of using makeml should be mostly as it used to.  However,
110  internally, there are some changes that you should be aware of:  internally, there are some changes that you should be aware of:
111    
112  1. The script will make a heap image and also move its associated  1. The script will make a heap image and build a separate library directory
113     libraries into a separate directory.     that contains links to the library files in the bootfile directory.
114    
115  2. There is no "-full" option anymore.  This functionality should  2. There is no "-full" option anymore.  This functionality should
116     eventually be provided by a library with a sufficiently rich export     eventually be provided by a library with a sufficiently rich export
# Line 142  Line 122 
122     option to actually make the image.  The argument to "-rebuild"     option to actually make the image.  The argument to "-rebuild"
123     is the <prefix> for the new bin and boot directories (see above).     is the <prefix> for the new bin and boot directories (see above).
124    
125  4. Unless you use "-rebuild", makeml will delete the boot directory  Makeml will not destroy the bootfile directory.
    (thus readying you for further "CMB.make();" runs).  
126    
127  * Testing a newly generated heap image  * Testing a newly generated heap image
128  --------------------------------------  --------------------------------------
# Line 151  Line 130 
130  If you use a new heap image by saying "sml @SMLload=..." then things  If you use a new heap image by saying "sml @SMLload=..." then things
131  will not go as you may expect because along with the new heap image  will not go as you may expect because along with the new heap image
132  should go those new stable libraries, but unless you do something  should go those new stable libraries, but unless you do something
133  about it, the new CM will look for its stable libraries in places  about it, the newly booted system will look for its stable libraries
134  where you stored your _old_ stable libraries.  in places where you stored your _old_ stable libraries.
135    
136  After you have made the new heap image, the new libraries are in a  After you have made the new heap image, the new libraries are in a
137  separate directory whose name is derived from the name of the heap  separate directory whose name is derived from the name of the heap
138  image.  The "testml" script that you also find here will run the heap  image.  (Actually, only the directory hierachy is separate, the
139  image and instruct it to look for its libraries in that new library  library files themselves are hard links.)  The "testml" script that you
140  directory.  also find here will run the heap image and instruct it to look for its
141    libraries in that new library directory.
142    
143  "testml" takes the <prefix> of the heap image as its first  "testml" takes the <prefix> of the heap image as its first
144  argument. All other arguments are passed verbatim to the ML process.  argument. All other arguments are passed verbatim to the ML process.
# Line 182  Line 162 
162  "installml" patches the ../../lib/pathconfig file to reflect any  "installml" patches the ../../lib/pathconfig file to reflect any
163  changes or additions to the path name mapping.  changes or additions to the path name mapping.
164    
165  Thus, after a successful CMB.deliver, you should say  Thus, after a successful CMB.make, you should say
166    
167          ./makeml          ./makeml
168    
# Line 234  Line 214 
214  <os> can be either "unix" or "macos" or "win32".  <os> can be either "unix" or "macos" or "win32".
215  (Obviously, not all combinations are valid.)  (Obviously, not all combinations are valid.)
216    
217    Again, as with host-cmb.cm, you can specify the .cm file as an
218    argument to the sml command:
219    
220        $ sml target-compilers.cm
221    
222    or
223    
224        $ sml alpha32-unix.cm
225    
226  * Path configuration  * Path configuration
227  --------------------  --------------------
228    
# Line 384  Line 373 
373  library, n for n sub-groups), there will be just one file representing  library, n for n sub-groups), there will be just one file representing
374  the one stable archive (per architecture/os) for the whole thing.  For  the one stable archive (per architecture/os) for the whole thing.  For
375  example, I structured the standard basis into one library with two  example, I structured the standard basis into one library with two
376  sub-groups, but once you compile it (CMB.deliver) there is only one  sub-groups, but once you compile it (CMB.make) there is only one
377  stable file that represents the whole basis library.  If groups were  stable file that represents the whole basis library.  If groups were
378  allowed to appear in more than one library, then stabilization would  allowed to appear in more than one library, then stabilization would
379  duplicate the group (its code, its environment data structures, and  duplicate the group (its code, its environment data structures, and
# Line 399  Line 388 
388  * Pervasive environment, core environment, the init group "init.cmi"  * Pervasive environment, core environment, the init group "init.cmi"
389  -------------------------------------------------------------------------  -------------------------------------------------------------------------
390    
391  CMB.make (or CMB.deliver) starts out by building and compiling the  CMB.make starts out by building and compiling the
392  "init group".  This group cannot be described in the "usual" way  "init group".  This group cannot be described in the "usual" way
393  because it uses "magic" in three ways:  because it uses "magic" in three ways:
394   - it is used to later tie in the runtime system   - it is used to later tie in the runtime system
395   - it builds the "core" environment   - it exports the "core" environment
396   - it builds the "pervasive" environment   - it exports the "pervasive" environment
397    
398  The pervasive environment no longer includes the entire basis library  The pervasive environment no longer includes the entire basis library
399  but only non-modular bindings (top-level bindings of variables and  but only non-modular bindings (top-level bindings of variables and
400  types).  types).
401    
402  CM cannot automatically determine dependencies for the init group  CM cannot automatically determine dependencies (or exports) for the
403  source files, but it still does use its regular cutoff recompilation  init group source files, but it still does use its regular cutoff
404  mechanism.  Therefore, dependencies must be given explicitly.  This is  recompilation mechanism.  Therefore, dependencies must be given
405  done by a special description file which currently lives in  explicitly.  This is done by a special description file which
406  Init/init.cmi.  See the long comment at the beginning of that file for  currently lives in Init/init.cmi.  See the long comment at the
407  more details.  beginning of that file for more details.
408    
409  After it is built, init.cmi can be used as an "ordinary" library by  After it is built, init.cmi can be used as an "ordinary" library by
410  other libraries.  (This is done, for example, by the implementation of  other libraries.  (This is done, for example, by the implementation of
411  the Basis library.)  Access to "init.cmi" is protected by the  the Basis library.)  Access to "init.cmi" is protected by the
412  privilege named "primitive".  privilege named "primitive".  Also, note that the .cmi-file is not
413    automatically recognized as as CM description file.  Therefore, it
414    must be given an explicit member class:
415    
416         init.cmi : cm
417    
418  * Autoloader  * Autoloader
419  ------------  ------------
420    
421  The new system heavily relies on the autoloader.  As a result, almost  The new system heavily relies on the autoloader.  As a result, almost
422  no static environments need to get unpickled at bootstap time.  The  no static environments need to get unpickled at bootstrap time.  The
423  construction of such environments is deferred until they become  construction of such environments is deferred until they become
424  necessary.  Because of this, I was able to reduce the size of the heap  necessary.  Thanks of this, it was possible to reduce the size of the
425  image by more than one megabyte (depending on the architecture).  The  heap image by more than one megabyte (depending on the architecture).
426  downside (although not really terribly bad) is that there is a short  The downside (although not really terribly bad) is that there is a
427  wait when you first touch an identifier that hasn't been touched  short wait when you first touch an identifier that hasn't been touched
428  before.  (I acknowledge that the notion of "short" may depend on your  before.  (I acknowledge that the notion of "short" may depend on your
429  sense of urgency. :-)  sense of urgency. :-)
430    
# Line 564  Line 557 
557    
558  Don't use relative or absolute pathnames to refer to libraries.  If  Don't use relative or absolute pathnames to refer to libraries.  If
559  you do it anyway, you'll get an appropriate warning at the time when  you do it anyway, you'll get an appropriate warning at the time when
560  you do CMB.deliver().  If you use relative or absolute pathnames to  you do CMB.make().  If you use relative or absolute pathnames to
561  refer to library B from library A, you will be committed to keeping B  refer to library B from library A, you will be committed to keeping B
562  in the same relative (to A) or absolute location.  This, clearly,  in the same relative (to A) or absolute location.  This, clearly,
563  would be undesirable.  would be undesirable.

Legend:
Removed from v.568  
changed lines
  Added in v.569

root@smlnj-gforge.cs.uchicago.edu
ViewVC Help
Powered by ViewVC 1.0.0