PHP Interpreter - co-project - Loughborough University

nutritionistcornInternet και Εφαρμογές Web

14 Δεκ 2013 (πριν από 3 χρόνια και 7 μήνες)

112 εμφανίσεις

i


ACKNOWLEDGEMENTS

I
would like to
thank all those who have contributed in any way
, shape or form

to the
completion of this report. Thank you to Dr R
oger
. G. Stone for his guidance and to Jade
Skelton for her help and support.



ii


ABSTRACT

In semester one fir
st year Computer Science students at Loughborough University learn how
to program using client
-
side technologies including
JavaScript

and
the
Document Object
Model
.

Students can
experiment with

scripts they have written using a web
-
based integrated
development environment. The
environment allows them to easily refer to tutorials and
to
easily modify example code

to learn new techniques.
In

semester two students progress to
server
-
side programming and learn the
PHP

scripting language.

However, no tool exists for
them to ea
sily test their code without
undergoing the arduous process of
uploading it to

a
web
server before the script can be executed.
This project is concerned with the design and
implementation of a web
-
based PHP interpreter to provide a development environment where
students can learn, program and test PHP scripts.

The chosen i
mplementation method is to
use the

pre
-
written use
r interface library
Ext JS

to provide the required
functionality
. The
required
lexical
analyser and parser
for the PHP engine
and generated from script files using
the
two GNU/Linux programs
Flex and Bison. The generated lexical analyser and parser are
then combined with a

custom programmed virtual machine similar to that of the one used by
programming languages such as
JavaScript
. The
user interface

and
the
PHP
interpreter

are
connected using a server
-
side interface that handles passing data between the two entities.
In
co
nclusion to the project it was decided that
a modified version of the official PHP engine
sh
ould have been used because of time restraints. However, the custom PHP engine that was
developed was successful as far as the
feature set that was implemented in the
time

available
.


iii


CONTENTS


Acknowledgements

................................
................................
................................
................................

i

Abstract

................................
................................
................................
................................
..................

ii

List of Figures

................................
................................
................................
................................
........

v

List of Tables

................................
................................
................................
................................
........

vi

List of App
endices

................................
................................
................................
...............................

vii


1. Introduction

................................
................................
................................
................................
.......

1

1.1 Background Information

................................
................................
................................
..

1

1.2 Aims

................................
................................
................................
................................
.

1

1.3 Objectives

................................
................................
................................
........................

2

1.4 Previous Work

................................
................................
................................
.................

2

2. System

Specification

................................
................................
................................
.........................

4

3. Design and Implementation

................................
................................
................................
.............

6

3.1 Problem Approach

................................
................................
................................
...........

6

3.2 System Design

................................
................................
................................
.................

6

3.3 User Interface (Front
-
end)

................................
................................
...............................

7

3.3.1 Comparison of User Interface Framework Libraries

................................
................

8

3.3.2 Comparison of Syntax Highlighting Engines

................................
...........................

8

3.3.3

User Interface Design and Implementation

................................
..............................

9

3.4 PHP Engine (Back
-
end)

................................
................................
................................
.

11

3.4.1 A Comparison of Different PHP Engine Solutions
................................
.................

11

3.4.2 Minimizing the Disadvantages of Using a Custom PHP Engine

............................

12

3.4.3 Backend Structure

................................
................................
................................
...

12

3.4.4 Lexical Analyser

................................
................................
................................
.....

13

3.4.5 Parser
................................
................................
................................
.......................

15

3.4.6 Virtual Machine (VM)

................................
................................
............................

19

3.5 Restricting Language Co
nstructs

................................
................................
...................

23

iv


3.6 Front
-
end / Back
-
end Interface

................................
................................
......................

24

4. Testing

................................
................................
................................
................................
..............

25

4.1 Test Plan

................................
................................
................................
........................

25

4.2 Test Cases and Results

................................
................................
................................
...

25

5. Evaluation of Test Results

................................
................................
................................
..............

26

6. Conclusion

................................
................................
................................
................................
.......

27

7. Recommendations and Further Work

................................
................................
..........................

28

7.1 Project Limitations

................................
................................
................................
.........

28

7.2 Further Work

................................
................................
................................
..................

28

8. References

................................
................................
................................
................................
........

30

9. Appendices

................................
................................
................................
................................
.......

32

A. JavaScript Tester

................................
................................
................................
.............

32

B. System Design

................................
................................
................................
.................

33

C. User Interface Screenshots

................................
................................
..............................

34

D. System Design and Flowchart

................................
................................
.........................

36

E. Backus
-
Naur Form PHP Grammar

................................
................................
..................

37

F. Virtual Machine In
struction Set

................................
................................
.......................

42

G. Code Generation Templates for Language Constructs

................................
...................

44

H. Test Cases and Results

................................
................................
................................
....

45

I. Browser Test Screenshots

................................
................................
................................
.

49


v


LIST OF FIGURES

Figure 1


The grammatical

expansion of an example „while‟ statement.

..............................

18

Figure 2


An example of a stack frame.

................................
................................
.................

20

Figure 3


An example of a run
-
time stack with two stack frames.

................................
.........

21

Figure 4


The admin
istration utility for restricting language constructs.

...............................

23

Figure 5


The existing JavaScript Tester tool as used by students in Semester 1.

.................

32

Figure 6



The initial outline of the structure of the project solution.

................................
.....

33

Figure 7


The initial layout with content areas defined.

................................
.........................

34

Figure 8


Content areas filled with tabs and titles applied.

................................
....................

34

Figure 9


The user interface with a toolbar and error grid controls added.

............................

35

Figure 10


The finished user interface with all content areas containing sample data.

..........

35

Figure 11


The structure of the back
-
end including the supporting virtual machine classes.

36

Figure 12


A flow diagram to demonstrate the path of execution through the interpreter.

....

36

Figure 13


Firefox 1.5 on
Windows 2000

................................
................................
..............

49

Figure 14


Firefox 2.0.0.4 on Windows 2000

................................
................................
........

49

Figure 15


Firefox 2.0.0.12 on Ubuntu 7.10

................................
................................
..........

50

Figure 16


Internet Explorer 6 on Windows 2000

................................
................................
.

50

Figure 17


Opera 9.26 on Windows XP

................................
................................
.................

51

Figure 18


Opera 9.50 on Ubuntu 7.1

................................
................................
....................

51

vi


LIST OF TABLES

Table 1


The advantages and disadvantages of the JavaScript Tester tool.

.............................

3

Table 2


A comparison of the features that each user interface library has.

............................

8

Table 3


A comparison of the features that each code input area has.

................................
.....

9

Table

4


The advantages and disadvantages of using a custom PHP engine in comparison to
using the Zend PHP engine

................................
................................
................................
......

12

Table 5


The virtual machine instruction set.

................................
................................
.........

42

Table 6



The virtual machine opcode set for operation, memory and array instructions.

......

43

Table 7


Test cases, the expected result and t
he actual result for the user interface.

.............

