scispace - formally typeset
Search or ask a question
Author

Todd A. Proebsting

Bio: Todd A. Proebsting is an academic researcher from Microsoft. The author has contributed to research in topics: Compiler & Code generation. The author has an hindex of 25, co-authored 51 publications receiving 2368 citations. Previous affiliations of Todd A. Proebsting include University of Wisconsin-Madison & University of Arizona.


Papers
More filters
Journal ArticleDOI
TL;DR: This paper describes a simple program that generates matchers that are fast, compact, and easy to understand and run up to 25 times faster than Twig's matchers.
Abstract: Many code-generator generators use tree pattern matching and dynamic programming This paper describes a simple program that generates matchers that are fast, compact, and easy to understand It is simpler than common alternatives: 200–700 lines of Icon or 950 lines of C versus 3000 lines of C for Twig and 5000 for burg Its matchers run up to 25 times faster than Twig's They are necessarily slower than burg's BURS (bottom-up rewrite system) matchers, but they are more flexible and still practical

222 citations

Journal ArticleDOI
TL;DR: This document describes only that fraction of the BURS model that is required to use BURG, a program that generates a fast tree parser using BURS (Bottom-Up Rewrite System) technology and accepts a tree grammar and emits a BURS tree parser.
Abstract: 1 Overview BURG is a program that generates a fast tree parser using BURS (Bottom-Up Rewrite System) technology. It accepts a cost-augmented tree grammar and emits a C program that discovers in linear time an optimal parse of trees in the language described by the grammar. BURG has been used to construct fast optimal instruction selectors for use in code generation. BURG addresses many of the problems addressed by TWIG [AGT89, App87], but it is somewhat less flexible and much faster. BURG is available via anonymous ftp from kaese.cs.wisc.edu. The compressed shar file pub/burg, shar. Z holds the complete distribution. This document describes only that fraction of the BURS model that is required to use BURG. Readers interested in more detail might start with Reference [BDB90]. 2 Input BURG accepts a tree grammar and emits a BURS tree parser. Figure 1 shows a sample grammar that implements a very simple instruction selector. BURG grammars are structurally similar to YACC's. Comments follow C conventions. Text between \"%{\" and \"%}\" is called the configuration section; there may be several such segments. All are concatenated and copied verbatim into the head of the generated parser, which is called BURM. Text after the second \"%%\", if any, is also copied verbatim into BURM, at the end. The configuration section configures BURM for the trees being parsed and the client's environment. This section must define NODEPTR_TYPE to be a visible typedef symbol for a pointer to a node in the subject tree.

190 citations

01 Jan 1996
TL;DR: The term liquid software is used to describe the complete picture-liquid software is an entire infrastructure for dynamically moving functionality throughout a network, and is expected to enble new paradigms, such as active networks that allow users and applications to customize the network by interjecting code into it.
Abstract: This paper introduces the idea of dynamically moving functionality in a network-between clients and servers, and between hosts at the edge of the network and nodes inside the network. At the heart of moving functionality is the ability to support mobile code-code that is not tied to any single machine, but instead can easily move from one machine to another. Mobile code has been studied mostly for application-level code. This paper explores its use for all facets of the network, and in a much more general way. Issues of efficiency, interface design, security, and resource allocation, among others, are addressed. We use the term liquid software to describe the complete picture-liquid software is an entire infrastructure for dynamically moving functionality throughout a network. We expect liquid software to enble new paradigms, such as active networks that allow users and applications to customize the network by interjecting code into it.

159 citations

Proceedings ArticleDOI
25 Jan 1995
TL;DR: The paper describes the design and implementation of a hybrid translator/interpreter that employs superoperators, an optimization technique for bytecoded interpreters that builds an efficient implementation of the virtual machine in assembly language.
Abstract: This paper introduces superoperators, an optimization technique for bytecoded interpreters. Superoperators are virtual machine operations automatically synthesized from smaller operations to avoid costly per-operation overheads. Superoperators decrease executable size and can double or triple the speed of interpreted programs. The paper describes a simple and effective heuristic for inferring powerful superoperators from the usage patterns of simple operators.The paper describes the design and implementation of a hybrid translator/interpreter that employs superoperators. From a specification of the superoperators (either automatically inferred or manually chosen), the system builds an efficient implementation of the virtual machine in assembly language. The system is easily retargetable and currently runs on the MIPS R3000 and the SPARC.

155 citations

Journal ArticleDOI
TL;DR: To encourage repeatable research, fund repeatability engineering and reward commitments to sharing research artifacts to encourage shareable research.
Abstract: To encourage repeatable research, fund repeatability engineering and reward commitments to sharing research artifacts.

152 citations


