Re: interpreter: how is it possible to interpret nested IF ELSE ENDIF ????

Aleksey Demakov <ademakov@gmail.com>
Fri, 31 May 2013 16:07:38 +0400

          From comp.compilers

Related articles
interpreter: how is it possible to interpret nested IF ELSE ENDIF ???? jkallup@web.de (Jens Kallup) (2013-05-15)
Re: interpreter: how is it possible to interpret nested IF ELSE ENDIF ademakov@gmail.com (Aleksey Demakov) (2013-05-31)
Re: interpreter: how is it possible to interpret nested IF ELSE ENDIF mertesthomas@gmail.com (2013-06-19)
| List of all articles for this month |
From: Aleksey Demakov <ademakov@gmail.com>
Newsgroups: comp.compilers
Date: Fri, 31 May 2013 16:07:38 +0400
Organization: Compilers Central
References: 13-05-009
Keywords: interpreter, design
Posted-Date: 31 May 2013 15:16:49 EDT

Hi,


Just have in your interpreter a structure that has all the information
required to execute one statement. To support nested statements every
such structure should have a pointer to the parent structure. You will
have a global pointer to the currently executing statement. When
interpreter meets a nested statement it creates a new structure, saves
the current statement in the parent pointer and makes the new
structure current. When the interpreter reaches the end of the current
statement it takes its parent pointer and makes it current.


For if-else-endif statement you will need to remember within the
structure if the if-condition was met. Depending on it you set a
global skip-flag when entering either of the two if branches. When the
flag is set the statements like assignments and procedure calls are
just ignored. But for nested if-else-endif statements the interpreter
still creates nested structures and observes the described above order
of entering and leaving them.


But on entering a branch before setting the skip flag it is required
to save its previous value and on leaving a branch the previous value
has to be restored.


Such implementation technique works well for such simple cases as
#ifdefs of c preprocessor.


But when it is necessary to handle something more complicated like
loop statements or gotos then it becomes more practical to have some
sort of intermediate representation like ASTs or bytecodes.


Regards,
Aleksey


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.