home *** CD-ROM | disk | FTP | other *** search
/ The World of Computer Software / World_Of_Computer_Software-02-385-Vol-1of3.iso / m / me_cd25.zip / DOC.ZIP / INSIDEMU < prev    next >
Text File  |  1992-11-09  |  6KB  |  194 lines
  1. -*-text-*-
  2.  
  3.                  Inside Mutt
  4.                  ------ ----
  5.  
  6.     Notes on what goes on under the hood of an embedded language.
  7.  
  8.  
  9.  
  10.             Overview of Embedded Languages
  11.             -------- --    -------- ---------
  12.  
  13. Why embedded languages are cool
  14. Why you want one in your application
  15.   - less code to debug, just need a core "machine"
  16.   - easier to expand
  17.   - same extension language in all your applications
  18. Typed (kinda),  why:  runtime error checking
  19. Compiled.  why: static checking and speed
  20. Algol like
  21. Stack based
  22. procedure called based
  23. "Loosely" coupled with application:
  24.   Standalone language
  25.   Don't know much about the application
  26.   General purpose - never will know much about application
  27.   Has "library" (mmaux.c) that has functions used to interface with
  28.     application.
  29.   This makes it very easy to add Mutt to about any application.
  30. Drawbacks:
  31.   Hard for Joe Average-Application-User to modify.
  32.  
  33.  
  34.                Internal Objects
  35.                -------- -------
  36.  
  37. Characteristics:
  38.   Mutt knows everything there is to know about these objects.
  39.   Should act like regular vars - globals live as long as the block,
  40.     locals come and go with a stack frame.
  41.   Since objects are [big] structs and might be used in outside
  42.     libraries, they can be a pain:
  43.     - MC has know to deal with them.  This can be rude from the machine
  44.       independent aspect.
  45.     - It can be a pain to dig and reassemble the struct from a chunk of
  46.       memory.  Can't use C to just stuff it or retrieve because
  47.       different machines require more/less space and different
  48.       alignments.  To do that would require MC to know the biggest the
  49.       struct could ever be as well as the worst case alignment.
  50.   Might be easier to add special instructions for each object and keep
  51.     some kind of numeric id in var memory and have separate areas and
  52.     code to maintain them.  
  53.     Pro:
  54.     - MC just thinks of objects as numbers.
  55.     - 
  56.     Con:
  57.     - Not as easy to control stack growth.  More work to sync it with
  58.       var stack.
  59.     - Yet more stacks to control, more memory being used up.
  60.     - More opcodes.
  61.     How To:
  62.     - Local:
  63.       - (create-local-objects n):  Create n objects for use in current
  64.     stack frame.  Have to remember where previous stack frame
  65.     starts.  This can be stored in the var stack frame.  Have to
  66.     remember where this frame starts.
  67.       - (free-local-objects):  Free all objects in the current stack
  68.     frame.
  69.       - (gc-local-objects):  Free all local objects.
  70.       - (set-local-object n):  Set the nth object in the current stack
  71.         frame.
  72.       - (get-local-object n):  Get the nth object in the current stack
  73.         frame.
  74.     - Global:
  75.       - (create-global-object n offset-1 ...  offset-n):  Create n
  76.     objects as global objects.  Store their ids in offset-i.
  77.       - (free-global-object offset):  Free the object whos id is stored
  78.     in offset.
  79.       - (gc-global-objects block):  Free all objects associated with
  80.     block.  This probably just entails calling the block prologue.
  81.       - (set-global-object offset):  Set the object whos id is stored in
  82.     offset.
  83.       - (get-global-object offset):  Get the object whos id is stored in
  84.     offset.
  85. EG: dStrings
  86. Constructors
  87. Destructors
  88. Local Objects
  89.   garbage collection if program aborts
  90.   prologue
  91.   epilogue
  92. Global
  93.   garbage collection if block is removed
  94.   prologue
  95.   epilogue
  96. Wants:
  97.   Want fast allocate/free for (at least) local objects
  98.   Need to gc all local objects in event of abort, without knowing
  99.     anything except that they are local.
  100.   Need to be able to gc all objects if a block is freed.  Do this by
  101.     calling the block epilogue.
  102.   
  103.  
  104.  
  105.                External Objects
  106.                -------- -------
  107.  
  108. Characteristics:
  109.   Don't know what they are
  110.   Don't know how to GC them
  111.   Allocated by external source, I just have an id
  112. EG Buffers
  113. How created
  114. How freed
  115. How GCed in case of problems
  116. Global vs local
  117.  
  118.  
  119.            Garbage Collection for Embedded Systems
  120.            ------- ---------- --- -------- -------
  121.  
  122. Need GC because:
  123.   If a programs tanks, all the objects allocated so far won't be freed.
  124.   Less for the programmer to worry about or forget.
  125.   Programmers are bound to forget a few frees and never notice.
  126.   Mutt strings.
  127.  
  128. Domains:
  129.   Internal Mutt:
  130.     dStrings.
  131.     OOP:  Probably don't need gc - constructors and destructors can
  132.       handle the normal cases.  GC is needed for when the program is
  133.       aborted.
  134.   External Mutt:
  135.     Objects can be allocated that Mutt will never know how to deal with.
  136.     For example: Bags, Marks, Buffers.
  137.  
  138. Constraints:
  139.   Don't want to slow down programs.
  140.  
  141. Solutions:
  142.   Internal:
  143.     Pool strings so can gc on abort or program termination.  Handle like
  144.       external objects (or OOP):
  145.         {
  146.       (string foo bar)
  147.       (foo "this is a test")
  148.       (done)
  149.       (bar foo)
  150.     }
  151.       generates code:
  152.         {
  153.       (int foo bar)
  154.       (foo (create-string)) (bar (create-string))
  155.  
  156.       (copy-to-string foo "this is a test")    ;; (foo "this is a test")
  157.       (goto gc-strings)            ;; (done)
  158.       (copy-to-string bar (get-string foo))    ;; (bar foo)
  159.  
  160.       (label gc-strings)
  161.       (free-string foo bar)
  162.       (done)
  163.     }
  164.     Need new ops:
  165.       (create-string [global])        ;; RV gets string id
  166.       (copy-to-string string-id text)    ;; RV gets texts, put in string
  167.       (get-string string-id)        ;; RV gets char *
  168.       (free-string id)            ;; 
  169.     Global strings:
  170.       Need global strings so have 2 pools - Mortal and Immortal.  No id
  171.         overlap!
  172.  
  173.   External:
  174.     When external objects are allocated, they are flagged Mortal or
  175.       Immortal.  When a program stops running or aborts,
  176.       MMgc_foreign_objects() is called.  The external "process" can then
  177.       sweep the object lists and remove all objects marked Mortal.
  178.     Pros:
  179.       Easy.  Doesn't slow program execution.
  180.     Cons:
  181.       Not real GC.  If the programmer is lazy and doesn't free stuff, it
  182.     could be while before the resources are freed (programs that
  183.     repeatedly call a routine that creates objects).
  184.  
  185.  
  186.                  Mutt Machine
  187.                  ---- -------
  188.  
  189. Instructions
  190.   Never ment to be compiled down to machine language
  191.   Tradeoffs:  small memory used, tagged, high level, portable.
  192.   problems:
  193.     reading/writing numbers:  byte order, alignment
  194.