Results 1 - 10
of
34
C--: A Portable Assembly Language That Supports Garbage Collection
- IN INTERNATIONAL CONFERENCE ON PRINCIPLES AND PRACTICE OF DECLARATIVE PROGRAMMING
, 1999
"... For a compiler writer, generating good machine code for a variety of platforms is hard work. One might try to reuse a retargetable code generator, but code generators are complex and difficult to use, and they limit one's choice of implementation language. One might try to use C as a portable ass ..."
Abstract
-
Cited by 62 (19 self)
- Add to MetaCart
For a compiler writer, generating good machine code for a variety of platforms is hard work. One might try to reuse a retargetable code generator, but code generators are complex and difficult to use, and they limit one's choice of implementation language. One might try to use C as a portable assembly language, but C limits the compiler writer's flexibility and the performance of the resulting code. The wide use of C, despite these drawbacks, argues for a portable assembly language. C-- is a new language designed expressly for this purpose. The use
Specifying Representations of Machine Instructions
- ACM TRANSACTIONS ON PROGRAMMING LANGUAGES AND SYSTEMS
, 1997
"... ..."
The New Jersey Machine-Code Toolkit
- IN PROCEEDINGS OF THE 1995 USENIX TECHNICAL CONFERENCE
, 1995
"... The New Jersey Machine-Code Toolkit helps programmers write applications that process machine code. Applications that use the toolkit are written at an assembly-language level of abstraction, but they recognize and emit binary. Guided by a short instructionset specification, the toolkit generates al ..."
Abstract
-
Cited by 48 (8 self)
- Add to MetaCart
The New Jersey Machine-Code Toolkit helps programmers write applications that process machine code. Applications that use the toolkit are written at an assembly-language level of abstraction, but they recognize and emit binary. Guided by a short instructionset specification, the toolkit generates all the bitmanipulating code. The toolkit's specification language uses four concepts: fields and tokens describe parts of instructions, patterns describe binary encodings of instructions or groups of instructions, and constructors map between the assembly-language and binary levels. These concepts are suitable for describing both CISC and RISC machines; we have written specifications for the MIPS R3000, SPARC, and Intel 486 instruction sets. We have used the toolkit to help write two applications: a debugger and a linker. The toolkit generates efficient code; for example, the linker emits binary up to 15% faster than it emits assembly language, making it 1.7-2 times faster to produce an a....
Machine descriptions to build tools for embedded systems
- In ACM SIGPLAN Workshop on Languages, Compilers, and Tools for Embedded Systems (LCTES’98), volume 1474 of LNCS
, 1998
"... - CSDL should support a variety of machine-level tools while remaining inde-pendent of any one in particular. ..."
Abstract
-
Cited by 45 (16 self)
- Add to MetaCart
- CSDL should support a variety of machine-level tools while remaining inde-pendent of any one in particular.
Guard: A relative debugger
- Software Practice and Experience
, 1997
"... (to appear in Software-Practice and Experience) A signi cant amount of software development isevolutionary, involving the modi cation of already existing programs. To a large extent, the modi ed programs produce the same results as the original program. This similarity between the original program a ..."
Abstract
-
Cited by 26 (9 self)
- Add to MetaCart
(to appear in Software-Practice and Experience) A signi cant amount of software development isevolutionary, involving the modi cation of already existing programs. To a large extent, the modi ed programs produce the same results as the original program. This similarity between the original program and the development program is utilized by relative debugging. Relative debugging is a new concept that enables the user to compare the execution of two programs by specifying the expected correspondences between their states. A relative debugger concurrently executes the programs, veri es the correspondences, and reports any di erences found. We describe our novel debugger, called Guard, and its relative debugging capabilities. Guard is implemented by using our library of debugging routines, called Dynascope, which provides debugging primitives in heterogeneous networked environments. To demonstrate the capacity of Guard for debugging in heterogeneous environments, we describe an experiment in which the execution of two programs is compared across Internet. The programs are written in di erent programming languages and executing on di erent computing platforms.
A Procedural Interface for Program Directing
, 1995
"... This paper presents a library of directing commands which enable the construction of powerful directors. The interface has been implemented in a Unix environment as a runtime subsystem running in the directed program's address space. The paper provides the description of the interface and the basic ..."
Abstract
-
Cited by 21 (10 self)
- Add to MetaCart
This paper presents a library of directing commands which enable the construction of powerful directors. The interface has been implemented in a Unix environment as a runtime subsystem running in the directed program's address space. The paper provides the description of the interface and the basic programming techniques in building directors. Examples of novel applications, illustrating the use of the directing interface, are demonstrated by the directors for the visualization of program control and structured snapshots
A Simple and Extensible Graphical Debugger
- IN WINTER 1997 USENIX CONFERENCE
, 1997
"... deet is a simple but powerful debugger for ANSI C and Java. It differs from conventional debuggers in that it is machine-independent, graphical, programmable, distributed, extensible, and small. Low-level operations are performed by communicating with a "nub," which is a small set of machine-depende ..."
Abstract
-
Cited by 20 (4 self)
- Add to MetaCart
deet is a simple but powerful debugger for ANSI C and Java. It differs from conventional debuggers in that it is machine-independent, graphical, programmable, distributed, extensible, and small. Low-level operations are performed by communicating with a "nub," which is a small set of machine-dependent functions that are embedded in the target program at compile-time, or are implemented on top of existing debuggers. deet has a set of commands that communicate with the target's nub. The target and deet communicate by passing messages through a pipe or socket, so they can be on a different machines. deet is implemented in tksh, an extension of the Korn shell that provides the graphical facilities of Tcl/Tk. Users can browse source files, set breakpoints, watch variables, and examine data structures by pointing and clicking. Additional facilities, like conditional breakpoints, can be written in either Tcl or the shell. Most debuggers are large and complicated, deet is less than 1,500 lines...
A Debugging Tool for Software Evolution
- CASE-95, 7th International Workshop on Computer-Aided Software Engineering
, 1995
"... This paper describes a tool for debugging programs which have been developed using evolutionary software techniques. The tool enhances the traditional debugging approach by automating the comparison of data structures between two running programs. Using this technique, it is possible to use early ve ..."
Abstract
-
Cited by 19 (9 self)
- Add to MetaCart
This paper describes a tool for debugging programs which have been developed using evolutionary software techniques. The tool enhances the traditional debugging approach by automating the comparison of data structures between two running programs. Using this technique, it is possible to use early versions of a program which are known to operate correctly to generate values for comparison with the new program under development. The tool allows the reference code and the program being developed to execute on different computer systems by using open distributed systems techniques. A simple visualisation system allows the user to view the differences in data structures. By using the data flow of the code, it is possible to locate faulty sections of code rapidly. A small case study of finding an error in a scientific code is given. 1. INTRODUCTION The high cost of software development, in combination with advances in software engineering, has caused the emergence of a software development m...
Implementation of Stack-Based Languages on Register Machines
, 1996
"... Languages with programmer-visible stacks (stack-based languages) are used widely, as intermediate languages (e.g., JavaVM, FCode), and as languages for human programmers (e.g., Forth, PostScript). However, the prevalent computer architecture is the register machine. This poses the problem of efficie ..."
Abstract
-
Cited by 13 (0 self)
- Add to MetaCart
Languages with programmer-visible stacks (stack-based languages) are used widely, as intermediate languages (e.g., JavaVM, FCode), and as languages for human programmers (e.g., Forth, PostScript). However, the prevalent computer architecture is the register machine. This poses the problem of efficiently implementing stack-based languages on register machines. A straight-forward implementation of the stack consists of a memory area that contains the stack items, and a pointer to the top-of-stack item. The basic
A Machine-Independent Debugger
- Software—Practice and Experience
, 1995
"... cdb is a simple, source-level debugger for ANSI C programs compiled by lcc, a retargetable C compiler. cdb is completely independent of its target architecture. This independence is achieved by embedding a small amount of itself --- a `nub' --- in the program to be debugged and by having the compil ..."
Abstract
-
Cited by 12 (3 self)
- Add to MetaCart
cdb is a simple, source-level debugger for ANSI C programs compiled by lcc, a retargetable C compiler. cdb is completely independent of its target architecture. This independence is achieved by embedding a small amount of itself --- a `nub' --- in the program to be debugged and by having the compiler emit machine-independent symbol-table data and related code. This paper describes the design of a nub interface for debugging, a target-independent implementation of this interface for cdb, and the implementation of cdb itself. When compared to platform-specific debuggers, cdb's implementation is minuscule: the nub, debugger, and associated communications routines take about 1500 lines of C, and fewer than 600 lines were added to lcc's front end to emit symbol tables and breakpoint hooks. All this code is machine independent. Introduction Source-level debuggers are notoriously machine-dependent programs. Most debuggers depend not only on the machine on which they run, but also depend...

