Stack machine

Abstract: An apparatus for providing feedback to a user of a weight stack machine having weights for lifting has an enclosure adapted for attachment to the weight stack machine. Means for sensing weight for determining the number of weights lifted is provided as well as encoder means for detecting the motion of the weights during a lift. Electronic detection means are operatively coupled to the weight sensors means and the encoder means for computing data describing the number of weights lifted. Interface means for transmitting the computed data from the electronic detection means to a central storage means and the display is provided. The interface means also receives information from the central storage means and displays it on the display.

Abstract: Virtual machines (VMs) enable the distribution of programs in an architecture-neutral format, which can easily be interpreted or compiled. A long-running question in the design of VMs is whether a 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 three ways. First, our translation from stack to register code and optimization are much more sophisticated. The result is that we eliminate an average of more than 46p of executed VM instructions, with the bytecode size of the register machine being only 26p larger than that of the corresponding stack one. Second, we present a fully functional virtual-register implementation of the Java virtual machine (JVM), which supports Intel, AMD64, PowerPC and Alpha processors. This register VM supports inline-threaded, direct-threaded, token-threaded, and switch dispatch. Third, we present experimental results on a range of additional optimizations such as register allocation and elimination of redundant heap loads. On the AMD64 architecture the register machine using switch dispatch achieves an average speedup of 1.48 over the corresponding stack machine. Even using the more efficient inline-threaded dispatch, the register VM achieves a speedup of 1.15 over the equivalent stack-based VM.

Abstract: Despite achieving tremendous success, existing deep learning models have exposed limitations in compositional generalization, the capability to learn compositional rules and apply them to unseen cases in a systematic manner. To tackle this issue, we propose the Neural-Symbolic Stack Machine (NeSS). It contains a neural network to generate traces, which are then executed by a symbolic stack machine enhanced with sequence manipulation operations. NeSS combines the expressive power of neural sequence models with the recursion supported by the symbolic stack machine. Without training supervision on execution traces, NeSS achieves 100% generalization performance in four domains: the SCAN benchmark of language-driven navigation tasks, the task of few-shot learning of compositional instructions, the compositional machine translation benchmark, and context-free grammar parsing tasks.

Abstract: The Functional Abstract Machine (Fam) is a stack machine designed to support functional languages on large address space computers It can be considered a SECD machine [1] which has been optimized to allow very fast function application and the use of true stacks (as opposed to linked lists) The machine qualifies to be called functional because it supports functional objects (closures, which are dynamically allocated and garbage collected), and aims to make function application as fast as, say, taking the head of a list All the optimization and support techniques which make application slower are strictly avoided, while tail recursion and pattern-matching calls are supported Restricted side effects and arrays are provided, but they are less efficient than one might expect Moreover the performance of the proposed garbage collector deteriorates in the presence of large numbers of updatable objects The machine is intended to make compilation from high level languages easy and regular, by providing a rich and powerful set of operations and an open-ended collection of data types This richness of types can also facilitate portability, because every type can be independently implemented in different ways However the number of machine instructions tends to be high, and in general there is little concern for minimality The instructions of the machine are not supposed to be interpreted, but assembled into machine code and then executed This explains why no optimized special-case operations are provided; special cases can be easily detected at assembly time For efficiency considerations, the abstract machine is not supposed to perform runtime type checking (even if a hardware implementation of it might), and hence it is not type-safe Moreover, as a matter of principle, there is no primitive to test the type of an object; the correct application of machine operations should be guaranteed by typechecking in the source language Where needed, the effect of run-time typechecking can be achieved by the use of variant (ie tagged) data types