On 22 Jul 2014, at 9:32 pm, Nicole Fontenot <robwob...@gmail.com> wrote:
> Give me some time to look over the Exuberant Ctags code-base and I'll see
> what I can do.
> Can there be some general discussion with, exactly what are the shortcomings
> of the current parser:
> Is there a problem with ctags not understanding that entity blocks and
> architecture blocks are connected in a fundamental way?
> Are there library functions and constructs that are just too much for the
> current implementation? What do those look like?
> Is ctags recognition outdated?
> Is it ctags job to recognize things like flipflops, muxers or
> non-synthesizable constructs?
> I know the topic was on a project of larger scope but, for an IDE ctags is an
> important part of what people expect from one.
> Without good parsing support, the market for the up-and-coming IDE will be
> blasé at best. With this and that I work a full time job in mind,
> don't expect sudden results; If there is a wanting for new features I will do
> my best.
>
I think it would be useful to be able to reference every named object
explicitly or implicitly declared:
(This from VHDL93)
entity_class ::= [§ 5.1]
entity | architecture | configuration
| procedure | function | package
| type | subtype | constant
| signal | variable | component
| label | literal | units
| group | file
(VHDL 2008 adds property and sequence both found in PSL). Notice alias is
missing.
Something like the implicitly declared parameters from a for generation scheme
or loop statement iteration scheme would be clearly out of reach of a
non-thorough parser. I'd suspect labels are too, being context sensitive used
in object declaration as well (constants, signals, variables and files).
There's issue both with ctags and any editor understanding scope, visibility
and declarative regions (which would give you the generation or iteration
scheme variables). Even an architecture name exists in a separate declarative
region for component instantiation. Primary units declarative regions can
extend to their secondary units (or a configuration specification).
Note there are places where object class defining reserved words (e.g. signal,
variable) are optional (interface lists for entities and functions ).
Functions and procedures should be distinct, the former an expression the
latter a statement.
And how do you distinguish between something in a package declaration and
package body when they can be in two different design files? (e.g.
std_logic_1164.vhdl std_logic_1164_body.vhdl). It looks like name by name file
and line number attributes.
I don't know about you but I'd love to have an editor that can filter by entity
class for those times you know what something is but don't remember the exact
name. It's faster (for some of us) then coming up with a meta match value to
search with. The existing VHDL tags implementations tend to pour things into
two few a number of cups, IIRC.
GTKWave has a new dump file format FST, which I've seen in one VHDL
implementation (nvc) and has the ability to point at declarations from the
signals pane, and allows opening an external editor on the declared line in the
declared file. nvc currently only points to declarative regions and by
definition this only covers signals. What's of interest is where the
information comes from - nvc creates a structure containing all the signals
being queued for waveform dump and looks up the location declarations, it's
essentially done from the 'distributed' symbol table the same way you'd
traverse and elaborated model looking for things to 'tag'.
This also points out you need an elaborated model to get an accurate set of
tags or the ability to superimpose configuration on your results. There's two
few a number of cups in object files too, to distinguish even object classes
(without a naming convention which would be implementation limited and likely
platform limited).
And the moral here is not meant as discouragement but to encourage working
toward a known goal. Understand how big the problem is. Try for improvement
over the 'state of the art'.
The last ctags source I have is 5.8 which shows a 29 June 2009 dated for
vhdl.c. It supports limited VhdlKinds:
static kindOption VhdlKinds[] = {
{TRUE, 'c', "constant", "constant declarations"},
{TRUE, 't', "type", "type definitions"},
{TRUE, 'T', "subtype", "subtype definitions"},
{TRUE, 'r', "record", "record names"},
{TRUE, 'e', "entity", "entity declarations"},
{FALSE, 'C', "component", "component declarations"},
{FALSE, 'd', "prototype", "prototypes"},
{TRUE, 'f', "function", "function prototypes and declarations"},
{TRUE, 'p', "procedure", "procedure prototypes and declarations"},
{TRUE, 'P', "package", "package definitions"},
{FALSE, 'l', "local", "local definitions"}
};
signal is only mentioned as a KEYWORD and recognized. (Ouch!)
What good are the concepts 'prototype' or 'local' or even distinct 'record' to
someone thoroughly VHDL inculcated? Taking short cuts leads to substandard
editor/IDE support.
Something free standing can enforce it's will on an editor (GTKWave is an
example). It can coexist with other tools (a plugin in gedit, truly stand
alone, etc., you'd get less usage defining which editor to use). That thing
needs to be thoroughly GHDL aware to be really useful. ctags aren't useful
unless something can take advantage of them and the missing signal is a good
indication of what ctags for VHDL hasn't caught on. (That and for our own works
of VHDL authorship we tend not to need them - we tend to be less altruistic
when there isn't an immediate need).
Try a gander at OpenGrok's Comparison with Similar Tools for features. (This
link was found on the GNU GLOBAL web page. GLOBAL achieves ctag compatibility
by translation. The big selling point is editor independence.)
_______________________________________________
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss
