On 18/04/18 22:39, Cubreacov Misha wrote:
> But the source code of this "interpreter", you do not know where I could
> find .
https://github.com/SWI-Prolog/
In particular the files pl-wam.c and pl-vmi.c from swipl-devel.git
I consider "interpreter" a bit misleading term. This term was used long
ago for languages that executed the statements directly from the source
code. That is rare these days. Possibly shells still do that. Most
modern high level languages use the `virtual machine' design where the
source is translated to instructions for a virtual machine that is
typically implemented in C/C++. That holds for Prolog, Python, Java,
JavaScript, Perl and many others. Some of these perform `hotspot
optimization' where heavily used bits of code are detected at runtime,
optimized and compiled to machine code using e.g., LLVM.
The most polular VM is the WAM (Warren Abstract Machine). Despite the
naming, the SWI-Prolog VM is based on a minimal VM described by Pereira
and Byrd which is closely related to the `ZIP' VM. The main difference
is that this VM passes arguments over the stack rather than using
registers.
I'm not entirely sure what the status here is wrt. Prolog. Surely
SWI-Prolog uses a VM but no hotspot optimization. The only (but crucial)
runtime optimization peformed is creating `clause indexes':
(hash-)tables that allow it to find candidate clauses from a given goal
quickly.
Some Prolog systems do compile to native code, often using the VM code
as intermediate. GNU-Prolog is a good example. All in all, the advantage
of native code for Prolog is not obvious. The VM instructions have a
larger granularity than for imperative languages which significantly
reduces the overhead of the VM. Using VM code allows for decompilation
and runtime reachability analysis for GC.
If you want to study this stuff, I'd start with some minimal WAM based
implementation as this is all well described in the literature.
Cheers --- Jan