45

Table 8


Test cases, the expected results and the actual results for the PHP engine.

.............

48



vii


LIST OF APPENDICES

A. JavaScript Tester

................................
................................
................................
.................

32

B. System Design

................................
................................
................................
.....................

33

C. User Interface Screenshots

................................
................................
................................
..

34

D. System Design and Fl
owchart

................................
................................
.............................

36

E. Backus
-
Naur Form PHP Grammar

................................
................................
......................

37

F. Virtual Machine Instruction Set

................................
................................
...........................

42

G. Code Generation
Templates for Language Constructs

................................
.......................

44

H. Test Cases and Results

................................
................................
................................
........

45

I. Browser Test Screenshots

................................
................................
................................
.....

49



1


1
.
INTRODUCTION

1
.1 Background Information

PHP is a recursive
initialism
acronym that stands for
PHP Hypertext Pre
-
processor
. „PHP is
a widely
-
used general
-
purpose scripting la
nguage that is especially suited for
web
development

and can be embedded into
HTML
. It generally runs on a
web server
, taking PHP
code as its input and creating
web pages

as output.‟
1

PHP was first developed by Rasmus
Lerdorf in 1994 and was released publ
icly in June 1995 and has since then been rewritten and
developed many times over to produce the current version (5.2.5 as of writing).

First year
computer science
students at Loughborough University study client
-
side
programming as part of their
„P
rogramm
ing for the World Wide Web


module. In this
first
semester
module they learn how to modify and interact with web pages using client
-
side
JavaScript

and the
Document Object Model
.

At the heart of the teaching material for the
module is an online too
l called

JavaScript

Tester

.

This tool provides a
n environment
whereby the

students
can

learn
, write and
test their own
JavaScript

code
whilst being able to

directly reference tutorials and learning material written by the lecturer.

In the second semeste
r the

students

learn server
-
side programming using the PHP
scripting
language.
This is an important skill for the students, as not only is PHP similar to other
programming languages (and thus aids learning of those) but it is currently used on ‟20
million

websites and 1 million servers‟
2

globally.
Students currently use the
provided

lecture
material (PowerPoint presentations and Adobe Acrobat files)
for learning/reference

and t
hey
can test their code by using
web hosting
provided by
Department
.

This projec
t
is involved with the
design and implementation of a web
-
based
PHP learning aid
similar to that of the one used
during

the first semester module.

1
.2 Aims

The aim of the project is to develop a learning aid to be used by first year students who are
being
taught to program in PHP.
The project
should
consist of a single web

page that serves
the purpose
of
allowing the user to

input PHP code for interpretation and to display the
produced output. At the core of the project will be a custom
ised

PHP interprete
r with the task
of producing sensible, user friendly messages on how to correct any invalid
-
code.

The user



1

Wikipedia.
PHP
, <
http://en.wikipedia.org/wiki/PHP
>, 18/03/2008, [accessed 20/03/2008].

2

Wikipedia.
PHP
, <
http://en.wikipedia.org/wiki/P
HP
>, 18/03/2008, [accessed 20/03/2008].


2


should be able to restrict the grammar of the PHP language so that only certain programming
statements can be used (i.e. the ability to use for
-
loops

can be removed).

1
.3 Objectives

The objectives for the project are outlined below:



Design and implement a suitable user interface based u
pon the evaluation of different

designs and technologies

involved
.




Design and implement a

lexical analyser

and parser

for the PHP programming
language using either LEX

and
YACC or FLEX

and
BISON.

This objective
can be
broken down into
t
w
o sub
-
objectives:



To establish the grammar to be used for the PHP interpreter.
Only a subset of
the full PHP language grammar needs to

be implemented. A
dvanced features
such as classes and function/operator overloading

are not required because
they are not taught as part of the course
.



To identify code generation templates for certain grammar statements. These
will need to be combined

with the BNF grammar used at the parser stage of
the interpreter to allow for variable definitions, expression evaluation,
conditionals and function calls.



All of the relevant tokens for the PHP language need to be identified and if
necessary the correct
regular expressions to match them need to be created.




De
sign and implement a
n interpreter capable of processing PHP captured through the
user interface and processing it using the lexical analyser and parser to produce the
required output.

1.4 Previous Wo
rk

In semester one first year students use a web
-
based tool called „JavaScript Tester‟ written by
the module lecturer Dr Roger G. Stone. A good basis for this project would be to build upon
the advantages demonstrated by the tool and to develop solutions
to eliminate the
disadvantages; therefore a comparison of the advantages and disadvantages are shown in

Table
1
.

A screenshot of the tool is shown in

Figure
5
, Appendix A.




3


Advantages

Disadvantages

The full Ja
vaScript language
is available to
students
, the only limitation being that of the
implementation provided by the browser that
the user uses to view the website in.

The text input area is a fixed size and does
not resize when the browser is resized. It
req
uires the user to click buttons to make the
area bigger and smaller.

Teaching material is displayed alongside the
code input area allowing the students to
easily refer to lecture notes.

The user has to manually copy and paste code
from the teaching materi
al into the code input
area.

The ability to save and load user scripts to
and from a database so they can be edited at a
later date.

No error messages are reported if the code
contains syntax errors.

Table
1



The advantages and d
isadvantages of the JavaScript Tester tool.



4


2
.
SYSTEM

SPECIFICATION




The web
-
based user interface
should function like a standalone

integrated
development environment (IDE)
3
. To allow the webpage to function like an IDE, it
should make use of an appropria
te technology such as
HTML
frames

or
Asynchronous JavaScript and XML (AJAX)

to give the impression that the webpage
never refreshes.




The webpage should feature an area for the user to
enter

PHP code

as well as areas to
display
any error messages or outp
ut
of interpreted code
.





The user interface should consist of an area displaying learning resources for the user
to easily read tutorials

and lecture material

on how to program in PHP. It should be
possible to copy code examples from the learning resourc
es to the input area to allow
users to modify them.





The user interface should be capable of
automatically
highlighting PHP syntax to
make it more easily read.





To develop a server
-
side
interface

that will accept the user‟s PHP code sent to it from
the c
lient
-
side webpage and invoke the PHP interpreter. The
interface
should pass
the PHP code to the interpreter and any output from the interpreter should be passed
back to the
client
-
side webpage
so that the results can be processed and acted upon
according
ly.





A
ll basics

language

features

such as variables, functions, loops and conditional
statements should be implemented.
It should be possible to restrict the language
grammar so that

only a subset of the implemented grammar is available to the user at
a
time. The grammar should be dictated in
Backus
-
Naur Form (
BNF
)
.






3

Wikipedia,
IDE
. <
http://en.wikipedia.org/wiki/Integrated_development_environment
>, 24/03/2008,
[accessed 01/04/2008].


5




Any errors encountered during the analysi
s

or parsing must be reported to the client
along with a suitable message possibly detailing how to
remedy
the problem
. A
suitable error message is

“Line 30: Missing required semi
-
colon.”

