A.I. programming in Prolog and Assembler

July 20, 2008

Assembly Language for Visual Prolog Meta-programming

Visual Prolog Integrated...Image via Wikipedia
Back in 2005, while working in large-scale programming projects for data-mining in G.I.S. and Hydrology, I wrote a Prolog interpreter called G.I.S. Prolog, equipped with many extra predicates (such as functions to locate points inside polygons, etc).The G.I.S. Prolog interpreter was originally based on the “PIE interpreter” (included as free source-code in Visual Prolog) but it ended up enhanced with many extra predicates, as well as an improved core-level inference mechanism.
Ever since I started using the Visual Prolog compilers (and the PDC Prolog compilers preceding them) I was fascinated by the possibilities of implementing additional ISO-Prolog functionality in Visual Prolog through Assembly Language and ‘C’. Of course, such attempts are inherently limited by the internal design of Visual Prolog compilers. So, the only way to implement ISO-Prolog functionality in Visual Prolog is to extend the “PIE Interpreter” (and G.I.S. Prolog as its offspring). A multitude of extra predicates, implemented in pure Assembly language, became available through G.I.S. Prolog for easy immediate experimentation: Coding in G.I.S. Prolog produced immediate results, without any need for (often tedious) EXE-file compilation. Code modifications could therefore be done very quickly and most mistakes were (semi-)automatically corrected by the interpreter’s own enhanced error-checking capabilities.

Recently, I discovered some Assembly language techniques to enhance G.I.S. Prolog even further, potentially valuable for a multitude of other purposes. They also have an intrinsic fascination in themselves, as general tools for Prolog meta-programming.

E.g. here is an Assembly language predicate, that takes as inputs another (external) predicate’s memory-address and a (Visual Prolog-) argument-list, and calls this (external) predicate, using the (arbitrary-length-) list of N arguments, as arguments of “arity N”:

apply_func(PRED, [Arg,Arg2,…]) <=> PRED(Arg1,Arg2,…)

Now, in ISO-Prolog there is a standard predicate known as “univ”, written as “=..“, which turns a list like [PRED,ARG1,ARG2,ARG3…] into a predicate call such as PRED(ARG1,ARG2,…). However, this does not exist in Visual Prolog, which sacrifices such “luxuries” for speed (which is the reason I also often use ISO-Prolog compilers, such as LPA-WinProlog and SWI-Prolog).

Anyway… The code you are about to see can be useful more generally, as an example of Prolog meta-programming, implemented in Assembly Language. The only difference between the way it works for Visual Prolog and the way it might work for another Prolog (or -indeed- ANY programming language, using a ‘C’-calling convention) is the Visual-Prolog-specific structure of a LIST, which in Visual Prolog has a different form than in all other languages. If you understand Assembly Language and intend to use this code for other (meta-programming) tasks, all you have to do is modify just a couple of lines in the code that follows. However, before you (even begin to) look at the Assembly Language Code, the following simple definitions in Visual Prolog (5.*) are a prerequisite for easier understanding:

GLOBAL DOMAINS
dom_iii = determ INTEGER (INTEGER,INTEGER,INTEGER)
 	-(i,i,i) language c % <-- example domain
GLOBAL PREDICATES
apply_func(DWORD,ListDomain) -(i,i) language c
% where arg-1 is a predicate-domain, such as "dom_iii"

After you compile the Assembly language code, you could create a simple “EasyWin” Visual Prolog project, with the following ines:

PREDICATES
 func2dword(dom_iii,DWORD) 
 % converts a predicate to a doubleword/address

 add3: dom_iii
CLAUSES
func2dword(FUNC,DW):- DW = cast(dword,FUNC).

add3(_X,_Y,_Z,Out):- Out = _X+_Y+_Z,
 	write("out = ",Out), nl, !
 	;
 	write("error!\n"), Out=-1, !.
GOAL
func2dword(add3,DW),
Out = apply_func(DW,[10,20,30]),
write("result = ",Out), nl, readchar(_).

%This program should produce "result = 60" (sum of [10,20,30]).

OK, so here is the Assembly language code:

