Machine Language Instructions Research Articles

Quick Quantum Circuit Simulation

Quick Quantum Circuit Simulation (QQCS) is a software system for computing the result of a quantum circuit using a notation that derives directly from the circuit, expressed in a single input line. Quantum circuits begin with an initial quantum state of one or more qubits, which are the quantum analog to classical bits. The initial state is modified by a sequence of quantum gates, quantum machine language instructions, to get the final state. Measurements are made of the final state and displayed as a classical binary result. Measurements are postponed to the end of the circuit because a quantum state collapses when measured and produces probabilistic results, a consequence of quantum uncertainty. A circuit may be run many times on a quantum computer to refine the probabilistic result. Mathematically, quantum states are 2n -dimensional vectors over the complex number field, where n is the number of qubits. A gate is a 2n ×2n unitary matrix of complex values. Matrix multiplication models the application of a gate to a quantum state. QQCS is a mathematical rendering of each step of a quantum algorithm represented as a circuit, and as such, can present a trace of the quantum state of the circuit after each gate, compute gate equivalents for each circuit step, and perform measurements at any point in the circuit without state collapse. Output displays are in vector coefficients or Dirac bra-ket notation. It is an easy-to-use educational tool for students new to quantum computing.

Quantification of the phase fraction in multiphase steel and 2D design using mini CNC plotter

This present experimental setup is about designing a low cost three axis Mini CNC plotter using stepper motor, Arduino microcontroller and motor control software. This present experimental plotter deals with a low cost CNC plotter which can be further modified into small - medium size or an open structure as per the requirement. The demand for Computer Numerical Control (CNC) plotter machines in educational institutions and laboratories are rapidly rising with the advancement of technology. Current investigation will present an affordable model of a CNC plotter machine which is able to draw different microstructural phase fraction identification layout for further FE analysis of multiphase steel, automotive layout and any other solid surface using simple algorithm. First of all, image file or text file is converted into G code using Inkscape software and then feed it to the machine using processing software. The microcontroller converts G-code into a set of machine language instruction to be sent to the motor driver of the CNC plotter. L293D Motor Shield accordingly instructs the stepper motor how to move, combine, and synchronize motions of stepper motor ends in a good image.

Malware Family Discovery Using Reversible Jump MCMC Sampling of Regimes

ABSTRACTMalware is computer software that has either been designed or modified with malicious intent. Hundreds of thousands of new malware threats appear on the internet each day. This is made possible through reuse of known exploits in computer systems that have not been fully eradicated; existing pieces of malware can be trivially modified and combined to create new malware, which is unknown to anti-virus programs. Finding new software with similarities to known malware is therefore an important goal in cyber-security. A dynamic instruction trace of a piece of software is the sequence of machine language instructions it generates when executed. Statistical analysis of a dynamic instruction trace can help reverse engineers infer the purpose and origin of the software that generated it. Instruction traces have been successfully modeled as simple Markov chains, but empirically there are change points in the structure of the traces, with recurring regimes of transition patterns. Here, reversible jump Markov chain Monte Carlo for change point detection is extended to incorporate regime-switching, allowing regimes to be inferred from malware instruction traces. A similarity measure for malware programs based on regime matching is then used to infer the originating families, leading to compelling performance results.

Using early instruction sets to introduce computer architecture

Motivating computer science students to study computer architecture can be difficult, especially when complex, modern architectures such as the Intel® Core™ i7 are held up as examples. The solution presented here is to introduce computer architecture by first teaching students how to program simpler, historic machines such as Konrad Zuse's Z1, the Manchester Baby, and the Princeton IAS machine. The limitations of these machines can then be used to motivate students to learn the principles of addressing modes, instruction set architectures, and CPU register design. These early architectures can demonstrate how much, and how little, has changed in the area of computer architecture. This paper summarizes the results of research into the machine language instruction sets and architectures of the Zuse Z1, the Manchester Baby, and the Princeton IAS machine. It then presents examples of how these instruction sets can be used to motivate students in a senior-level computer architecture course.

Navigating through triangle meshes implemented as linear quadtrees