When an error is
reported to the user, they should easily be able to
jump to

the specific line of code
giving rise to the error.





The system
should be designed such that it can run on either a central server as we
ll
as it being possible for users to download it and run it on their home computers.





Once a PHP script has been successfully interpreted the output should be displayed to
the user in a form that is also capable of displaying HTML tags as they would appea
r
in an internet browser.



6


3
.
DESIGN

AND IMPLEMENTATION

3
.1 Problem Approach

The approach
that will be taken

in
developing a solution to
the problem is to develop each of
the system

s sub
-
components at the same time. This approach
will allow a basic worki
ng
version of the system to be implemented quickly
. The reason behind taking this approach is
to prevent the situation whereby an unforeseen problem occurs during development of one
sub
-
component which then has a big delay on the overall project. A lengt
hy delay could lead
to the project overrunning the final deadline and as a consequence the system would not be
finished. Once a basic working version is implemented and the basic structure of the solution
is outlined, features can be added to
fulfil

all o
f the requirements.

3
.2 System Design

The system will be split into two main sub
-
components, the front
-
end user interface and the
back
-
end PHP engine and each of these will then be further broken down. This is shown in

Figure
6
,
Appe
ndix B
.

The user inte
rface will be a server
-
side web
page designed to mimic other integrated
development environments (IDEs) such as Microsoft Visual Studio and Macromedia
Dreamweaver. It is likely that students will have used these applications in other
modules
and will already be familiar with their layout. This will hopefully allow the students to
quickly become familiar with the user interface
;

and
to
allow them to concentrate on using the
application to learn PHP instead of spending their time learni
ng how to use the application.
One consideration is that the
learning aid should also be able to run completely
client
-
side;
that is, without the need to be running a web server.

There are a couple of possible solutions for the
backend
PHP engine. The

official PHP
engine is open source software and so

it

could be modified to meet the needs of the project.
A custom PHP engine could be written from scratch as an alternative, having the required
functionality built in from the base upwards.




7


3
.3
User I
n
terface

(Front
-
end)

The user interface will be constructed using an existing library of user interface components.
This will provide a number of benefits whilst still allowing the web page to be custom
designed to suit the requirements of the project.

T
he use of an existing user interface library will bring about several major advantages over
developing the user interface from scratch. The development time will be significantly
reduced, allowing more time to work on the PHP engine and getting the overal
l system
working rather than debugging complex JavaScript and Document Object Model (DOM) code
to resolve bugs. Existing libraries are likely to be cross
-
browser compatible which fulfils the
requirement that the web page can be accessed from the range of
operating systems and web
browsers available to students in the laboratories. This task in itself could take several
months of development and so the advantages have an immediate effect on the project.

Several requirements for the user interface are speci
fically related to the input area for PHP
code. The use of an existing syntax highlighting engine will allow the advantages discussed
above to be applied here. However, it must be pointed out that it

is likely a certain amount of
glue

will have to be app
lied to allow the code input component to interface with the rest of the
user interface.

Technologies like Microsoft ASP.NET cannot be used in this situation because they cannot be
run on a computer without a web server. After researching possible user in
terfaces through
various search engines, three similar user interfaces that can be run client
-
side are DHTML
Goodies
4
, Yahoo! User Interface
5

(YUI) and Ext JS
6
. These frameworks use
only client
-
side
dynamic HTML (DHTML) and JavaScript
technology
to achiev
e the functionality they
provide. These rules must also apply to the syntax highlighting engine that will be used.
Further research took place to find possible syntax highlighting engines. The two that were
discovered through searching that
will be comp
ared
based on their functionality
are
CodePress
7

and EditArea
8
.




4

D
HTML Suite. <
http://www.dhtmlgoodies.com/index.html?page=dhtml
-
suite
>, 2007, [accessed
Octobe
r 2007].

5

Yahoo.
User Interface Library
, <http://developer.yahoo.com/yui>, 2007, [accessed
October 2007
].

6

Ext JS. <http://www.extjs.com>, 4/12/2007, [accessed
October 2007
].

7

CodePress. <http://www.codepress.org>, 26/09/2007, [accessed October 2007].

8

Cristophe Dolivet.
EditArea
, <
h
ttp://www.cdolivet.net/editarea>, 10/10/2007, [accessed October
2007].


8


3
.3.1 Comparison of User Interface Framework Libraries

Table
2

shows a comparison between the possible user interface frameworks and whether
they have the ability to mee
t the requirements set out.

Feature Required

YUI

Ext JS

DHTML Suite

Resize
-
able content areas.

Yes

Yes

Yes

Tabular structures for the display of error messages.

Yes

Yes

Yes

The ability to load web pages into content areas.

Yes

Yes

Yes

The ability to ta
b content areas.

Yes

Yes

Yes

Menu / toolbars for placing option selections.

Yes

Yes

Yes

Line numbering.

Yes

Yes

Yes

Load and save files from disk.

No

Extension

No

Built
-
in AJAX connection engine.

Yes

Yes

No

Table
2



A comparis
on of the features

that

each user interface library
has
.

In conclusion, the table shows that all of the libraries have the ability to meet the requirements
except for the syntax highlighting text editor. However, Ext JS has the ability to add this via
an
extension. There are also other factors that must be taken into consideration other than the
meeting the requirements set out above. For example, YUI and Ext JS have much bigger
developer bases than DHTML Suite; this could be an advantage when problems a
re
encountered in developing the solution. Secondly, Yahoo! UI and Ext JS have extensive
examples, tutorials and developer forums. If the project was to be expanded on at a later date
to add further features it is likely that these frameworks will contai
n tools to aid in adding the
features. For these reasons the user interface framework that will be used for the project is
Ext JS.

3
.3.2 Comparison of
Syntax Highlighting Engines

Table
3

shows a comparison between the possible syntax

highlighting engines and whether
they have the ability to meet the requirements set out.
The
shaded

lines show features that are
required by the syntax highlighter and the other lines show features that would be nice to
have, and are found in similar IDE
s.






9


Feature Required

CodePress

EditArea

PHP syntax highlighting.

Yes

Yes

Dual HTML and PHP syntax highlighting.

Yes

No

Go
-
to line jumping.

No

Yes

Automatic code completion.

Yes

No

Line numbering.

Yes

Yes

Interfaces with user interface framework li
braries.

Ext JS

None

Load and save files from disk.

No

Yes

Table
3



A comparison of the features
that
each code input area
has
.

It can be seen that CodePress

has more features on the whole.


One of the main advantages of
CodePres
s is that it has the ability to integrate with the chosen user interface framework (Ext
JS) through an extension.
H
owever
,

it is missing one of the key requirements, the ability to
jump to a certain line of text within the editor.
The syntax highlighting

engine that will
initially be used for the project is EditArea because it

meets the two main requirements „out
of the box‟. However, if time allows, this may be swapped for CodePress because of the
bigger feature set that it implements. This depends on
how easily the „go
-
to line‟ feature can
be implemented.

