Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!jato!herron.uucp!jbrown
From: jbrown@herron.uucp (Jordan Brown)
Newsgroups: comp.databases
Subject: Re: FORCE
Message-ID: <326@herron.uucp>
Date: 11 Apr 90 10:15:14 GMT
References: <23925@usc.edu>
Reply-To: jbrown@jato.jpl.nasa.gov
Lines: 79

In article <23925@usc.edu>, atieu@skat.usc.edu (Anthony Tieu) writes:
> Does Clipper produces native code or pseudo code which is executed
> by a runtime interpreter?------

My understanding is that it produces pseudocode.  However, the pseudocode
is bundled with the interpreter into a single .EXE, so it's transparent
to the programmer and the user.

> I have always that Clipper produces exe files.

Yes it does.


I don't consider it to be a failing that it uses pseudocode.  I think
FORCE is the only dBASE-language product that produces native code,
or claims to.

Most dBASE statements *can't* be turned into native code, at least not
without all kinds of high-tech compiler technology.  Even a simple statement
like
	c = a+b
can't.  Why not?

1)  What types are A and B?  If they're numbers, then you need to do an add.
If they're strings, a concatenate.  If they're a date and a number, you
might have to do a different kind of add depending on how dates are
represented.  (For that matter, they may be different types the next time
through...)

2a)  If you're using BCD for numbers (as Vulcan and, I believe, dBASE IV do)
you're going to have to do a subroutine call anyway; who cares whether the
subroutine call is done directly or out of a pseudocode interpreter's
jump table?

2b)  If they're strings, you have to do non-trivial memory handling to
build up the result, and are going to be making several subroutine calls.
See 2a.


A native code implementation can certainly be done; it just has to do
most things using subroutine calls.  The question then becomes how to make
the tradeoffs...

- native code is probably faster.
- native code may well be bigger.  (note that for macros and dBASE indexes
you still need a full expression interpreter...)
- native code works only on one processor type.
- it's harder to implement a virtual memory scheme when using native code.
- native code *may* make it easier to integrate routines in other languages.


The dBASE language is just not well suited to compilation.

An aside, vaguely related...

Alastair, here's a thought problem for you.  Consider the following sequence
and how it works internally.  Does it produce the same result in dBASE III
and IV?  (I know the Vulcan interpreter and compiler will get different
answers and I think that Clipper will be different from dBASE III...
I just checked FoxBase and it doesn't match dBASE III...)

use somedbf		&& assume it has a field "name"
myname="brown"
set filter to name=myname
private myname
myname="dallas"
list

Now, will you get "brown" records, or "dallas" records?

I suspect that III (and the Vulcan interpreter) will give "brown" records,
and IV, Fox, Clipper, and the Vulcan compiler will give "dallas" records.

I can't see any reasonable way to get the compiled version to dup the
behavior of the interpreted version.  Sigh.  Another example of the
inherent non-compilability of the language.
-- 
Jordan Brown
jbrown@jato.jpl.nasa.gov