Techniques are presented for navigating between adjacent triangles of greater or equal size in a hierarchical triangle mesh where the triangles are obtained by a recursive quadtree-like subdivision of the underlying space into four equilateral triangles. These techniques are useful in a number of applications, including finite element analysis, ray tracing, and the modeling of spherical data. The operations are implemented in a manner analogous to that used in a quadtree representation of data on the two-dimensional plane where the underlying space is tessellated into a square mesh. A new technique is described for labeling the triangles, which is useful in implementing the quadtree triangle mesh as a linear quadtree (i.e., a pointer-less quadtree); the navigation can then take place in this linear quadtree. When the neighbors are of equal size, the algorithms have a worst-case constant time complexity. The algorithms are very efficient, as they make use of just a few bit manipulation operations, and can be implemented in hardware using just a few machine language instructions. The use of these techniques when modeling spherical data by projecting it onto the faces of a regular solid whose faces are equilateral triangles, which are represented as quadtree triangle meshes, is discussed in detail. The methods are applicable to the icosahedron, octahedron, and tetrahedron. The difference lies in the way transitions are made between the faces of the polyhedron. However, regardless of the type of polyhedron, the computational complexity of the methods is the same.

Buy and Use Thinking Things Through

I thank Selmer Bringsjord and David Ferrucci (1998) for the generosity with which they have described Thinking Things Through (Glymour 1992). I trust readers will use the book whenever possible. I have one objection to their review, and, no surprise, it has to do with John Searle’s argument. The Chinese Room argument was an attempt to show that understanding is not realized simply by carrying out a set of instructions: Searle in a room can carry out the instructions for any computer program if he is given the program to follow and adequate paper, even a program for holding conversations in Chinese, but Searlein-the-room doesn’t understand Chinese. So we shouldn’t think that just because they execute programs that produce intelligent input-output behavior, machines understand anything. So I said: Part of both human and machine input-output behavior is the time between input and output. A lip puckering that takes a year isn’t a kiss. A hand motion that takes a month isn’t a wave. A reply to a sentence that takes a millennium isn’t a conversation. And, I further say, for any interesting program, Searle-in-aroom can’t read and carry out the machine-language instructions fast enough to produce competent input-output behavior. Understanding isn’t just processing the right programs; it’s processing the right programs fast enough. Bringsjord and Ferrucci say: But what if Searle had a computer in the room with him that told him, fast enough, what to do? Then he could produce output from input sufficiently quickly for competence, so Glymour’s objection fails. And I say: Putting the computer in the room would defeat Searle’s argument, because the point of the example was to show, by describing a system (Searlein-the-room) that processes a program and doesn’t understand, that just because machines process a program doesn’t mean they understand. But if Searle is given a computer that executes the program, the example constitutes no argument that the computer in the room with Searle doesn’t understand. Bringsjord and Ferrucci save Searle from the objection only by changing Searle’s example so that it begs the point it aims at.

Introduction to the Special Issue: Trends in Evolutionary Methods for Program Induction

Given accessible computational models of evolution, it is a short leap to the application of evolving programs. At its essence, evolving programs concerns the efficient evolution of behavior. This same question compels the currently thriving artificial life community. Unlike artificial life, however, the practical nature of evolving computer programs forces the evolutionary computation community to attend to the distinct issues involved in the induction of behavior that accomplishes a desired task and which is directed by a program. When evolving computer programs an issue of primary importance is the designation of an appropriate evolvable representation for the behavior. The general requirements of being sufficient to model the behavior and being amenable to evolutionary manipulation imply that an appropriate representation must accommodate the specific constraints of evolving executable structures: Executability must be maintained despite random variation, and variable length expression must be permitted. Popular programming languages permit a wealth of syntactic expressions in order to articulate the intended semantics in a fashion suitable for humans. While necessary for human programmers, extraneous syntax is problematic when evolving programs. Structures constrained by many syntactic rules often become unexecutable after unconstrained evolutionary manipulation. The solution has been to use structures that have minimal syntactic requirements or to employ specialized operators that respect the interpretation of an individual as an executable structure. In addition, because one does not know in advance how long the desired program should be, rather than stipulate a fixed length for an evolved program, dynamic length representations have provided often necessary flexibility. The evolutionary induction of executable structures has been investigated in diverse ways employing distinct representations. Friedberg (1958) and Friedberg, Dunham, and North (1959), working within the constraints of simple computers, evolved sequences of machine language instructions that performed modest computations. Fogel, Owens, and Walsh (1966), interested in the evolution of artificial intelligence, proposed evolving finite state machines as models of intelligent behavior by applying representation specific mutations without recombination in their early definition of evolutionary programming. Evolutionary programming has blossomed more recently into a much broader collection of methods centered

