Re: [Caml-list] The Bytecode Interpreter...

[Gerd Stolpmann <info@gerd-stolpmann.de>]

Am Sonntag, den 23.10.2005, 14:03 +1300 schrieb Jonathan Roewen:
> > No difference. Toplevel expression are compiled as bytecode and then
> > executed by bytecode interpreter.
> 
> I think I'm starting to understand some of how the toplevel & bytecode
> interpreter work. Some of it, I don't understand why, so will continue
> from there ;-)
> 
> In the toplevel, you can #load in an ocaml library, but you still need
> all the .cmi files in order to open/use them. Why is that? Shouldn't
> it be in the library?

I don't know exactly the reasons, but I think this scheme is driven by
the needs of ocamlc, not the toplevel. If the interfaces were packed
into the .cma files, one would have to specify the .cma even for ocamlc
-c. As the command-line of ocamlc is patterned after the C compiler
command syntax, this would be quite surprising. Some hacks would become
impossible (e.g. several .cma implementations for the same set of .cmi).
I think the idea is not bad. One clear disadvantage would be that the
interfaces would be stored twice (in .cma and .cmxa) if one had both a
bytecode and a native code version of the library.

> Also, I presume loading libraries on the fly, and having access to
> -all- symbols defined in .cmi files available does -not- use the
> Dynlink module. Is this correct?

As far as I know, both Dynlink and the toplevel share parts of the
infrastructure needed for that. Dynlink only loads the bytecode,
relocates it, and resolves symbols pointing to already loaded libraries.
For this purpose, Dynlink maintains a symbol table (i.e. a mapping from
identifiers to addresses).

When one #loads within a toploop, more or less the same happens.
However, the toploop is a full compiler, and does not only have the
symbol table, but also the current environment, i.e. the set of
currently visible types and values with the still-needed parts of their
definitions. As far as I know, #load does not modify the environment
(because nothing changes - the loaded modules are already in scope when
the .cmi file is in the search path).

> How can a bytecode program do the same things as the toplevel in terms
> of #load-ing libraries and accessing any given value as specifed in
> the compiled interface files?

Because it has the symbol table. It is part of every bytecode executable
and .cmo file, but normally not loaded, because not needed for
execution. When Dynlink is initialized, the symbol table is extracted
from the bytecode executable.

> Lastly, why is the Dynlink module unable to provide the ability to
> access any given value in a compiled interface file when loading a
> bytecode object? Or can it? The comments for the Dynlink module
> specify that this -isn't- possible. However, it -can- access values
> from the program the loads the .cmo -- is that correct?

In principle, it can. As mentioned, it has the symbol table, so it can
look up every symbol.

However, the question arises how to access symbols at runtime while
keeping type safety. A function like dlopen cannot be type safe and is
not provided (or better, this interface is not installed - see the
compiler module Symtable for direct access, it is part of Dynlink).

To ensure type safety at runtime, O'Caml uses interface hashes (MD5
sums). A new module can only access already loaded modules when it knows
the MD5 sums, i.e. is compiled against the same interfaces. So the
reason for the restriction of only being able to "look back" from the
new module to the existing modules is that this scheme opens a way to
check type safety. 

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
Telefon: 06151/153855                  Telefax: 06151/997714
------------------------------------------------------------