ocean-lang.org Git - ocean-D/blob - Byte Code

   1
   2 Thoughts on a bytecode level language to implement an OO language on.
   3
   4 Omo - Object/Method Oriented.
   5
   6 Everything is an object, and we do things by invoking methods on objects.
   7 This invocation passes some objects and returns some objects.
   8
   9 There are a small number of different implementation styles of
  10 objects (styles of classes).
  11  1/ builtin implementations, such as boolean and code variable
  12  2/ external implementation - e.g. C code
  13  3/ explicit implementations, built using code
  14
  15
  16 There are two different objects of type 'boolean'(class Boolean), one
  17 we call 'true', one we call 'false'.
  18 One of the methods that this type accepts is 'select', which take two
  19 objects and returns one of them.
  20
  21 The class 'code' accepts the method 'execute', and is passed ....
  22 something.
  23
  24 So to implement an if statement, we create code objects for the two
  25 forks, pass them with the select method to the condition, and invoke
  26 the execute method on the result.
  27
  28 To implement 'while', we evaluate the condition, then invoke the
  29 select method passing body and while loop, and null, and the 'execute'
  30 the result.
  31
  32 Maybe 'execute' should be passed a 'continuation' code, but it has to
  33 return sometime, so why not straight away.
  34
  35 So, while X do Y done; becomes
  36
  37 X.select(stuff, NOP).execute
  38
  39 stuff: Y ; X.select(stuff, NOP).execute ;
  40
  41 An explicit implementation provides a piece of 'code' for each method
  42 needed for that type.  An object of an explicit class contains a list
  43 of objects.  Some of these objects might be 'variables' but that is
  44 not essential.  They may well be externally implemented objects.
  45
  46 A variable supports two methods, get and set.  They return and
  47 receive a reference to an object, respectively.
  48
  49 A piece of code can contain object identifiers and method names
  50 (numbers, whatever).
  51 An object identifier can refer to
  52         A subobject within the current object.
  53         An object imported into the class of the current object.
  54         An object passed with the method which called this code
  55         A temporary object
  56 After a method completes, the object(s) that it returns are assigned
  57 to temporary objects so that other methods may access them.
  58
  59 So a 'code' starts with
  60         -> t1 t2 t3 ...
  61 to assign 'names' to passed object (references).
  62 Then has multiple
  63         Method (I1 I2 I3 I4 ) -> t6 t7 t8
  64 To call method on object I1 passing I2.. returning t6 ...
  65 And finally
  66         Return (I10 I11 I12)
  67 to return some object references.
  68
  69 One can imaging that the interpreted might do dependancy analysis and
  70 possibly invoke different methods in different threads if they are
  71 independant.
  72
  73 Question: What about when the dependancy is is sideeffects that cannot
  74 be seen from the calling patern.  Maybe method with side-effects need
  75 to be flagged -- what about methods that don't have side effects, but
  76 depend on the side effects of others...
  77 Probably just have sync points within the 'code'  such that preceding
  78 methods must complete before following ones commence.
  79
  80 Some methods might return 'pending' objects that in some way refer to
  81 a thread which is continuing to evaluate the method.  The interpreter
  82 would not then wait for that thread to finish until the object was
  83 actually needed. e.g. until it is ready to invoke a method, on it, or
  84 pass it to another method.  Some methods may allow pending objects to
  85 be passed in for certain arguments.
  86 This could allow easy parallelism.
  87 When the last reference to a 'pending' object is dropped, it may be
  88 appropriate to let it continue in it's own right, or it may be
  89 appropriate to terminate the thread(s) working to evaluate it.  This
  90 decision would probably depend on whether side effects are expected.
  91
  92 There would be some standard external classes, such as string and
  93 int32.
  94 The distinction between builtin and standard external classes depends
  95 on whether the interpreter needs to 'understand' the class, either for
  96 proper implementation of explicit classes, or for effective
  97 optimisation of code.
  98
  99 Multi-threading can be achived in two ways
 100         1/ with OS support, such as Pthreads
 101         2/ by round robining a number of states in the interpreter.
 102
 103 1 is probably fiddly as yet (witness the problems that java seems to
 104 have - or is that just for JIT compiling)
 105 2 does not naturally allow for multi-threading in external classes.
 106 For 2, we would have to require that external methods either be 'fast'
 107 or that they engage in co-operative multi-tasking, and never block.
 108 Thus there needs to be a return status which says "I haven't finished
 109 yet - call me again on *this* event", which might be selectable, or
 110 time, or process-exit, or immediate, or semaphore release.  This would
 111 presumably cause a thread to be created, and a pending object returned.
 112 The event would then be registered as blocking the thread.
 113
 114 Semphores probably need to be a builtin class.  Some methods will
 115 require a semaphore within the object to be Ped before continuing.
 116
 117 References to objects will probably be fat, including a reference to
 118 the class, and maybe a context.  Hopefully dynamic optimisations will
 119 reduce the need to always carry a fat pointer, but what about pointers
 120 that are embedded in objects, only compile time optimisations will be
 121 able to help them.
 122 Maybe some objects (types of) have the class pointer in the object,
 123 others have it with the pointer,and still others are determined to
 124 have a single implementation, and so need no class pointer. Or maybe
 125 the context can determine the class ??
 126
 127
 128 A "method" is a name-space-change plus a 'code'.
 129
 130 But sub-blocks like to allow local variables, so mini-methods are
 131 required, which inherit context.  In any context, we need a chain of
 132 parent contexts.  Many O-O langs have only "object" and "class" (and
 133 static "package"). I think that a completely general scheme is
 134 needed. Objects can often be 'part' of a larger object, from which
 135 some context is needed, and so-on recursively.