Using emulators as vehicles for instruction in systems programming: prospective consideration

Microprogramming is a technique for implementing machine language instruction sets —it is critical in today's computer architectures and operating systems. An emulator is a set of microprograms that implements the architecture of one machine on another; microprogramming is often used in emulation to make one computer system appear as if it were another. This paper presents the architecture for a microprogrammed computer system, the VSEM. The simulated virtual computer system, its monitor and a simulated concurrent PASCAL are discussed. The usefulness of the VSEM, its monitor and the concurrent PASCAL as vehicles for instruction in systems programming is addressed.

A microcoded RISC

A new, microcoded, RISC-type system is proposed and presented. The microcode is stored in a 256 x 64 PROM Nanomemory in the CPU. The 8-bit opcode of each instruction is a direct address to the Nanomemory. Each Nanomemory 64-bit word (horizontal microcode) corresponds to a specific machine language instruction. A large 2048 x 32 CPU Register file, using the register window approach, is implemented. A bit-sliced (AMD2900) prototype is currently under construction.

Emulators

Microprogramming is a technique for implementing machine language instruction sets --it is critical in today's computer architectures and operating systems. An emulator is a set of microprograms that implements the architecture of one machine on another; microprogramming is often used in emulation to make one computer system appear as if it were another. This paper presents the architecture for a microprogrammed computer system, the VSEM. The simulated virtual computer system, its monitor and a simulated concurrent PASCAL are discussed. The usefulness of the VSEM, its monitor and the concurrent PASCAL as vehicles for instruction in systems programming is addressed.

Emulators; prospective instruments for instruction in systems programming

Microprogramming is a technique for implementing machine language instruction sets -- it is critical in today's computer architectures and operating systems. An emulator is a set of microprograms that implements the architecture of one machine on another; microprogramming is often used in emulation to make one computer system appear as if it were another. This paper presents the architecture for a microprogrammed computer system, the VSEM. The simulated virtual computer system, its monitor and a simulated concurrent PASCAL are discussed. The usefulness of the VSEM, its monitor and the concurrent PASCAL as vehicles for instruction in systems programming is addressed.

A microcoded RISC

A new, microcoded, RISC-type system is proposed and presented. The microcode is stored in a 256 x 64 PROM Nanomemory in the CPU. The 8-bit opcode of each instruction is a direct address to the Nanomemory. Each Nanomemory 64-bit word (horizontal microcode) corresponds to a specific machine language instruction. A large 2048 x 32 CPU Register file, using the register window approach, is implemented. A bit-sliced (AMD2900) prototype is currently under construction.

The reduction of branch instruction execution overhead using structured control flow

This paper presents a technique for specifying change of control (e.g. branch) commands at a sequential processor's macroinstruction set level. It is shown that by representing high level language (HLL) control statements with special machine language instructions, the usual delays associated with control flow changes can be reduced. Preserving the HLL control flow information increases performance by reducing both the number of executed branches and pipeline breaks.

Improving the performance of UCSD Pascal via microprogramming on the PDP-11/60

UCSD Pascal is implemented as a machine-independent virtual machine. This virtual machine is usually interpreted on a host computer by machine language instructions, which, in turn, are often interpreted by microcode. Performance of a virtual machine is generally a function of the number of levels of interpretation required to perform a computation. By bypassing one or more of these layers, it should be possible to enhance performance.To test this hypothesis, a Pascal interpreter was written for the PDP-11/60. After analysis of the Pascal machine, changes were made that interpreted selected portions of the virtual machine directly in microcode.This paper describes the microcode which was added, and discusses the improvements which resulted.

Microcode support software for the Modular Computer System

This paper describes the microprogramming support software tools used to implement and verify microprograms for the Modular Computer System (MCS) at IBM-Owego, NY. The concept of emulating various existing machine language instruction sets to form a "multinative architecture" is the cornerstone of the MCS. Powerful, reliable, and economical microprogramming tools had to be developed to facilitate the large microprogramming effort involved in emulating multiple architectures on the MCS. This paper discusses the software technology behind the microprogramming support software tools (Assembler, Linkage Editor, Computer Logic Diagram Generator, and Simulator) developed for the MCS and analyzes their performance and results.

On reliable software development for microprocessors