3
.3.3 User Interface Design and Implementation

This section discusses how the user interface library was used to design and create a user
interface that met the requirements of the project. Although
the user interface components are
from

the pre
-
written library Ext JS

the code to put the components together in the required
way
has to be custom written
.

The design in
Figure
7
,
Appendix C

shows the initial concept of the user inter
face. The user
interface has three main content areas that will allow for the following functionality (content
areas A to C respectively):



A text input area where the user can enter PHP code
and view the generated
output
.




The display of l
earning resource
s alongside the users PHP code.



The display of i
nterpretation errors
and/or

interpreter messages.

Each of the content areas can be resized by dragging the splitter bar similar to most
standard
desktop applications.

The user interface in
Figure
8
, Appendix C shows
the
content areas with
tabbed panels
applied to
furthe
r divide up the content areas.
The
Learning Resources

content area is a
collapsible panel that allows the user to quickly and easily hide the resources if they do not

10


wish

to view them. The source code tab is where the user will enter the PHP code and the
output
tab
is where the resultant web page will appear if the script was successfully
processed.

Figure
9
, Appendix C

shows the user interface wit
h several Ext JS components implemented
to add additional functionality.

The toolbar buttons and drop
-
down box
have been

implemented along with adding an Ext JS Grid component to the error tab for the display of
error messages.
The toolbar has two button
s, the first of which starts a new script and the
second of which posts a PHP script to the server for processing. The drop
-
down box is used
to select which week the student is currently studying in (to restrict language constructs from
being used).
The
content of the l
earning resources

area is an
inline frame
9

HTML
construct
that allows external web pages to be displayed within the content area. This means that a
collection of resources can be created and modified by the module tutor at any time without

having to modify the user interface at all.
A

logo has also been added to the spac
e at the top
of the interface.

Figure
10
, Appendix C

shows the user interface with the syntax highlighting text editor
implemented and sample error me
ssages and learning resources.

The EditArea component is
added to the document by including a series of JavaScript files and
a
cascading style sheet
into the main page and then adding a
textarea
10

HTML construct with an appropriately named
style sheet clas
s name. However, the EditArea control was modified because it didn‟t match
the colour scheme of the rest of the user interface and also displayed its own toolbar which
was not required. This involved modifying the cascading style sheet to adjust the colo
urs and
then editing the JavaScript to remove the code that displayed the toolbar.






9

W3Schools.
HTML IFRAME Tag
, <
http://www.w3schools.com/tags/tag_iframe.asp
>, [accessed
December 2007].

10

W3Schools.
HTML TEXTAREA Tag
, <
http://www.w3sch
ools.com/tags/tag_textarea.asp
>, [accessed
December 2007].


11


3
.4 PHP Engine (Back
-
end)

The back
-
end engine is where the majority of work
exists

within the project. The main
requirement specifically for the back
-
end is the ability t
o restrict the language grammar so
that only certain language constructs may be used. There are two main ways to achieve this.
The first of which is to modify the existing official PHP engine

created by a company

called
Zend
11
, to add the required functio
nality. The second of which is to build a new PHP engine
from scratch with the required functionality built in from the start. This is the approach that
will be used in the project
because of personal choice and

a keen interest in the topic area.

3
.4.1
A

Comparison of Different PHP Engine Solutions

The advantages and disadvantages of using a

custom PHP engine

designed and written from
the ground up specifically for this project
in comparison to using
a modified

version of the
Zend PHP

engine are discussed

in
Table
4
.

Custom PHP Engine

Zend

PHP Engine

Advantages

Disadvantages

The engine can be designed and built
from the ground up with the required
functionality built
-
in. This could lead to a
better solution overall because the

core
functionality of restrict
-
able

grammar that
needs to be applied is part of the original
design, not an afterthought.

The code will have to be heavily modified to
achieve the required functionality. This will
involve spending a large amount of time learnin
g
how the engine works and then making sure the
appropriate modifications are made.

The engine will only have the
functionality that is actually needed. For
instance, function calls such as
exec

that
can execute remote commands will not
exist and so cann
ot pose an issue with
malicious users.

This functionality will either have to be removed
or hidden from the user by removing the
interfaces to it. This will add to the amount of
work

required
.

If the engine is built from the start as a
standalone applica
tion as opposed to a
web server extension then it is likely it
will be able to run on the University
server which has restricted privileges in
place
.

Zend is a web server extension, not a standalone
application. This means that it would need to be
modifie
d
into a standalone

application as it is
likely that
a custom server extension cannot be
installed on a University web server
.




11

Zend.
PHP Development & Production Software
, <
http://www.zend.com
>, [accessed October 2007].


12


Disadvantages

Advantages

Small grammatical errors may be made,
or certain grammar not implemented
properly that causes PHP scri
pts to not
execute properly. Certain grammatical
combinations in scripts may lead to a
series of operations that does not work as
expected.

The grammar structure that is implemented is the
same one that will be in real
-
world PHP
situations. It is importan
t that a teaching aid is
as close to real
-
world as possible to be as greater
use to the student as possible.

The custom engine may not be cross
-
operating system compatible.

The Zend engine is compatible with a range of
operating

systems and web server sof
tware

out
of the box.

The code may contain bugs such as
memory leaks and improper functionality

that could pose a stability risk to
University servers
.

The PHP engine as it is known today has been in
existence since 1999 and has since undergone
vigorous r
ounds of release candidate and beta
testing and as a result the codebase is very stable
and bug free.

Table
4



The advantages and disadvantages of using a custom PHP engine in comparison to using the
Zend PHP engine

3
.4.2 Minimizi
ng the Disadvantages of Using a Custom PHP Engine

It can be seen that there are several disadvantages to using a custom PHP engine. However, if
certain steps are taken then the effect of the disadvantages can be reduced

if not removed
altogether:



The offi
cial grammar should be used from the official source code. This will make
sure that syntax that is valid in real
-
world PHP scripts is also valid in the custom
engine. This will be the only code taken from the official engine; the rest of the
engine will
be developed from the ground up.



The engine will be

written in C++ and

therefore can be compiled to run on both
GNU/Linux and Microsoft Windows
.

T
hese are the two operating systems that the
engine will need to run on depending on the usage.



The engine will

undergo strict testing by using programming examples taken from the
official PHP website. If the engine can successfully interpret the examples then it
can
be

assumed to be
working correctly.

3
.
4
.
3

Backend Structure

The backend of the PHP Engine
is shown

in
Figure
11
, Appendix D

to contain two main
functional areas, the
lexical analyser

and the
parser
.
The

lexical analyser
is shown to accept


13


PHP code as its input and
to generate tokens which are
then

input
ted to the

p
arser which
in
turn

produces the required XHTML output
(
that is
,

the processed PHP script
)
. In reality the
backend
also
requires a collection of

interrelated

supporting structures and classes
collectively
known as a
process
virtual machine
; t
hese

are
also
shown
Figure
11
, Appendix D
.

