diogo/yap-6.3
Archived
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

fix bad reg

Browse Source 
docs
This commit is contained in:
Vitor Santos Costa 2018-10-15 13:48:10 +01:00
parent b41986ee3c
commit 127ebb2523
2 changed files with 79 additions and 82 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
C/control_absmi_insts.h
View File

@ -427,6 +427,8 @@ ructions *
Op(deallocate, p); Op(deallocate, p);
CACHE_Y_AS_ENV(YREG); CACHE_Y_AS_ENV(YREG);
// do this before checking
SREG = YREG;
check_trail(TR); check_trail(TR);
#ifndef NO_CHECKING #ifndef NO_CHECKING
/* check stacks */ /* check stacks */
@ -435,7 +437,6 @@ ructions *
PREG = NEXTOP(PREG, p); PREG = NEXTOP(PREG, p);
/* other instructions do depend on S being set by deallocate /* other instructions do depend on S being set by deallocate
:-( */ :-( */
SREG = YREG;
CPREG = (yamop *) ENV_YREG[E_CP]; CPREG = (yamop *) ENV_YREG[E_CP];
ENV = ENV_YREG = (CELL *) ENV_YREG[E_E]; ENV = ENV_YREG = (CELL *) ENV_YREG[E_E];
#ifdef DEPTH_LIMIT #ifdef DEPTH_LIMIT

156
C/dbase.c
View File

@ -25,90 +25,86 @@ static char SccsId[] = "%W% %G%";
* *
* @brief record and other forms of storing terms. * @brief record and other forms of storing terms.
* *
* @namespace prolog
*
*
*
* / * /
/** @defgroup Internal_Database Internal Data Base /** @defgroup Internal_Database Internal Data Base
*
@ingroup builtins * @ingroup builtins
@{ * @{
*
Some programs need global information for, e.g. counting or collecting * Some programs need global information for, e.g. counting or collecting
data obtained by backtracking. As a rule, to keep this information, the * data obtained by backtracking. As a rule, to keep this information, the
internal data base should be used instead of asserting and retracting * internal data base should be used instead of asserting and retracting
clauses (as most novice programmers do), . * clauses (as most novice programmers do), .
In YAP (as in some other Prolog systems) the internal data base (i.d.b. * In YAP (as in some other Prolog systems) the internal data base (i.d.b.
for short) is faster, needs less space and provides a better insulation of * for short) is faster, needs less space and provides a better insulation of
program and data than using asserted/retracted clauses. * program and data than using asserted/retracted clauses.
The i.d.b. is implemented as a set of terms, accessed by keys that * The i.d.b. is implemented as a set of terms, accessed by keys that
unlikely what happens in (non-Prolog) data bases are not part of the * unlikely what happens in (non-Prolog) data bases are not part of the
term. Under each key a list of terms is kept. References are provided so that * term. Under each key a list of terms is kept. References are provided so that
terms can be identified: each term in the i.d.b. has a unique reference * terms can be identified: each term in the i.d.b. has a unique reference
(references are also available for clauses of dynamic predicates). * (references are also available for clauses of dynamic predicates).
*
There is a strong analogy between the i.d.b. and the way dynamic * There is a strong analogy between the i.d.b. and the way dynamic
predicates are stored. In fact, the main i.d.b. predicates might be * predicates are stored. In fact, the main i.d.b. predicates might be
implemented using dynamic predicates: * implemented using dynamic predicates:
*
~~~~~ * ~~~~~
recorda(X,T,R) :- asserta(idb(X,T),R). * recorda(X,T,R) :- asserta(idb(X,T),R).
recordz(X,T,R) :- assertz(idb(X,T),R). * recordz(X,T,R) :- assertz(idb(X,T),R).
recorded(X,T,R) :- clause(idb(X,T),R). * recorded(X,T,R) :- clause(idb(X,T),R).
~~~~~ * ~~~~~
We can take advantage of this, the other way around, as it is quite * We can take advantage of this, the other way around, as it is quite
easy to write a simple Prolog interpreter, using the i.d.b.: * easy to write a simple Prolog interpreter, using the i.d.b.:
*
~~~~~ * ~~~~~
asserta(G) :- recorda(interpreter,G,_). * asserta(G) :- recorda(interpreter,G,_).
assertz(G) :- recordz(interpreter,G,_). * assertz(G) :- recordz(interpreter,G,_).
retract(G) :- recorded(interpreter,G,R), !, erase(R). * retract(G) :- recorded(interpreter,G,R), !, erase(R).
call(V) :- var(V), !, fail. * call(V) :- var(V), !, fail.
call((H :- B)) :- !, recorded(interpreter,(H :- B),_), call(B). * call((H :- B)) :- !, recorded(interpreter,(H :- B),_), call(B).
call(G) :- recorded(interpreter,G,_). * call(G) :- recorded(interpreter,G,_).
~~~~~ * ~~~~~
In YAP, much attention has been given to the implementation of the * In YAP, much attention has been given to the implementation of the
i.d.b., especially to the problem of accelerating the access to terms kept in * i.d.b., especially to the problem of accelerating the access to terms kept in
a large list under the same key. Besides using the key, YAP uses an internal * a large list under the same key. Besides using the key, YAP uses an internal
lookup function, transparent to the user, to find only the terms that might * lookup function, transparent to the user, to find only the terms that might
unify. For instance, in a data base containing the terms * unify. For instance, in a data base containing the terms
*
~~~~~ * ~~~~~
b * b
b(a) * b(a)
c(d) * c(d)
e(g) * e(g)
b(X) * b(X)
e(h) * e(h)
~~~~~ * ~~~~~
*
stored under the key k/1, when executing the query * stored under the key k/1, when executing the query
*
~~~~~ * ~~~~~
:- recorded(k(_),c(_),R). * :- recorded(k(_),c(_),R).
~~~~~ * ~~~~~
*
`recorded` would proceed directly to the third term, spending almost the * `recorded` would proceed directly to the third term, spending almost the
time as if `a(X)` or `b(X)` was being searched. * time as if `a(X)` or `b(X)` was being searched.
The lookup function uses the functor of the term, and its first three * The lookup function uses the functor of the term, and its first three
arguments (when they exist). So, `recorded(k(_),e(h),_)` would go * arguments (when they exist). So, `recorded(k(_),e(h),_)` would go
directly to the last term, while `recorded(k(_),e(_),_)` would find * directly to the last term, while `recorded(k(_),e(_),_)` would find
first the fourth term, and then, after backtracking, the last one. * first the fourth term, and then, after backtracking, the last one.
*
This mechanism may be useful to implement a sort of hierarchy, where * This mechanism may be useful to implement a sort of hierarchy, where
the functors of the terms (and eventually the first arguments) work as * the functors of the terms (and eventually the first arguments) work as
secondary keys. * secondary keys.
*
In the YAP's i.d.b. an optimized representation is used for * In the YAP's i.d.b. an optimized representation is used for
terms without free variables. This results in a faster retrieval of terms * terms without free variables. This results in a faster retrieval of terms
and better space usage. Whenever possible, avoid variables in terms in terms * and better space usage. Whenever possible, avoid variables in terms in terms
stored in the i.d.b. * stored in the i.d.b.
*
*
*
*/ */
#include "Yap.h" #include "Yap.h"