CSC/ECE 517 Fall 2009/wiki2 8 rop: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
mNo edit summary
Line 59: Line 59:
Non-reflective approach:
Non-reflective approach:


repeat N times {
  if STATE is 1
    increase A by one
  else
    decrease A by one


  do something with A
}
The optimized version of the pseudo-code with a reflective approach is:
repeat N times {
  increase A by one
  do something with A
  }
  when STATE has to switch { replace the opcode "increase" above with the opcode to decrease }


=== Functional Testing and beyond ===
=== Functional Testing and beyond ===

Revision as of 20:39, 8 October 2009

Reflection-oriented programming

Traditional programming has always separated data from the instructions. Even though the memory system that stores them doesn't make any distinction between them, the way they are handled is the only differentiator. Data is "processed" while instructions are "executed". Reflection-oriented programming is a technique in which the program is made intelligent enough to modify their behavior.

Overview

Refection-oriented programming is a new paradigm which deals with understanding the computation as a task rather than a program. Conceptually, it can be thought as the program setting up a "watchdog" to observe the changes and self-modify accordingly based on the observations. One thing to be mentioned here is that this paradigm goes well with dynamically typed languages such as Ruby, Lisp etc. The core behind this paradigm is the flexibility of treating the instructions as data so that all the policies of data modification can be applied onto them.

Reflective Paradigm

Reflected-oriented programming is the concept used to write Reflective programs. This allows the program architecture to be decided during the course of execution and is not "hard-wired" to the procedural structure. This paradigm supplements the already-existing object-oriented programming to enhance it with the self-modifying-code feature. The control flow is something which is decided at runtime; this is important since dynamically altered program can change course of execution of a particular event due to modification. Hence, this paradigm requires that the program contain sequence of decisions be implemented rather than the strictness of decision, based on the run-time data.

On a broad perspective, tasks can be classified into:

  • atomic : this category of operations/tasks cannot be interrupted and usually consist of a single step
  • complex : this category of operations/tasks involve multiple steps (or atomic operations) and can be interrupted in the middle of computation

The reason why these categories are brought up here is that, atomic operations being single step do not have a specific structure associated with them. However, the complex tasks/blocks lose their structure when a program is compiled in a non-reflective language. It is necessary to preserve its architecture for reflective programs. The block can be thought of as a state-machine which has pre-defined states data will be in or transition to in case of specific events. This whole package is the metadata that is saved for preserving the structure or architecture of the program.

Paradigm implementation

In most of the languages as the code is compiled/assembled the structure of the program is lost. However, the key to implementing this programming paradigm is to preserve the structure so that the program can be analyzed and modified accordingly. To enable this, the program structure is preserved as metadata in the code. This ensures that even though the compiled/assembled code doesn't maintain the organization, in favor of optimization mostly, the code can be made self-modified. There are some languages like Lisp which do not separate compile-time and run-time. In such cases, there is no difference in the code.

Purpose and Uses

The basic purpose of reflection oriented programming is to introduce flexibility. Broadly the uses of reflection-oriented programming can be classified as:

  • Optimization of a state dependent loop
  • Application of a specialized algorithm to a data set depending on the runtime data information
  • Obfuscating the code to prevent reverse-engineering
  • Protection of code from malware
  • Decompression of code at runtime
  • Universal system for different situations (adaptation and code simplicity)

Apart from these, there are huge number of uses and many unexplored uses too. One interesting observation is the use of self-modifying code to hide copy-protection in DOS applications. It can also be used to hide the presence of a program. This technique may prove harmful if a malware made use of this paradigm. For such reason, some Operating Systems such as OpenBSD have explicit control over self-modifying code.

List of reflection-oriented programming languages

Some of the languages that have inherent reflection oriented programming support are:

  • APL
  • ColdFusion MX
  • Curl
  • Delphi
  • ECMAScript (ActionScript, DMDScript, JavaScript, JScript)
  • Java
  • Lisp
  • Logo
  • C#
  • Visual Basic .NET
  • Objective-C
  • Perl
  • PHP
  • Pico
  • Pliant
  • POP-11
  • Prolog
  • Python
  • Ruby
  • Scheme
  • Smalltalk
  • Tcl

Example

An example of a self-modifying pseudo-code for Optimization of a state dependent loop is shown:

Non-reflective approach:


Functional Testing and beyond

Testing Tools

Summary

References

  1. http://cs.indiana.edu/~jsobel/rop.html