„A process
virtual machine‟s purpose
is to provide a
platform
-
independent programming environment
that abstracts away details of the underlying hardware or operating system, and allows a
program to execute in the same
way on any platform.‟
12

This means that the supporting
classes act as a virtual computer by being able to execute virtual instructions on any physical
computer. This is as long as the physical computer (the hardware and operating system
running on it) is
capable of executing the code that the virtual machine is written in.

The interaction between the lexical analyser, parser and supporting classes can be seen in
Figure
12
, Appendix D

which displays a flow diagram of the interpretation

of a PHP script.

The flow boxes in
Figure
12

are coloured appropriately to show their relation to the functional
boxes in
Figure
11
.

3
.
4
.
4

Lexical Analyser

The lexical analyser is a
collection of functions

gene
rated using a GNU
/
Linux utility called
F
lex
13

(The Fast Lexical Analyser).
The job of the lexical analyser is to convert the inputted
PHP code into
tokens

that the parser can then use to work out
which

grammatical statements
the input is made up of
.
The l
exical analyser is generated fr
om a script file that Flex uses to
construct a collection of functions that instructs the lexical analyser on

what token
s

to report
for a given input
. The script file can either use literal text or regular expressions to mat
ch
input. For example
“else”

can be used to match the word
else

on the input stream. The
following regular expression is used to identify variable identifiers in the PHP language and
to specify
that they cannot begin with a number and can only contain al
phanumeric
characters
:




[a
-
zA
-
Z_
\
x7f
-
\
xff][a
-
zA
-
Z0
-
9_
\
x7f
-
\
xff]*

The script file also contains a list of token definitions that specify a unique numerical
identifier for each token type. For example, the following
#
define

statements are fo
r variable
iden
tifiers and the
keyword
if

respectively.


#define T_STRING_VARNAME 298


#define T_IF 291




12

Wikipedia.
Virtual
Machine
, <
http
://en.wikipedia.org/wiki/Virtual_machine
>.

13

FLEX. <
http://www.gnu.
org/software/flex
>, [accessed February 2008].


14


When the lexical analyser matches input
to a regular expression
it then stores information
relating to that token in a special data structure before returning the uniq
ue token number.


3
.4.4.2 Storing Data of Different Types

As the lexical analyser processes the input
(known as
tokenising
)
it is able to store data
alongside the token so that the parser knows what the actual input was. For example, when
the lexical anal
yser
recognizes

the input
„2‟

it says that it is a token of type
T_LNUMBER
.
However, the grammar rules for the parser only specify and know the token type, not that the
token was actually the number „2‟. The
script file passed to F
lex

has been modified,
firstly to
set an appropriate data structure to use for storing information alongside the token but
secondly C/C++ commands have been added to actually store that
information

within the
specified data structure.


The data structure used is
called

a
union

a
nd is capable of storing several different types of
information but only one at a time. To use this

data type,

a C language
struct

data type
is
used
which has two fields. The first
field
is a C language enum
erated type

which tells us
what the type of dat
a stored is. The second
field
is the union which contains a field for each
type of data that can be stored. This data structure and the required definitions are shown
below:

enum eDataType

{


DT_NULL
= 0,


DT_LONG = 1,


DT_DOUBLE = 2,


DT_BOOL

= 3,


DT_S
TRING = 4,


DT_ARRAY = 5,


DT_PTR = 6

};

typedef union _uDataValue

{


p_long lval;


p_double dval;


p_string sval;


p_array *aval;

}

uDataValue;

typedef struct _sValue

{


uDataValue data;


enum eDataType type;

}

sValue;


15


This means that the lexical analyser

can now store data written by the programmer, such as
literals and variable names along

with the

tokens. This information can
then
be accessed by
the parser and in turn passed onto the virtual machine
to be used
.

3
.4.5 Parser

The parser is a separate ent
ity to the lexical analyser
,

although the two are very tightly
interconnected. The lexical analyser on its own is only capable of working out what tokens
the input is constructed of
;

it is the job of the parser to understand and act upon the meaning
of th
e given tokens. Similar to the lexical analyser, the parser is also a collection of functions;
this time created by using the GNU
/
Linux utility called Bison
.

Bison is a general
-
purpose
parser generator that converts an annotated context
-
free grammar int
o an LALR(1) or GLR
parser for that grammar.‟
14


3
.4.5.1 Backus
-
Naur Form Grammar

A
context
-
free
Backus
-
Naur form

(BNF)
15

grammar

file
defining

the
syntax of the

PHP
programming language is inputted to Bison, along with commands that instruct it to use
the
f
unctions generated by
FLEX to fetch the next token in the token stream
16
. The parser
attempts to match the inputted tokens to
a
certain grammar statement. Upon finding a match
with a certain grammar statement, it is possible to make the parser call C/C++
routines. This
makes it possible to
add machine instructions to the virtual machine which in turn allow
s

the

PHP script to be interpreted and executed.

Part of the
grammar statement for the „while‟ programming construct is shown below
. Refer
to Appendix
E

for the full PHP
language
grammar
:

unticked_
statement: T_WHILE '('
expr ')' while
_statement;


while_statement: statement

| ':' inner_statement_list T_ENDWHILE ';'


The above statement instructs the parser that if a T_WHILE token
is encountered
then it
s
hould expect the next token to be an open bracket.

If it is not then the parser will look for
alternative grammar statements
that match
and report a syntax
error

if none are found
.


There are two types of tokens known as
terminal

and
non
-
terminal
. Termi
nal tokens „form
the parts of the strings generated by the grammar‟
17
, that is the token
T_WHILE

and the
brackets in the above example. Non
-
terminal tokens „map to the names of productions in the



14

GNU.
Bison


GNU parser generator
, <
ht
tp://www.gnu.org/software/bison>.

15

Wikipedia.
Backus
-
Naur
Form
, <
http
://en.wikipedia.org/wiki/Backus
-
Naur_form
>.

16

Wikipedia.
Lexical
Analysis
, <
http
://en.wikipedia.org/
wiki/Lexical_analysis
>.

17

Wikipedia.
Terminal Symbol
,

<
http://en.wikipedia.org/wiki/Terminal_symbol
>.


16


grammar‟
18
, these include
expr
,

while_statement

and

inner_sta
tement_list

in the above
example.

3
.4.5.2 Lookahead Left
-
to
-
Right Parsing

A lookahead left
-
to
-
right (LALR) parser reads input
in a
left
-
to
-
right
,

bottom
-
up fashion. The
parser attempts to establish top level grammar statements by using lower level „leaf‟
statements.

The parser consists
of two tables and a stack that is used to track the current state
.
The tables
are used to determine what action to take depending on the current state and what the next
token in the token stream is. The first table is for

terminal tokens and is called the
action

table; the second is for non
-
terminal tokens and is called the
goto

table.

When
Bison generates
a

parser

these tables are created
using the context
-
free grammar
and
supporting code is added to
make calls to the lex
ical analyser to fetch the next token and then
act upon it by indexing the generated tables. This combined code can then
be used to parse
PHP scripts.

