[gambit-list] Module system ELS20 presentation

Marc Feeley feeley at iro.umontreal.ca
Mon Apr 27 22:30:10 EDT 2020


> On Apr 27, 2020, at 10:24 AM, Marc Feeley <feeley at iro.umontreal.ca> wrote:
> 
>> 
>> A Termite-specific question:  why send bytecode rather than C (perhaps minified by removing whitespace)?  Presumably that would cost nothing at the source node (it's already been done) and be faster and cheaper at the destination node?  Is the bytecode so much more compact as to make transmitting C untenable?
> 
> Termite does not send bytecode.  If you are referring to the slides, we were just saying “one way to implement portable code is with bytecode” but Termite does not do that.  It can either send what is essentially an AST (in the “interpreted” code case), or a symbolic reference to the compiled code control point (in the “compiled” code case).  A symbolic reference is basically the pair <procedure_name, seq_number>.

I notice my answer doesn’t cover all your questions.

Even though the C code generated by the Gambit compiler is portable and could be compiled on all the platforms, it is not quite sufficient to do it that way because macros can observe properties of the system where the library was built.  So it is conceivable that a macro could affect the generated C code.  This has the potential to ruin deserialization of procedures if the macro behaves badly, but if the “programmer knows what he’s doing” (like have a macro that simply put’s the build machine’s hostname in the binary, or a random number stamp) then all is well.

Apart from that problem, there are lots of ways to represent the code, with various levels of space usage (tested with lib/_num.scm):

     3396 KB  _num.c  (C code generated by gsc from _num.scm)
      446 KB  _num.scm
      296 KB  gzip -9 _num.c
      276 KB  _num.scm (read-all of _num.scm followed by write)
      153 KB  binary serialization format (read-all of _num.scm followed by object->u8vector)
       88 KB  gzip -9 _num.scm
       60 KB  gzip -9 of (read-all of _num.scm followed by write)
       55 KB  gzip -9 of binary serialization format

So there’s a factor of 62x between the most compact and least compact representation.  The various forms of the C code are not on the best side of that scale…

Marc





More information about the Gambit-list mailing list