Separate elaboration and parsing

V

valtih1978

Guest
It seems that VHDL tools separate parsing from elaboration. However, it
seems that some constructions are ambigous at syntax level. For
instnance, http://cs.stackexchange.com/questions/24032, target <=
prefix(argument) can be treated as either

element <= composite_name(10) // selecting an element

or

int_target <= integer(1.1) // conversion

How do the tools handle this case? How do they communicate to the
elaborator whether elements should be addressed or conversion function
instantiated?
 
On Thursday, April 24, 2014 8:48:39 AM UTC-4, valtih1978 wrote:
It seems that VHDL tools separate parsing from elaboration. However, it

seems that some constructions are ambigous at syntax level. For

instnance, http://cs.stackexchange.com/questions/24032, target <=

prefix(argument) can be treated as either



element <= composite_name(10) // selecting an element



or



int_target <= integer(1.1) // conversion



How do the tools handle this case? How do they communicate to the

elaborator whether elements should be addressed or conversion function

instantiated?

They don't communicate. When the names 'composite_name' and 'integer' come across, that name must have already been defined. If they are not defined, you get an error saying that 'composite_name' is unrecognized. If they are defined but you are using them incorrectly (for example by passing in an integer argument to something that is expecting a real) then you will get an error pointing out what you're doing wrong.

Kevin Jennings
 
On Fri, 25 Apr 2014 08:10:12 +0300, valtih1978 wrote:

On 24.04.2014 20:21, KJ wrote:
They don't communicate. When the names 'composite_name' and 'integer'
come across, that name must have already been defined. If they are not
defined, you get an error saying that 'composite_name' is unrecognized.
If they are defined but you are using them incorrectly (for example by
passing in an integer argument to something that is expecting a real)
then you will get an error pointing out what you're doing wrong.

You basically say that parser does the elaboration (if "The process by
which a declaration achieves its effect is called the elaboration of the
declaration" is not elaboration then what is elaboration?) for the
purpose of mantaining the list of defined objects and, thereby, is not
related with elaboration. Try once more. That statement as it is is pure
nonsense.

Kevin is correct and does not need to try once more.

The parser will have resolved any ambiguity or will have issued an
error. The elaboration has all the necessary information to elaborate
the definition (in your phraseology).

To keep the syntax similar consider the following FORTRAN code

I=C(10)

Is "C" a function or array? Or consider

IF(IF(10).NE.0) GOTO JAIL

And yes, that is legal FORTRAN code (actually it could be
IF(IF(10).NE.0)GOTOJAIL). How does the compiler know what "IF" is?

The lexer/parser does not know from the BNF. It has to resolve the issue
by dealing with the symbol table and then building the correct node or
whatever AST type structure you are using.

--
Chisolm
Republic of Texas
 
On 24.04.2014 20:21, KJ wrote:
They don't communicate. When the names 'composite_name' and
'integer' come across, that name must have already been defined. If
they are not defined, you get an error saying that 'composite_name'
is unrecognized. If they are defined but you are using them
incorrectly (for example by passing in an integer argument to
something that is expecting a real) then you will get an error
pointing out what you're doing wrong.

You basically say that parser does the elaboration (if "The process by
which a declaration achieves its effect is called the elaboration of the
declaration" is not elaboration then what is elaboration?) for the
purpose of mantaining the list of defined objects and, thereby, is not
related with elaboration. Try once more. That statement as it is is pure
nonsense.
 
Why Fortran? Do you know that meaning of the symbol depends on the
scope? So, how many tables do you need in VHDL? Do you mean that there
is a difference between elaborating the definitions and building all
those tables?
 
On Friday, April 25, 2014 8:43:58 AM UTC-4, valtih1978 wrote:
Particularly, parser works at per-file basis. Yet, file may refer

objects defined in another file (package), which parser have no idea of.

"which parser have no idea of"...That is not correct

Only elaborator is aware of their nature. How do you build your symbol

table without elaborating the design?

- In one word 'library'.
- In two questions to guide the reader to the solution 'Where do you think the output of parsing the file ends up?' and 'What do you think then happens with that output?' Hint: The 'one word' will help you on both questions.

I would be more helpful, but your misstating what I did say and then your statement to me "That statement as it is is (sic) pure nonsense" when in fact it is correct leads me to make you do some work for yourself.

Kevin Jennings
 
Particularly, parser works at per-file basis. Yet, file may refer
objects defined in another file (package), which parser have no idea of.
Only elaborator is aware of their nature. How do you build your symbol
table without elaborating the design?
 
On Fri, 25 Apr 2014 15:43:58 +0300, valtih1978 wrote:

Particularly, parser works at per-file basis. Yet, file may refer
objects defined in another file (package), which parser have no idea of.
Only elaborator is aware of their nature. How do you build your symbol
table without elaborating the design?

Because parsing the language and actually running a sim (or building
a final bit stream to program a device) are separate task.
The parser takes the language and creates "object code". The
"object code" is going to be in your work library or in some other
library you "use". The LRM has some rules. The "object code" or
other data in the library, has all the necessary information for
references by other design units. I have no idea how Xilinx,
Altera, or any of the other tools represent and save this data.

Consider:

library IEEE;
use IEEE.STD_LOGIC_1164.all;
use IEEE.NUMERIC_STD.all;
use work.my_widget_library_pkg.all;

This is telling the parser where to find the definition of the
symbol "to_integer" or perhaps "my_widget".

Take a look at ghdl and see how they do it.

--
Chisolm
Republic of Texas
 
Because parsing the language and actually running a sim (or building
a final bit stream to program a device) are separate task.

Thanks for even more nonsense.

> The LRM has some rules. The "object code" or

LRM says that there is analyzis stage and elaboration, which check the
design semantics and bind the objects. Thanks for attributing all that
activity to the parser and ignoring any analysis/elaboration that
perform on top of it. Since I asked about the difference between parser
and elaboration, it makes a great sense to silence any
analysis/elaboration and lead astray to the higher level tasks. This
should be really convincing.
 
On Sat, 26 Apr 2014 09:22:12 +0300, valtih1978 wrote:

Because parsing the language and actually running a sim (or building a
final bit stream to program a device) are separate task.

Thanks for even more nonsense.

The LRM has some rules. The "object code" or

LRM says that there is analyzis stage and elaboration, which check the
design semantics and bind the objects. Thanks for attributing all that
activity to the parser and ignoring any analysis/elaboration that
perform on top of it. Since I asked about the difference between parser
and elaboration, it makes a great sense to silence any
analysis/elaboration and lead astray to the higher level tasks. This
should be really convincing.

You must be really fun to work with....

What Kevin and I were trying to *help* you with and explain is the
way the major players in the industry do this with their tools.
Unlike you, these people have had working tool sets for probably
longer than you have been on this planet.

Bye. I'm done with you.
 

Welcome to EDABoard.com

Sponsor

Back
Top