The parser follows through the following steps when it is executed:

1)

I
nitialis
e

the current state to 0
.
T
h
e

current state is the state that is always at the top
of the state stack.

2)

Fetch the next terminal from the token stream and considering the current state a table
lookup is performed. There are four possible actions:

a)

S
hift to a

new

state: The terminal
is removed from the token stream and the
new state in the table is pushed onto the state stack.

b)

R
educe by a rule: Remove a state from the stack for every symbol on the
right hand side of the rule. A lookup is then performed on the
goto

table
using the cur
rent state and the
non
-
terminal on the left of the rule and the new
state is pushed onto the state stack.

c)

Accept input: the input is accepted and valid.

d)

No action: the system reports a syntax error.

3)

Repeat (2) until either (2c) or (2d).



3.
4.5.
3

Code Gene
ration Templates

Code generation templates

are plans for generating code (instructions

within the virtual
machine
) based upon grammars that the parser uses.
For example, when a „while‟ construct is
encountered, the computer needs to evaluate the expressio
n
within the brackets
and act upon



18

Wikipedia.
Terminal Symbol
,

<
http://en.wikipedia.org/wiki/Terminal_symbol
>


17


the result (
decide whether to execute

the statements within the loop

or not).

To create this
functionality, other instructions needed to be added alongside the code written by the
programmer

using the
tool
. Code generat
ion templates are similar to the BNF grammar
statements but contain extra information. The code generation template for a „while‟
construct is shown below:

whileA: <template code for expr>



operation not



jump conditional elihwA



<template code for

while_statement>



jump whileA

elihwA:

These templates can then be used to add C/C++ routines
that interface with the virtual
machine
to the BNF grammar file
which
is inputted to Bison
. The
original
grammar
statement
shown in section
3
.4.5.1
has been m
odified to contain three calls to the virtual
machine (variable
M
) that add instructions for the „operation not‟ and two „jump‟ operations

as shown below:

unticked_statement:
T_WHILE '(' { M
-
>WhileInstruction(&$1); }



expr ')' { M
-
>WhileAfterInstruction(
&$4, &$1, &$4); }



while_statement { M
-
>WhileEndInstruction(&$1, &$4); }

These are

required to make the
while loop function as expected.

It can also be seen that the
address in memory of a series of items is

passed as parameters (
$1

and
$4
)

to these func
tions.
These parameters are the extra information stored along with each token as discussed in
S
ection
3
.4.4.2.

The tree in
Figure
1

shows the expanded grammar used to parse the code below:

w
hile ($var < 2) { }

It can

be seen that ev
entually the parser discovers the leaf
-
nodes with the two terminals
T_VARIABLE

and
T_LNUMBER
. These leaf nodes require instructions added to be added to
the virtual machine to make it perform the necessary functions to evaluate the expression
used. A fur
ther instruction needs to be added where the branch splits to perform a less
-
than
operation. The next section discusses how the virtual machine is constructed and how it uses
an instruction set and a stack to perform calculations.


18



Figure
1



The grammatical e
xpansion
of

an example
‘while’ statement.




19


3
.4.6 Virtual Machine

(VM)

The Zend PHP Engine makes use of
opcode

based instructions

and
hash arrays

for temporary
storage amongst other
technologies

to interpret and execute PHP s
cripts. The custom PHP
engine that has been created attempts to take things one step further and create a virtual
machine that works as closely as possible to how a real machine works.
The virtual machine
that has been created uses
instructions based on
o
pcode
s

and
operand
s
.

Opcodes are „
the
portion of a
machine language

instruction

that specifies the operation to be performed‟
19

and
the operand is that data
on

whi
ch the operation is performed
.

The virtual machine

(VM)

is m
ade up of five classes each
of w
hich performs

a distinct
function:

1.

Context



This class looks after the whole process of interpretation and execution. It
is responsible for taking the input, passing it to the parser
for parsing
and then
making
sure there are no errors before
executing t
he generated instructions
.

This class writes
any generated
output (or errors)
to disk so they can be passed to the front
-
end
.

2.

Handler



This class carries out any operations on operands, such a
s the addition of
two variables or the copying of data from on
e stack address to another.

3.

Interrupt



This class contains functions built into the PHP language. This includes
mathematical functions (
sin
,
cos

and
tan

etc
) as well as string manipulation functions
(
strlen

and
strcat

etc
).

4.

Machine



This class is at the

heart of the virtual machine. As the parser finds
grammar statements that match the input
given to it from the lexical analyser code
generation calls are made to
this class
.

This class also handles the execution of the
generated instructions.

5.

Symbol



T
his class is a symbol table
that is
used during the interpretation of PHP
scripts. It is used to keep track of what address functions, constants and variables are
within the stack.

The virtual machine
has t
w
o distinct functions.


F
irstly as an interpreter

the VM is concerned
with

generating the required instructions to make the PHP script execute as required

at run
-
time
.

This will be known as compile
-
time however this is not strictly true because the PHP

script

is never compiled.

Secondly, the
virtual ma
chine has the task of

execut
ing

the
generated instructions
;

this is known as run
-
time
.




19

Wikipedia.
Opcodes
, <
http://en.wikipedia.org/wiki/Opcode
>


20



3
.4.6.1
The
Run
-
Time

Stack

At the centre of the virtual machine during the execution of a PHP
script

sits the
run
-
time

stack.
This is a last in first out (LIFO) stack
that is used to store variables, intermediate
calculations and return values amongst other t
hings.

Each different block of code that is
executed creates a new stack frame on the stack (i.e. for every function call). Stack frames
are used to store variabl
es on the stack for each block of code that is executed and to allow
language features such as functions and global variables. The stack is implemented using an
array and therefore each stack frame has two variables (
top

and
bottom
)

that keep

track
of
whe
re in the array the stack frame is located.
There is always at least one stack frame on the
stack

because there is always one block of code being executed
, and there is only one active
stack frame at a time (the top
-
most one).

Stack frames are variable
in size but always contain at least three
reserved locations in the
bott
om three locations of the frame.
Locations 0, 1 and 2 in Figure 3.9 show

the
static link
,
dynamic link

and
return address

which exist in every stack frame
.

Location 3 is data that
co
uld have been pushed onto the stack

as the result of program instructions executing

or a
variable/constant.

The static link

is used to establish the correct location to retrieve variables
from at run
-
time
based upon the
information

known at compile
-
time
.
The dynamic link stores the bottom
location of the previous stack frame so when a return instruction is encountered, the previous
stack frame can be restored. When this happens the top of the previous stack frame
can be
calculated as

the bottom of the cur
rent stack frame minus one

position
.

The return address
stores the address of the next instruction to execute when a return instruction is encountered.



Figure
2



An example of a stack frame.


21



Figure
3



An example of a run
-
time stack with two stack frames.

Figure
3

shows the stack
during

a function
call

and shows that a second stack frame has been
created

on