Cited by
More filters
Journal ArticleDOI
12 Nov 2000
TL;DR: Key requirements are identified, a small device is developed that is representative of the class, a tiny event-driven operating system is designed, and it is shown that it provides support for efficient modularity and concurrency-intensive operation.
Abstract: Technological progress in integrated, low-power, CMOS communication devices and sensors makes a rich design space of networked sensors viable. They can be deeply embedded in the physical world and spread throughout our environment like smart dust. The missing elements are an overall system architecture and a methodology for systematic advance. To this end, we identify key requirements, develop a small device that is representative of the class, design a tiny event-driven operating system, and show that it provides support for efficient modularity and concurrency-intensive operation. Our operating system fits in 178 bytes of memory, propagates events in the time it takes to copy 1.25 bytes of memory, context switches in the time it takes to copy 6 bytes of memory and supports two level scheduling. The analysis lays a groundwork for future architectural advances.

3,648 citations

Journal ArticleDOI
TL;DR: On conventional PC hardware, the Click IP router achieves a maximum loss-free forwarding rate of 333,000 64-byte packets per second, demonstrating that Click's modular and flexible architecture is compatible with good performance.
Abstract: Clicks is a new software architecture for building flexible and configurable routers. A Click router is assembled from packet processing modules called elements. Individual elements implement simple router functions like packet classification, queuing, scheduling, and interfacing with network devices. A router configurable is a directed graph with elements at the vertices; packets flow along the edges of the graph. Several features make individual elements more powerful and complex configurations easier to write, including pull connections, which model packet flow drivn by transmitting hardware devices, and flow-based router context, which helps an element locate other interesting elements. Click configurations are modular and easy to extend. A standards-compliant Click IP router has 16 elements on its forwarding path; some of its elements are also useful in Ethernet switches and IP tunnelling configurations. Extending the IP router to support dropping policies, fairness among flows, or Differentiated Services simply requires adding a couple of element at the right place. On conventional PC hardware, the Click IP router achieves a maximum loss-free forwarding rate of 333,000 64-byte packets per second, demonstrating that Click's modular and flexible architecture is compatible with good performance.

2,595 citations

Proceedings ArticleDOI
12 Dec 1999
TL;DR: The Click IP router can forward 64-byte packets at 73,000 packets per second, just 10% slower than Linux alone, and is easy to extend by adding additional elements, which are demonstrated with augmented configurations.
Abstract: Click is a new software architecture for building flexible and configurable routers. A Click router is assembled from packet processing modules called elements. Individual elements implement simple router functions like packet classification, queueing, scheduling, and interfacing with network devices. Complete configurations are built by connecting elements into a graph; packets flow along the graph's edges. Several features make individual elements more powerful and complex configurations easier to write, including pull processing, which models packet flow driven by transmitting interfaces, and flow-based router context, which helps an element locate other interesting elements.We demonstrate several working configurations, including an IP router and an Ethernet bridge. These configurations are modular---the IP router has 16 elements on the forwarding path---and easy to extend by adding additional elements, which we demonstrate with augmented configurations. On commodity PC hardware running Linux, the Click IP router can forward 64-byte packets at 73,000 packets per second, just 10% slower than Linux alone.

1,608 citations

Journal ArticleDOI
TL;DR: It is illustrated how the routers of an IP network could be augmented to perform such customized processing on the datagrams flowing through them, and these active routers could also interoperate with legacy routers, which transparently forwarddatagrams in the traditional manner.
Abstract: Active networks are a novel approach to network architecture in which the switches (or routers) of the network perform customized computations on the messages flowing through them. This approach is motivated by both lead user applications, which perform user-driven computation at nodes within the network today, and the emergence of mobile code technologies that make dynamic network service innovation attainable. The authors discuss two approaches to the realization of active networks and provide a snapshot of the current research issues and activities. They illustrate how the routers of an IP network could be augmented to perform such customized processing on the datagrams flowing through them. These active routers could also interoperate with legacy routers, which transparently forward datagrams in the traditional manner.

1,489 citations

Proceedings ArticleDOI
01 Nov 2010
TL;DR: Soot, a framework for optimizing Java* bytecode, is implemented in Java and supports three intermediate representations for representing Java bytecode: Baf, a streamlined representation of bytecode which is simple to manipulate; Jimple, a typed 3-address intermediate representation suitable for optimization; and Grimp, an aggregated version of Jimple suitable for decompilation.
Abstract: This paper presents Soot, a framework for optimizing Java* bytecode. The framework is implemented in Java and supports three intermediate representations for representing Java bytecode: Baf, a streamlined representation of bytecode which is simple to manipulate; Jimple, a typed 3-address intermediate representation suitable for optimization; and Grimp, an aggregated version of Jimple suitable for decompilation. We describe the motivation for each representation, and the salient points in translating from one representation to another. In order to demonstrate the usefulness of the framework, we have implemented intraprocedural and whole program optimizations. To show that whole program bytecode optimization can give performance improvements, we provide experimental results for 12 large benchmarks, including 8 SPECjvm98 benchmarks running on JDK 1.2 for GNU/Linuxtm. These results show up to 8% improvement when the optimized bytecode is run using the interpreter and up to 21% when run using the JIT compiler.

1,160 citations