SOAR: Smalltalk without bytecodes

ACM SIGARCH Computer Architecture News, 1984

Smalltalk on a RISC (SOAR) is a simple, Von Neumann computer that is designed to execute the Smalltalk-80 system much faster than existing VLSI microcomputers. The Smalltalk-80 system is a highly productive programming environment but poses tough challenges for implementors: dynamic data typing, a high level instruction set, frequent and expensive procedure calls, and object-oriented storage management. SOAR compiles programs to a low level, efficient instruction set. Parallel tag checks permit high performance for the simple common cases and cause traps to software routines for the complex cases. Parallel register initialization and multiple on-chip register windows speed procedure calls. Sophisticated software techniques relieve the hardware of the burden of managing objects. We have initial evaluations of the effectiveness of the SOAR architecture by compiling and simulating benchmarks, and will prove SOAR's feasibility by fabricating a 35,000-transistor SOAR chip. These earl...

2011

Paper presented at 10th ACM SIGPLAN Int. Workshop on Virtual Machines and Intermediate Languages (see http://design.cs.iastate.edu/vmil/2011/index.html) but not archived as part of the proceedings.

Information and Software Technology, 1991

Sigplan Notices, 1989

Computational reflection makes it easy to solve problems that are otherwise difficult to address in Smalltalk-80, such as the construction of monitors, distributed objects, and futures, and can allow experimentation with new inheritance, delegation, and protection schemes. FulI reflection is expensive to implement. However, the ability to override method lookup can bring much of the power of reflection to languages like Smalltalk-at IXJ cost in efficiency.

ACM SIGPLAN Notices, 1987

The Smalltalk programming language allows contexts (stack frames) to be accessed and manipulated in very general ways. This sometimes requires that contexts be retained even after they have terminated executing, and that they be reclaimed other than by LIFO stack discipline. The authoritative de nition of Smalltalk Goldberg and Robson 83] uses reference counting garbage collection to manage contexts, an approach found to be inadequate in practice Krasner, et al. 83]. Deutsch and Schiman have described a technique that uses an actual stack as much as possible Deutsch and Schiman 84]. Here we o er a less complex technique that we expect will have lower total overhead and reclaim many frames sooner and more easily. We are implementing our technique as part of a state of the art Smalltalk interpreter. The approach may apply to other languages that allow indenite lifetimes for execution contexts, be they interpreted or compiled.

Science of Computer Programming, 2005

Virtual machines (VMs) are a popular target for language implementers. A longrunning question in the design of virtual machines has been whether stack or register architectures can be implemented more efficiently with an interpreter. Many designers favour stack architectures since the location of operands is implicit in the stack pointer. In contrast, the operands of register machine instructions must be specified explicitly. In this paper, we present a working system for translating stackbased Java virtual machine (JVM) code to a simple register code. We describe the translation process, the complicated parts of the JVM which make translation more difficult, and the optimisations needed to eliminate copy instructions. Experimental results show that a register format reduced the number of executed instructions by 34.88%, while increasing the number of bytecode loads by an average of 44.81%. Overall, this corresponds to an increase of 2.32 loads for each dispatch removed. We believe that the high cost of dispatches makes register machines attractive even at the cost of increased loads.

Virtual machines (VMs) are commonly used to distribute programs in an architecture-neutral format, which can easily be interpreted or compiled. A long-running question in the design of VMs is whether stack architecture or register architecture can be implemented more efficiently with an interpreter. We extend existing work on comparing virtual stack and virtual register architectures in two ways. Firstly, our translation from stack to register code is much more sophisticated. The result is that we eliminate an average of more than 47% of executed VM instructions, with the register machine bytecode size only 25% larger than that of the corresponding stack bytecode. Secondly we present an implementation of a register machine in a fully standardcompliant implementation of the Java VM. We find that, on the Pentium 4, the register architecture requires an average of 32.3% less time to execute standard benchmarks if dispatch is performed using a C switch statement. Even if more efficient threaded dispatch is available (which requires labels as first class values), the reduction in running time is still approximately 26.5% for the register architecture.

The Squeak Smalltalk virtual machine is used in several projects (Squeak, Pharo, Cuis, Context, NewSpeak) and has software implementations including the original interpreter, SqueakR (PyPy), SqueakJS (Javasscript) and Cog (JIT compiler) plus Sista (bytecode optimizer). SiliconSqueak is a microcoded-like processor with four caches which can be implemented in an FPGA or an ASIC to efficiently support both interpreters and adaptive compilation.

Software: Practice and Experience, 2020

SummaryOpenSmalltalk‐VM is a virtual machine (VM) for languages in the Smalltalk family (eg, Squeak and Pharo), which is itself written in a subset of Smalltalk that can easily be translated to C. VM development is done in Smalltalk, an activity we call “simulation.” The production VM is then derived by translating the core VM code to C. As a result, two execution models coexist: simulation, where the Smalltalk code is executed on top of a Smalltalk VM, and production, where the same code is compiled to an executable through a C compiler. The whole VM execution can be simulated: the heap is represented as a huge byte array, the VM code is executed as Smalltalk, and the native code generated by the just‐in‐time (JIT) compiler is executed by a processor simulator. All the Smalltalk development tools, such as the debugger, are then available while simulating. In addition, in simulation, it is also possible to use debugging features such as single stepping in the machine code generated ...

AbstractÐTechnological trends require that future scalable microprocessors be decentralized. Applying these trends toward memory systems shows that the size of the cache accessible in a single cycle will decrease in a future generation of chips. Thus, a bankexposed memory system comprised of small, decentralized cache banks must eventually replace that of a monolithic cache. This paper considers how to effectively use such a memory system for sequential programs. This paper presents Maps, the software technology central to bank-exposed architectures, which are architectures with bank-exposed memory systems. Maps solves the problem of bank disambiguationÐthat of determining at compile-time which bank a memory reference is accessing. Bank disambiguation is important because it enables the compile-time optimization for data locality, where data can be placed close to the computation that requires it. Two methods for bank disambiguation are presented: equivalence-class unification and modulo unrolling. Experimental results are presented using a compiler for the MIT Raw machine, a bank-exposed architecture that relies on the compiler to 1) manage its memory and 2) orchestrate its instruction level parallelism and communication. Results on Raw using sequential codes demonstrate that using bank disambiguation improves performance by a factor of 3 to 5 over using ILP alone.