the top of the stack
.
The first stack frame (green) always exists be
cause there is
always one part of the program being executed. This stack frame always has a bottom

of 0.
During compile time, the number of variables and constants for a block of code are
calculated; space is then reserved on the stack when the stack fra
me is created. For example,
in
Figure
3

the data at positions 3, 7 and 8 might be variables or constants and they will have
had stack space reserved for them. Alternatively, they may be literals
pushed
on
to

the stack
for interme
diate calculations. If we assume that the second stack frame

(red)

has two
variables then we can calculate the top to be
bottom +
variables + constants

+ 2

to give the
result of 8 (4 + 2 + 0 + 2).

This achieved at compile time by consulting the symbol ta
ble for
how many variables and constants are declared in a block of code and then adding the
required instruction to increase the stack size.
If an instruction pushes data onto the stack, or
pulls it off then the top value of the current stack frame will
also
increase

or decrease.

3
.4.6.
2

Virtual Machine Instructions

The virtual machine is similar to any real computer in that it has a set of instructions that
carry out tasks when executed. These instructions in a real CPU include moving data from
memory i
nto registers and vice versa, or calling interrupt routines for example. In the case of
the virtual machine there is a set of eighteen instructions. Several of these instructions make
use of
opcodes

to give extra meaning to them, in effect creating a wid
er instruction set. These
twenty four opcodes
act upon the data

(operands) pointed to by the instruction
.


22


The full instruction set is listed in
T
able
1, Appendix
F

and the opcodes that are used by the
o
peration
,
m
emory

and
a
rray

instructions are listed in

T
able
2, Appendix
F
.

After compilation, the PHP program exists as an array of instructions within the virtual
machine. When it comes to executing these, the VM sets the program counter register to
zero, to start with the first instruction. Once the inst
ruction has been executed the program
counter is incremented such that the next time around the loop the next instruction will be
executed. This continues until either a halt instruction or the end of the array is encountered.

3
.4.6.3
Compile
-
Time

Discuss
ion has so far centred on how the virtual machine executes instructions, and what
those instructions are. However, before any of that can be carried out
,

it is the task of the
interpreter to
use the appropriate code generation template for each grammar st
ructure so that
the program executes correctly at run
-
time.
At run
-
time the virtual machine has no
knowledge of variable or function names, only their addresses (whether it be an address on
the stack or the address of an instruction), to aid the interpret
er in keeping track of these
addresses at compile
-
time a structure
called a symbol table is used.

The symbol table is implemented with a LIFO stack and is used to store information about
identifiers

(
constants, variables and procedure
s
) such as their names
, addresses and types.
Information for a particular identifier only exists within the symbol table while it is in
its

scope of declaration. This means that when an identifier is defined, it is added to the symbol
table. When the identifier goes out of
scope it is removed from the symbol table. When an
identifier is used in a statement or expression, the interpreter will
go through the symbol table
in a last to first

fashion until it finds the required identifier. This
makes sure

that the most
recently

defined identifier is correctly chosen when one or more identifiers of a given type
have the same name.

Different information is stored for each

different type of identifier
stored in the table:

1.

Variables



The symbol table stores the offset within the s
tack frame that the
variable‟s data will be stored at. The first variable for a stack frame has an offset of
3, then 4 etc because of the three special slots (static link, dynamic link and return
address).

2.

Globals


The symbol table stores the same inform
ation as for variables, however
when a new variable is defined, the symbol table is consulted to see if a global with
the same name exists.


3.

Constants


The symbol table stores the same information as for variables, however
their value cannot be changed

on
ce they have been defined
.


23


4.

Functions


T
he symbol table stores the name of the function, the level at which it
has been defined and the address of the first instruction in the function.

3
.5 Restricting Language Constructs

One of the main requirements of th
e teaching aid is the ability to restrict certain language
constructs (conditional statements, loops etc) from being used. This is to restrict students
from using language features that have not been taught to them yet.
The restriction system
works using

a system of levels. The student chooses what week
in the semester it currently is

using a drop down menu on the toolbar. Associated with each week is a number that
corresponds to the level (1, 2, 3 etc) which is submitted to the PHP back
-
end along with
the
code and a configuration file detailing which grammar statements
(elements)
are allowed for
that level. When the parser

calls the virtual machine
to notify it
that a grammar statement

has
been matched
, the virtual machine checks to see if the grammar
statement is
legal

at the
current level.


The level configuration file is cryptic to read in its raw format to make
it quicker to parse.
Therefore, a utility has been created to aid the
lecturer
in changing what weeks each grammar
statement can be used i
n. This is shown in
Figure
4
.


Figure
4



The administration utility for restricting language constructs.

The utility is written in C#.NET and therefore requ
ires the .NET Runtime Framework.
H
owever it c
ould easily be ported to C++ to run on both Linux and Mac OS.



24


3
.
6

Front
-
end / Back
-
end
Interface

The final component to the system is the interface that joins the front
-
end to the back
-
end.
The interface is a single server
-
side PHP web page that
passes

t
he PHP code entered in the
user interface onto the PHP engine for processing before returning the output back to the user
interface. Figure 1, Appendix B shows where the interface fits into the overall system.

When the user presses the „Parse script‟ butt
on on the user interface an AJAX

request is
generated using the Ext

JS user interface library. This request passes the users PHP script and
current semester week to the interface

where they can be accessed using
the PHP

$_POST

variable
.

The interface the
n writes the PHP script to the server‟s disk before executing the
PHP engine specifying the script location as a command line parameter. When the PHP
engine has finished executing, the output is read from disk and returned to the user interface
as output
to AJAX request.





25


4
. TESTING

4
.1 Test Plan

There are two distinct areas of the implemented solution that need testing. First and foremost
,
for a given input

the
custom
PHP engine
must

produce exactly the same output as the real
PHP engine

created

by

Zen
d
. This is the most important aspect because
it is no
use

having a
teaching aid that teaches incorrectly.
Secondly, the
s
ystem must actually
work;

this covers
other requirements such as being able to restrict the language grammar that is available to the

user as well as
elements of the user interface such a
s cross
-
browser compatibility
.

The custom PHP engine will be tested
using
code samples
from the official PHP
documentation
20

that demonstrate how to program PHP

properly. These code samples will be
pass
ed through the custom PHP engine and the output compared with the output shown on the
documentation website. If the output is the same then it can be assumed that the engine is
functioning correctly.
Obviously it is unreasonable to test every
combination

of programming
constructs because there is an infinite amount.

The engine will also be tested with
syntactically incorrect code to make sure that an

appropriate

error
message
is reported.

The rest of the system will be tested by choosing appropriate test

cases to test the
functionality of individual aspects. The tests will contain both valid and invalid input to test
for both normal output and correct error handling.

One of the requirements is that the teaching aid
works

in all of the
most used
internet
browsers

which are Internet Explorer, Firefox, Opera and Safari
21
.

An online service provided
by
BrowserShots
22

will be used to make sure this requirement is met
.

