TkSee/SN Experiences with the parser benchmark
description
Transcript of TkSee/SN Experiences with the parser benchmark
TkSee/SNExperiences with the parser
benchmark
IWPC 2002, Paris
S. Marchenko and T. Lethbridge
Parser Architecture
tkSee/SN parser
C/C++source
C/C++parser
SN DB
SN DBAPI
GXLFile(s)
SN 5.0parsing engine.
Cross-referencedata filePass 1.
generating code
information
TCL API
System calls
GXLgenerator
Direct codeinfo extractor
SN DBManager
Pass 2.generating
cross- reference
information
Source Navigator Database Structure
InheritancesGlobal variables
Constants
Enumerations
Inclusions
Enumerated constants
Function declarations
Instance variables
Function implementations
File symbols
Macros
Method declarations
Method implementations
Typedefs
Referenced-BY…
Referenced-TO…
Classes
TkSee/SN on the benchmark: Positive points
• Parser always produced output for all tests•No crashes
• Benchmark results can be easily recreated by other.• We use “free” software tools including our parser.• Answer-generation scripts are included along with the results).
• For “generated code” results we process the embedded code in the original lex/yacc source along with the generated results
TkSee/SN on the benchmark: Negative points.
• Accuracy and completeness of information extracted by parser was limited by supported language dialects:
•Not all examples were C++, K&R C, and ANSI C, which we support•Some tests were apparently from other dialects
•Not supported:• Pre-processing directives.• Namespaces • Operator overloading.
• Parser is not capable of “run-time” call resolution
Feedback on the benchmark (1)
•Benchmark helped us to fix a few bugs in our parser•Related to accuracy of results
•Additional questions added for this iteration were useful
•Extraction of positions information in terms of offset in bytes from the beginning of the source files:
•This was formally possible in TkSee•We moved away from it to line/character positions due to an attempt to conform to what everybody else is doing!
Feedback on the benchmark (2)
• “Heterogeneous” examples•E.g. combination of C/SQL•Benchmark should perhaps not ask about the content of the embedded language
•since the main intention of the test is comparison of C/C++ parsers.
• Some questions had to be answered rather indirectly•E.g. Number of Macros used to compute number of #define•DMM did not fully support some questions, but we could ‘stretch’ it!