; ==================== _apply_func.asm =====================
; Code for TASM 5 Assembler, command-line call for compilation:
; C:\TASM\BIN\TASM32.EXE /p /z /w2 /m2 /ml _apply_func.asm
IDEAL
P586
MODEL    flat
CODESEG
ALIGN 4
public _apply_func    ; (i,i)
PROC _apply_func near
ARG    func:dword, list:dword
LOCAL    fcnt:dword
ENTER 4,0
push    esi        ;
push    edi        ;
push    ebx        ;
push    ecx        ;
mov    ecx,[func]  ; function............ ARG 1
mov    esi,[list]  ; list................ ARG 2
xor    ebx,ebx     ; make EBX=0
mov    [fcnt],ebx  ; initialize local variable 'fcnt' to 0
lodsd              ; load the 1st list-element's "element-flag"
dec    al          ; decrement it, to check if it was a 1
jnz short @@x1     ; exit if not (i.e. if it's the list's end)
; ----------------- else...
@@L1:             ; loop to read the (Visual-Prolog-) arg-list
inc    ebx        ; increment ebx (counter for number_of_args)
lodsd             ; load next list-element (arg. of function)
push    eax       ; push it into the stack (for a function-call)
lodsd             ; load the pointer to next list-element in EAX
mov    esi,eax    ; now ESI = (pointer-to-) next list-element
lodsd             ; load element-flag of next list-element
dec    al         ; decrement it, to check if it was a 1
jz short @@L1     ; if so, not yet the list's end, so repeat!
; ================= else...
@@x1:
mov    [fcnt],ebx  ; store the number_of_args in local var. 'fcnt'
call   ecx         ; call the (external) function (given in ARG-1)
mov    ecx,[fcnt]  ; get the function's number of args from 'fcnt'
@@L2:
jcxz @@x2          ; if the called function had NO args, exit
; ------------------ else...
@@L3:              ; loop to POP function-args after the call
pop        edx     ; recover next argument from the stack
dec        ecx     ; decrement the remaining number_of_args
jnz short @@L3     ; if not zeroed, continue popping args...
; ------------------
@@x2:
pop        ecx     ;
pop        ebx     ;
pop        edi     ;
pop        esi     ;
LEAVE
ENDP _apply_func
end

NOTES:

  • A not-so-obvious advantage of this code is that any Prolog interpeters written on the basis of Visual Prolog’s “PIE engine” (such as G.I.S. Prolog) make extensive use of calls such as this, inside their inference engine; using Prolog-lists of arguments to be called by turning them into proper predicate calls of arity=N (where N is the size of the list). So, an Assembly language implementation of such a calling mechanism can speed up such an interpreter considerably, especially inside recursive calls or loops, which call other predicates repeatedly countless times…
  • Another not-so-obvious advantage is that -in this way- we managed to… trick Visual Prolog into doing “forbidden” predicate calls, such as PRED(arg1,arg2,….), where both the predicate’s functor and the arguments may appear as static data, stored in a Visual Prolog facts’ database.
  • Don’t ask me (yet) how to implement such tricks in Visual Prolog 6.* or 7.*; I still use the version 5.* compilers a lot, because of their speed, as well as robustness in foreign language calls.
Zemanta Pixie
Advertisements

October 14, 2007

DreamProver: A visual theorem prover for “Multiple Form Logic” (etc.) in LPA Win-Prolog 4.6

Chart showing the stages in the software relea...Image via Wikipedia

Visual DreamProver 1.0 is a new theorem-proving program, developed in LPA Win-Prolog 4.6, with multi-coloured graphics displays of (potentially unlimited) Logic expressions, theorem proofs and deductions in Multiple Form Logic, in the primary algebra of “Laws of Form“, in Boolean Algebra and in a variety of other logic systems (to a large extent used-defined). Here is an animated GIF slide-show of DreamProver’s visual display. It offers unlimited control of size, colour, shape and content for all Logic Expressions and all theorem proofs:

dreamprover430x.gif

(Click on this image for a better quality animated GIF, of size 450Kb)

Although DreamProver is still at the “alpha stage“, I decided to publish a preliminary first report about its features and capabilities, to a large extent already working, to a lesser extent requiring minor debugging and final extensions, before release. I am also doing this for the benefit (and amusement) of a friendly innovative company: “Logic Programming Associates Ltd”, where I worked for a short pleasant period of a few weeks, some years ago (in 2001). LPA are the creators of the LPA Win-Prolog compiler. I hope that LPA continues a long tradition of innovative success through the latest version of their compiler, which also has MIDI (music) programming capabilities (featured in a recent posting, here).

I am also… officially requesting, after the release of DreamProver (and the ensuing free promotion of LPA’s amazing compiler) a small… personal favour: -A legitimate free copy of their newest LPA Win-Prolog 4.7 compiler! 🙂 (as my license for using version 4.6 ends on the last day of 2007).

DreamProver is particularly suited for the display of so-called “Boundary Logic Systems” (first created by George Spencer Brown in “Laws of Form” and then extended by various people in various ways – including my own “Multiple Form Logic” system). However, its (almost unlimited) potential allows the display of many other logic systems, including Parse-Trees of used-defined grammars, since both the shapes and the data-structures they represent can be redefined “on the fly”. In the display shown above, only a small example of a logic expression is used, mainly to demonstrate graphics capabilities. However, if -for example- the Grammar of a subset of English is used, instead of a Logic Expression, the ensuing graphic display of coloured shapes resembles a tree which is symmetric with respect to a “horizon” line in the middle.