Microprocessor software is no longer microsized. It requires the same degree of methodology as is used for developing software for large mainframes. Software development for microprocessors involves much more than just writing the machine language instructions to perform some functions. This paper describes a systematic approach for microprocessor software development based on the concepts borrowed from large systems. The suggested methodology can go a long way to promise reliable software for microprocessor based systems. The approach lays emphasis on an ordered sequence of stages, well-supported development tools, good programming practices and management backing — all integrated into a systematic method. The methodology also suggests the use of an educational plan for new staff.

HTERM/CIM and HTERM/BAS: “Smart” terminal enabling programs for the TRS-80 microcomputer

HTERM/CIM and HTERM/BAS: “Smart” terminal enabling programs for the TRS-80 microcomputer

The design of a space efficient compiler

Writing a compiler for a small machine with minimal software support can be quite difficult because the program is long and debugging aids are usually inadequate. In addition, the usual techniques for compiler writing tend to produce programs which are quite large when compared to, for example, a BASIC interpreter. This frustrates efforts for producing compilers on small machines. We describe a method which can be used to reduce the size of a compiler and simultaneously provide good debugging tools. The resulting compiler sacrifices little in terms of execution speed (in part because compilers on minicomputers are often I/O bound). We have used this method to write an MPL [1] compiler for a Microdata 32/S minicomputer. The compiler requires approximately 12K bytes of memory as opposed to 32K bytes required by the compiler produced by the manufacturer, and compiles at essentially the same speed. Appendix II outlines the syntax of the MPL language and is included to illustrate the size of the language being compiled. MPL is based on PL/I and is quite similar to the PL/M* [2] language developed by the INTEL Corporation. The method described here uses an interpretive language for writing the compiler. Thus the interpreter is the only machine language program written. We coded the interpreter in MPL and used a cross compiler to compile it, however, the interpreter could have been easily coded in assembly language. Figure 1 illustrates the savings of the interpretive language over machine code. The procedure IF_STAT is typical of a routine which might appear in a recursive descent compiler for MPL. The gain in space occurs because machine language instructions carry too much information content when applied to a special purpose (such as compiling). Note for example that a subroutine call for the Microdata requires 6 bytes, but all that is really needed is an opcode to indicate a call and a byte to indicate which of a few subroutines is to be called.

A Machine Description Facility for Compiler Testing

Requirements for a machine description facility for compiler testing are discussed. The compiler testing procedure consists of proving that programs are correctly translated by the compiler at hand. This is achieved by use of a common intermediate representation for both the source and object programs. The intermediate representation for the object program is built by use of a process termed symbolic interpretation. This process interprets a set of procedures which describe the effects of machine language instructions corresponding to the target machine on a suitable computation model in a manner consistent with an execution level definition of the high level language. Some of the important factors which enter into such a definition are discussed. These include architectural constraints posed by the target machine, and a description facility for memory and data types. Once such a definition is formulated, the actual instruction set of the target machine can be described. The highlights and limitations of such a definition facility are discussed in the context of a specific LISP implementation on a PDP-10 computer.

A general-purpose high-level language machine for minicomputers

In the course of our investigations into the design of translator writing systems (compiler-compilers), it has been established [2] that a certain set of “semantic primitives” can adequately express the major portion of the semantics of programs written in any of the several common high-level languages (e.g., PL/I, ALGOL W). It was also observed that each of these semantic primitives, while representing frequently-used high-level language constructs, corresponds to predictable sequences of machine-language instructions in the object code of programs. Similarly, other authors have noted that conventional computer instruction sets are less than satisfactory as target languages for high-level language programs and have offered, as a solution to this problem, hardware or firmware processors designed specifically for programs written in a particular high-level language—the machine language and the programming language are essentially identical. The best known early example of such a processor is Helmut Weber's microprogrammed implementation of the EULER language on an IBM 360/30. [5] More recently, Burroughs Corporation has produced the B1700, a computer that has a microprogrammed language processor for each of several languages, the appropriate one of which is loaded into control memory to interpret a given program. [6,7] Such processors show significant speed increases over conventional computers of comparable basic speed in executing programs written in their particular language, but are too specialized to execute other languages efficiently. Therefore we have conjectured that, by designing a computer organization which implements a set of semantic primitives similar to Lancaster's via microprogramming, one instruction per primitive (so that the work required by a DO statement, for example, is performed in the firmware rather than in the software), we can achieve speed increases approaching those of the single-language processors, while retaining the flexibility characteristic of conventional computer organizations. This paper describes those primitives which we have chosen for initial implementation, and presents some preliminary results on the speedups obtained.