Topic
Translation unit (programming)
About: Translation unit (programming) is a research topic. Over the lifetime, 53 publications have been published within this topic receiving 699 citations. The topic is also known as: compilation unit.
Papers published on a yearly basis
Papers
1 Jan 2005
TL;DR: A novel approach is described to preserve preprocessor directives during parsing and program analysis, and integrate them in the program representations, and the results of implementing this approach in a refactoring tool for C, CRefactory are presented.
Abstract: The C preprocessor is heavily used in C programs because it provides useful and even necessary additions to the C language. Since preprocessor directives are not part of C, they are removed before parsing and program analysis take place, during the phase called preprocessing. In the context of refactoring, it is inappropriate to remove preprocessor directives: if changes are applied on the preprocessed version of a program, it may not be possible to recover the un-preprocessed version. This means that after refactoring, all the source code would be contained in a single unit, targeted to a single configuration and without preprocessor macros.
This thesis describes a novel approach to preserve preprocessor directives during parsing and program analysis, and integrate them in the program representations. Furthermore, it illustrates how the program representations are used during refactoring and how transformations preserve preprocessor directives.
Additionally, the semantics of the C preprocessor are formally specified, and the results of implementing this approach in a refactoring tool for C, CRefactory, are presented.
71 citations
TL;DR: A framework that permits analyses to be expressed in terms of both preprocessing and parsing actions, allowing the implementer to focus on the analysis, and an implementation of such a framework that embeds a C preprocessor, a parser, and a Perl interpreter for the actionhooks is discussed.
Abstract: Analyses of C source code usually ignore the C preprocessor because of its complexity. Instead, these analyses either dene their own approximate parser or scanner or else they require that their input already be preprocessed. Neither approach is entirely satisfactory: the rst gives up accuracy (or incurs large implementation costs), while the second loses the preprocessor-based abstractions. We describe a framework that permits analyses to be expressed in terms of both preprocessing and parsing actions, allowing the implementer to focus on the analysis. We discuss an implementation of such a framework that embeds a C preprocessor, a parser, and a Perl interpreter for the action \hooks." Many common software engineering analyses can be written surprisingly easily using our implementation, replacing numerous ad-hoc tools. The framework’s integration of the preprocessor and the parser further enables some analyses that otherwise would be especially dicult to perform.
51 citations
11 Oct 2000
TL;DR: The experiences of studying conditional compilation based on the symbolic execution of preprocessing directives are presented and two concrete goals are found: for any given preprocessor directive or C/C++ source code line, finding the simplest sufficient condition to reach/compile it, and finding the full condition for that code line.
Abstract: Conditional compilation is one of the most powerful parts of a C/C++ environment available for building software for different platforms with different feature sets. Although conditional compilation is powerful, it can be difficult to understand and is error-prone. In large software systems, file inclusion, conditional compilation and macro substitution are closely related and are often largely interleaved. Without adequate tools, understanding complex header files is a tedious task. This practice may even be complicated as the hierarchies of header files grow with projects. This paper presents our experiences of studying conditional compilation based on the symbolic execution of preprocessing directives. Our two concrete goals are: for any given preprocessor directive or C/C++ source code line, finding the simplest sufficient condition to reach/compile it, and finding the full condition to reach/compile that code line. Two different strategies were used to achieve these two goals. A series of experiments conducted on the Linux kernel are presented.
48 citations
Patent•
5 Apr 1994TL;DR: In this paper, a command preprocessor for a high performance three dimensional graphics accelerator in a computer system is described, where the command preprocessors translates geometry input data from differing formats, and a set of reformatting control registers are preprogrammed with translation parameters by a host processor.
Abstract: A command preprocessor for a high performance three dimensional graphics accelerator in a computer system is disclosed, wherein the command preprocessor translates geometry input data from differing formats. The command preprocessor contains a set of reformatting control registers that are preprogrammed with translation parameters by a host processor. The translation parameters in the reformatting control registers specify translation operations.
45 citations
1 Jan 1972
TL;DR: Major components of each language for data translation are discussed and sample statements in terms of an example data translation from a COBOL file to a NIPS/360 file are provided.
Abstract: The CODASYL Stored Data Definition and Translation Task Group has for the past two years been investigating the major components necessary in a language for data translation. Data translation is defined as the process whereby data that can be processed on one computer (the source file) can be translated into a form (the target file) which can be used by the same or a different processing system on a possibly different computer.Two languages are necessary—a Stored Data Definition Language to characterize the logical structure and physical realization of the source and target files, and a Translation Definition Language for defining how target file data instances are to be derived from source file data instances. This report discusses major components of each language and provides sample statements in terms of an example data translation from a COBOL file to a NIPS/360 file.
42 citations
Related Topics (5)
Performance Metrics
| Year | Papers |
|---|---|
| 2018 | 1 |
| 2015 | 2 |
| 2014 | 2 |
| 2012 | 1 |
| 2011 | 2 |
| 2010 | 2 |