The data-structure for this unusual kind of tree-representation is relatively simple, straight-forward and documented (in the final release of DreamProver). It is separate from the internal Logic representation but related to it through specific user-defined rules: Both the “productions” and the “leaves” of such a grammar tree are user-defined in shape and content. The only difference between other kinds of systems and those built-in (as regards the current first version of DreamProver) is that the other systems do not include internal Proof Algorithms and automated deductions, and can only be fed from the results of such processes (through external third-party software). Before final release it is hoped that the input-expressions in other systems are expressed in standard XML, so as to make the software useful to almost any researcher or developer, in any topic that includes parsed tree-expressions. The ultimate goal is also to develop a kind of Universal DreamProver library, available under a professional license to developers for a small fee (that might help sustain this work and pay for the effort of future upgrades). However, the current version of DreamProver is likely to appear as Open Source in the near future. Keep in touch!

Zemanta Pixie

September 22, 2007

LPA Win-Prolog: A professional Prolog compiler with unique features

In early 2001, I had the pleasure of working closely together with a friendly bunch of people, the creators of LPA Win-Prolog, for a a period of a few months: This company, who made LPA Win-Prolog is “Logic Programming Associates“, a group of dedicated developers and computer scientists led by Brian Steel, who also happens to be a musician and an orchestra conductor. A long time ago (in the eighties) Brian Steel had caused quite a stir in the so-called “home computer” industry, by writing the first Prolog compiler that could run on a ZX Spectrum, a machine with only 48Kb of RAM and a Z80 8-bit processor. At that embryonic stage of the computer industry’s evolution, it was considered impossible to cram a working Prolog compiler in only so little RAM and in such a slow computer. However, Brian Steel was also an Assembly Language programmer (just like me -although long before my time). He still writes very efficient Assembly Language code (today for Intel Pentiums – 32-bit and 64-bit code) which empowers today’s LPA compiler with a tremendous speed, compared to its rivals. Brian also thought deeply about the best way to implement certain commonly needed operations (such as string search) and so he set out to improve the ISO-prolog-compatible LPA compiler with special and unique instructions that increase its speed and efficiency even more (e.g. the multi-faceted predicate “find/3“).

Well, I am still using LPA Win-Prolog, ever since that happy period of a few months I spent in the UK, back in 2001, as an employee of LPA Ltd. In fact, I was forced to return to Greece because of a bad accident (a broken tendon in a foot), otherwise I’d rather stay in the UK and work with LPA… forever! BTW, Brian Steel is also -like me- a winter swimmer, in the English sea (in Cornwall) making it even more apealling for me -at the time- to… follow his example. 🙂

The latest versions of LPA Prolog (version 4.6 is the one I use at the moment) are full of extra goodies, such as a coloured syntax editor, a nice dialog editor (for the visual design of menus, windows, dialog boxes, etc), and so on. (Not to mention several good extra packages, included in the compiler, such as Flex, Datamite, Proweb, Chimaira Agents, and so on; you can read all about them in LPA Prolog’s site, here).

My only complaint is that (at the moment) the LPA package does not include a Constraints programming extension, (such as CLP, CLP/fd, CHR, etc). However, I plan to adapt some open source code for such extensions and include it inside LPA Prolog, in the near future. Unless -of course- this innovative company has already embarked on a similar project, adding to their compiler Constraints handling extensions. Finally, the very latest (recently announced) next version of LPA Prolog includes something very special, which is useful to musically inclined programmers and hobbyists: A midi interface!

I was probably among those people who first proposed to Brian Steel -back in 2001- that a midi interface would prove to be very popular, as well as a way to expand LPA’s customer base even further. At the time (2001), most of their customers were academics, universities and serious professional people. Today (2007) my guess is that their clients begin to be also musically oriented hobbyists and computer-literate composers. I -for one- (as a composer and remixer) can’t wait to get my hands on this new version of their compiler, since it’s the best way to experiment with L-systems for computer music generation, Prolog-based grammars for parsing and analysing existing MIDI music pieces, and so on.

However, now that the MIDI music Logic Programming client-base of LPA Prolog is beginniing to grow, the issue of Constraints extensions can no longer be neglected. Some of the best work in musical Artificial Intelligence is already using Constraints programming methods.

In this blog, I hope to write quite often about programming projects and experiments with LPA Win-Prolog, including my own (public domain) source-code. In addition, you can browse some professional projects implemented with LPA Prolog in recent years (2001-2005), in my source-code and programming projects’ page.

Finally, there are some rather unusual web-pages I wrote a few years ago, with tips and free code to combine LPA Win-Prolog, with… one of its rivals (PDC/Visual Prolog). At the time, it became evident that it was perfectly possible to combine the best features of both these professional compilers, so the title of the main web-page about this work was “A tale of Two Prologs“.

Create a free website or blog at WordPress.com.