Re: constatnt initialization

Clint Olsen <clint@0lsen.net>
13 Dec 2003 21:01:06 -0500

          From comp.compilers

Related articles
constatnt initialization csosz77@axelero.hu (2003-12-03)
Re: constatnt initialization wbs@wschindler.net (2003-12-08)
Re: constatnt initialization clint@0lsen.net (Clint Olsen) (2003-12-13)
Re: constatnt initialization nick.roberts@acm.org (Nick Roberts) (2003-12-13)
Re: constatnt initialization joachim.durchholz@web.de (Joachim Durchholz) (2003-12-14)
| List of all articles for this month |

From: Clint Olsen <clint@0lsen.net>
Newsgroups: comp.compilers
Date: 13 Dec 2003 21:01:06 -0500
Organization: Comcast Online
References: 03-12-046
Keywords: analysis
Posted-Date: 13 Dec 2003 21:01:06 EST

On 2003-12-04, Attila Csosz <csosz77@axelero.hu> wrote:


> constant name: type := expression;
>
> I have the book Aho/Sethi/Ulmann: Compilers. Can you suggest me
> algorithms in this book for it or in the internet or other good books?


You're going to have to implement type equivalence checking to your
compiler. There are a couple of ways to do it. The brute force way
is to write a 'deep' comparison which recursively descends into 'type'
and compares it against 'expression' at each phase along the way to
determine that they are assignment compatible. This means, for
structs (records) comparing each field and ensuring that the number
and type of each field is compatible with each element in the
expression, comparing the subtype and number of elements for arrays,
and then simple checks for the intrinsic types (integer, real, string)
etc. You walk 'type' to help guide you for what to expect for
successive elements. If you're writing a recursive descent parser,
this is pretty straightforward since you'll build the 'type' before
you parse the expression.


There are more advanced ways of doing type equivalence using hash
tables (avoids deep compares), but the problem is that you may have to
coerce 'expression' to match the types specifically in 'type' if
you've already built the tree for 'expression'. This is common in
bottom-up techniques like in yacc and friends. I don't know VHDL that
well, so I don't know if type coercion is even allowed. If not, then
the 'expression' type will be correct by design and you can just
perform the deep compare as I mentioned in the first paragraph.


Good luck,


-Clint


Post a followup to this message

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