FIVE 1.0
Index:
a.. Overview of Five 1.0.
b.. The Clipper virtual Machine (CVM).
c.. The compiler.
d.. The Run Time Library.
a.. OVERVIEW OF FIVE 1.0
Five 1.0 is a 32 bit Clipper-compatible compiler. It is divided in two
main parts: The compiler itself that generates OBJ files from PRG files and
the libraries to be linked to build the final application (EXE file).
The first part, the compiler, reads your Clipper code, and generates a
file with the PCode instructions necessary for being interpreted by the
Clipper Virtual Machine in order to execute your program. In order to do so,
the compiler reads each instruction and generates for it one or more PCode
instructions.
The compiler has been written using a lexical analyzer (Lex: FLEX
www.ecs.soton.ac.uk/support/gnu/flex ) and a syntax parser (Yacc: Berkeley
University BYACC
htttp://www.first.gmd.de/cogent/catalog/lexparse.html )
which produce a lexer and a parser, respectively. Both tools, Flex and Byacc
may be free downloaded from Internet and they contain full source code. We
strongly recommend the reading of the book lex & yacc from By John Levine,
Tony Mason & Doug Brown published by Published by O'Reilly & Associates and
associates. You may order this book directly from Internet. This book will
teach you in deep about how to use these two powerful tools and this will
help you to understand how we have used them to write Five 1.0.
The second part, the Clipper Virtual Machine (CVM), is included in the
program as a Run Time Library, called Five.lib. Thus, all your Clipper
executable programs will include portions of Five.lib inside them. The CVM
uses the same technical principles as the Java Virtual machine. We recommend
the reading of Java Virtual Machine Published by O'Reilly & Associates
www.ora.com to get a deep understanding of this technology. The CVM uses
certain subsystems that are vital components in the final application. We
are going to analyze in deep these components to get a perfect understanding
of the CVM.
b.. THE CLIPPER VIRTUAL MACHINE
a.. Overview of the Clipper Virtual Machine (CVM)
The CVM is formed by the main execution loop and several subsystems, each of
which could be theoretically replaced, supposing that you respect the
interface of each subsystem.
The main execution loop is defined in the C function named CVM (the
equivalent to Plankton in the CA-Clipper compiler), which receives two
parameters: the pcode instructions to execute and the local symbol table (a
portion of the static symbol table) used by that pcode:
CVM( pcode, local symbols )
The CVM may invoke the CVM (itself) again. This let the Clipper language to
access Clipper functions and methods and external C language functions again
and again. The CVM organizes these multiple accesses in a ordered and full
controlled way and implements services to access these multiple execution
levels (ProcName(), ProcLine(), debugging, and stack variables access).
The CVM subsystems are continuously used by the main execution loop. Lets
review these CVM subsystems:
a.. The startup: Controls the initialization of the different CVM
subsystems and it is invoked at the beginning of the application. It also
controls the exiting of the application.
b.. The stack: The CVM does not use the stack of the computer
directly, it uses instead its own stack for manipulating values (parameters,
returned values, and symbols) as a hardware stack does.
c.. The static symbol table: Created by the compiler at compile time
and grouped by the linker, this subsystem is responsible for an immediate
access to functions location and it is highly related to the dynamic symbol
table at runtime. It contains many duplicated symbols that will be optimized
by the dynamic symbol table.
d.. The dynamic symbol table: Dynamically generated from the startup
subsystem at the beginning of the application. It organizes in an efficient
way the static symbol table creating an alphabetical index that allows a
dicotomic search of symbols. This subsystem is responsible for quick access
to symbols (functions, variables, fields and workareas aliases).
e.. The static and public variables: Responsible for storing public
and static variables. The CVM uses two different Clipper arrays for this
purpose.
f.. The memory: Responsible for allocating, reallocating, locking,
unlocking and freeing memory. It also organizes garbage collection. It
directly connects to the Windows API memory management functions. This
subsystem is one of those to be easily modified to port Five 1.0 to another
computer platform.
g.. The extend system: Defines the interface (_parc(), ...,
_retc() ) from low level (C language) to high level (Clipper language). This
subsystem is responsible for connecting in a proper way C language functions
to the entire application.
h.. Multidimensional arrays:This subsystem allows the creation of
arrays, and the services to manipulate these arrays in all ways. The arrays
are extensively used by the Clipper language and also they are the
foundation of the Objects (Objects are just arrays related to a specific
Class). These arrays are also used as a storage system by several subsystems
(static and public variables).
i.. The Objects engine:Responsible for the creation of Classes and
Objects. It also defines the way to access a specific Class method to be
invoked by the CVM and provides all kind of Classes information that may be
requested at runtime.
j.. The macro subsystem: it implements a reduced compiler that may
be used at runtime to generate pcode to be used by the application. In fact
it is a portion of the yacc Five 1.0 specifications.
k.. The workareas subsystem: Responsible for databases management.
It defines the locations where the used workareas will be stored and
provides all the functions to access those workareas. It also implements the
interface to the replaceable database drivers.
In the next chapters we are going to review in deep these subsystems to
fully understand each of them.