Re: [Caml-list] In-memory assembly

[Gabriel Scherer <gabriel.scherer@gmail.com>]

# 1

Loading compiler-libs module from the toplevel requires some black
magic because the toplevel is already built by linking the same
libraries. (see MPR#6704,
https://caml.inria.fr/mantis/view.php?id=6704). The "ocaml" toplevel
does more black magic than "utop" and it works better there, but in
general I would recommend experimenting with non-toplevel programs for
this specific purpose.

# 2

The various x86_* modules seem to internally define a

  print_line : Buffer.t -> X86_ast.asm_line -> unit

which does not involve filesystem i/o. I think that the simplest
solution to your question would be to expose this function in addition
to the global one. (If I were you I would feel free to send a Pull
Request performing this change for all x86 printer implementations,
although I don't know whether the maintainers of this part of the
codebase would find it desirable.)

That said, what you would get is an in-memory representation of the
assembler *text*; the compiler calls an assembler and linker as
external programs. If for some reason you wanted to avoid this, you
would have to link to an assembler as a library, and then it would
possibly be easier to directly feed the (X86_ast.asm_line list)
abstract representation -- with some conversion into the format this
assembler library expects. For this you don't need to modify the
interface of the printer modules.

On Wed, Jan 10, 2018 at 11:20 AM, Christoph Höger
<christoph.hoeger@celeraone.com> wrote:
> Dear all,
>
> I want to trigger OCaml compilation programmatically from a C++ application
> and avoid the usage of subprocesses. It is fairly straightforward to
> generate an OCaml AST, but I cannot compile it.
>
> 1. The relevant modules/libraries do not load
>
>   utop # #require "compiler-libs.optcomp";;
>   Error: Reference to undefined global `Location'
>
>   X86_masm.generate_asm stdout [] ;;
>
>
> 2. The relevant modules seem to insist on file i/o for communication (i.e.,
> they use out_channel objects)
>
>
> Does anyone know a simple way around these issues?
>
> a) Can I load the optcomp library without modifying the compiler (or with
> some simple modifications)
>
> b) Is there a way to create an out_channel  from a memory buffer?
>
> thanks,
>
> Christoph
>
> ps: If the answer to both questions is "no", I would be willing to work with
> the community and enhance the compiler if I could get some advice on how to
> do it best and if such a modification is wanted.