4
.2 Test Cases and Results

Table
7

and
Table
8

in Appendix H
show the results of testing relating to the front
-
end

and
back
-
end

respectively. It can
be seen that the back
-
end fails

on a
number

of tests relating to
language constructs that ha
ve

not been implemented

or contain bugs in their implementati
on
.
The front
-
end functioned without any errors during testing. Appendix I contains a collection
of images generated by BrowserShots that show the user interface renders successfully in the
four main web browsers.




20

PHP.
PHP: Docum
entation
. <
http://www.php.net/docs.php
>, 03/05/2008, [accessed 03/05/2008].

21

Wikipedia.
Usage share of web browsers
,
<
http://en.wikipedia.org/wiki/Usage_share_of_web_browsers
>, 02/05/2008, [accessed 03/05/2008].

22

Test your website in different browsers
,
<http://www.browsershots.org>, [accessed 02/03/2008].


26


5
. EVALUATION

OF TEST RESULTS

Figure
13

to
Figure
18

in Appendix I show that the user interface is successfully rendered in a
range of different web browsers on a range o
f different operating systems. This is expected
because the user interfac
e Ext JS has been designed with cross
-
browser compatibility in mind.
The test results in
Table
7
, Appendix H show

that the user interface is working as it has been
designed to.
Test case 1 shows that the three content areas can
be resized and are correctly
being restricted from being resized too small. The toolbar buttons are function correctly as
demon
strated with test cases 5 and 6;

when the „New script‟ button is clicked the input area is
cleared

and the script is being sent
to the interface when the „Parse script‟ button is clicked
.

T
a
b
l
e

8
,

Appendix H contains test results for the PHP back
-
end. The back
-
end is successfully
outputting

HTML tags
without modification
and is capable of
processing PHP contained in
either short or full length PHP tags as shown in test cases 1
-
3.

Standard mathematical
calculations and string concatenation work as expected. However, test cases 6
-
9 inclusive
show that the increment and decrement operators a
re not working. Test cases
21
-
24

show
that the
+=
,
-
=

etc operators are not working as
they should
. An investigation into why they
had stopped function correctly showed that a modification made to the method of loading and
saving variables to and from th
e stack had caused
a stack corruption
. This could not be fixed
before the project deadline.

Test cases 10
-
20

inclusive tested the main language constructs to make sure they are
functioning correctly
. It can be seen that
do
-
while

loops,
switch

statements
and
foreach

loops
returned errors. The bug causing
do
-
while

loops to fail was fixed before the project deadline
however, suitable solutions to the problems surrounding
switch

statements and
foreach

loops
could not be resolved and therefore they do not wor
k.

All other language constructs including
if
-
else

statements,
while

loops and
for

loops function correctly.

Test cases 2
5
-
3
1

show that arrays work correctly and can contain values that are of any data
type and can be indexed by either an integer or a str
ing literal; arrays can also be indexed
using variables as long as they are of the correct type (test case s 27 and 28). Test case 30
demonstrates that an array can contain arrays as values and therefore multi
-
dimension arrays
are possible.

The last set
of test cases (32 to 35 inclusive)

show that function calls are
working properly. Values can be passed into procedures via parameters and then return
values can be passed back to the calling procedure.

The ability to use
for

loops was restricted and an at
tempt made to use them within a script
(test case 36). An error message was successfully reported back to the user interface.


T
e
s
t

c
a
s
e

3
7

s
h
o
w
s

t
h
a
t

t
h
e

i
n
t
e
r
p
r
e
t
e
r

w
i
l
l

a
l
s
o

r
e
p
o
r
t

syntax

e
r
r
o
r
s

b
a
c
k

t
o

t
h
e

u
s
e
r

i
n
t
e
r
f
a
c
e
.



27


6
. CONCLUSION

The project
has been

a success

as far as the fact that a PHP interpreter has been developed
that is capable of int
erpreting and executing PHP scripts. H
owever
,

not all of the
requirements and objectives
have been
met due to time
restrictions; this means

that the project
has not met its core
objective
.

To meet the core
objective
of having all basic language
construct
s implemented the project would require further development to implement the
missing constructs.

An appropriate user interface
has been

developed that me
e
t
s

all of the requirements set out. It
is capable of running on a variety of different web browsers
a
nd
provides the user with a
syntax highlighted area for inputting PHP code
.

The user interface
meets

the advantages
demonstrated by the previous work
by displaying
code examples alongside the code input
area
. It then builds upon the advantages by

includi
ng the ability to click a link
to
automatically copy

code from the code examples to the input area

increasing the usability of
the tool
. The interface is uncluttered
, resizable

and has been designed for ease of use by
being similar to other applications t
ha
t

s
t
udents should be used to using.

The majority of
time and effort
was spent designing and implementing the virtual machine at
the heart of the
PHP
engine
itself. A custom engine was created specifically for the project
instead of modifying the officia
l engine
.


This in the end proved to be a downfall because
there was not enough time to implement
two

of the
core
language features
,

switch

statements
and
for
each

loops

after spending time developing the required supporting framework
.
This
can be consider
ed a

critical

problem

because
for
each

loops are very useful constructs
that are
specific to the PHP language.

However, these could be implemented at a later date making
the system complete.

The objectives of establishing the language grammar, code genera
tion
templates and tokens required for the engine were met successfully; therefore any code the
custom interpreter will interpret, the official engine will also interpret. However, despite
switch
statements and
foreach

loops being accepted, they will not
execute expected which
will cause confusion if students attempt to use them; as can be seen from testing.

In conclusion, it is

therefore

inevitable that the feature set of
the developed

PHP interpreter is
restricted

in comparison to that provided by the of
ficial PHP engine, because of the limited
time available for its design and implementation during this project. In retrospect, if the
official
P
HP engine was
instead
modified

to meet the needs of the project, then the

designed
interpreter would have
all the required
f
e
a
t
u
r
e
s
;

t
h
e
r
e
f
o
r
e

t
h
e

a
i
m

o
f

t
h
e

p
r
o
j
e
c
t

w
o
u
l
d

h
a
v
e

b
e
e
n

a
c
h
i
e
v
e
d
.



28


7
. RECOMMENDATIONS AN
D FURTHER WORK

7
.1 Project Limitations

T
he biggest limitation to the project was
a lack of
time.
The Zend PHP engine has been in
existence since 1999 and therefore the d
evelo
p
ers
have
had a lot of time to perfect the engine,
to make it run efficiently and to make it run on a range of computer architectures. Despite a
cut down feature set, and no direct need for the engine to be resource efficient it was still a
big task to cr
eate a completely new PHP engine from scratch. If more time was available
then
all of the features of the PHP language
could have been implemented
and then take
n a
step further

by
implementing

the ability to use
other
programming
languages.

The project
was in a working state at the start of semester two and so it would have been ideal
to test the tool in a real world scenario by
having

a selection

of

students currently learning
PHP as part of their first year

syllabus

to spend a session testing it for me