diff --git a/src/ieee.csl b/src/ieee.csl new file mode 100644 index 0000000..bb58f0e --- /dev/null +++ b/src/ieee.csl @@ -0,0 +1,512 @@ + + diff --git a/src/main.md b/src/main.md index c42a305..f943500 100644 --- a/src/main.md +++ b/src/main.md @@ -221,7 +221,7 @@ This storage area is accompanied by data indicating the position from which the However, in the case of higher-order functions that receive a function as an argument and return another function, the layout of the internal state of the given function is unknown at the compilation, so an internal state storage area is created for each instantiated closure separately from the global storage area held by the VM instance itself. The VM switches the `State_Ptr`, which points the internal state storage to be used, at each closure call, to the storage area on the closure, and returns a pointer pointing to the global storage area each time the closure context ends. -Instantiated closures also hold the storage area of Upvalues. Until the closure exits the context of the parent function (Open Closure), Upvalues holds a negative offset on the stack at the ongoing execution. Because this offset value can be determined at compile time, stored in the function prototype in the program. For instance, if the Upvalue indexes in the program were `[4,3]`, `GETUPVALUE 6 1` means that, take `3` from the upvalue indexes and get value from `R(-2)` (3-5) over the base pointer and store it to `R(6)`. +Instantiated closures also hold the storage area of Upvalues. Until the closure exits the context of the parent function ("Open Closure"), Upvalues holds a negative offset on the stack at the ongoing execution. Because this offset value can be determined at compile time, stored in the function prototype in the program. For instance, if the Upvalue indexes in the program were `[4,3]`, `GETUPVALUE 6 1` means that, take `3` from the upvalue indexes and get value from `R(-2)` (3-5) over the base pointer and store it to `R(6)`. When the closure escapes from the original function with\ `RETURN` instruction, inserted `CLOSE` instruction before the return, which causes, Actual upvalues are moved from stack to somewhere on the heap memory. This Upvalue may be referenced from multiple locations when using nested closures, and some form of garbage collection needed to free memory after it is no longer referred. @@ -247,11 +247,11 @@ CONSTANTS:[1.0] RETURN 3 1 ``` -Listing [\[lst:bytecodes_onepole\]](#lst:bytecodes_onepole){reference-type="ref" reference="lst:bytecodes_onepole"} shows an basic example when the *mimium* code in Listing [\[lst:onepole\]](#lst:onepole){reference-type="ref" reference="lst:onepole"} is compiled into VM bytecode. When `self` is referenced, the value is obtained with the `GETSTATE` instruction, and the internal state is updated by storing the return value with the `SETSTATE` instruction before returning the value with `RETURN` from the function. Here, the actual return value is obtained by the second `GETSTATE` instruction in order to return the initial value of the internal state when time=0. +Listing [\[lst:bytecodes_onepole\]](#lst:bytecodes_onepole) shows an basic example when the *mimium* code in Listing [\[lst:onepole\]](#lst:onepole) is compiled into VM bytecode. When `self` is referenced, the value is obtained with the `GETSTATE` instruction, and the internal state is updated by storing the return value with the `SETSTATE` instruction before returning the value with `RETURN` from the function. Here, the actual return value is obtained by the second `GETSTATE` instruction in order to return the initial value of the internal state when time=0. -For example, when a time counter is written as `| | {self + 1}`, it is the compiler's design choice whether the return value of time=0 should be 0 or 1 though the latter does not strictly follow the semantics E-FEED in Figure [\[fig:semantics\]](#fig:semantics){reference-type="ref" reference="fig:semantics"}. If the design is to return 1 when time = 0, the second `GETSTATE` instruction can be removed and the value for the `RETURN` instruction should be `R(2)`. +For example, when a time counter is written as `| | {self + 1}`, it is the compiler's design choice whether the return value of time=0 should be 0 or 1 though the latter does not strictly follow the semantics E-FEED in Figure [\[fig:semantics\]](#fig:semantics). If the design is to return 1 when time = 0, the second `GETSTATE` instruction can be removed and the value for the `RETURN` instruction should be `R(2)`. -A more complex example code and its expected bytecode instructions are shown in Listing [\[lst:fbdelay\]](#lst:fbdelay){reference-type="ref" reference="lst:fbdelay"} and Listing [\[lst:bytecodes_fbdelay\]](#lst:bytecodes_fbdelay){reference-type="ref" reference="lst:bytecodes_fbdelay"}. The codes define delay with a feedback as `fbdelay`, the other function `twodelay` uses two feedback delay with different parameters, and `dsp` finally uses two `twodelay` function. +A more complex example code and its expected bytecode instructions are shown in Listing [\[lst:fbdelay\]](#lst:fbdelay) and Listing [\[lst:bytecodes_fbdelay\]](#lst:bytecodes_fbdelay). The codes define delay with a feedback as `fbdelay`, the other function `twodelay` uses two feedback delay with different parameters, and `dsp` finally uses two `twodelay` function. Each after the referring to `self` through `GETSTATE` instruction, or call to the other statefull function,\ `SHIFTSTATE` instruction inserted to move the `StatePtr` forward to prepare the next non-closure function call. Before exits function, `StatePtr` is reset to the same position as that the current function context has begun by `SHIFTSTATE` (A sum of the operand for `SHIFTSTATE` in a function must be always 0). @@ -321,11 +321,11 @@ RETURN 1 1 Because *mimium* treats functions that have internal states which change over time, when higher-order functions are used, there is a counterintuitive behavior compared to general functional programming languages. -An example is the higher-order function `filterbank`, which duplicates `filter` function `N` times parametrically, and adds them together. Listing [\[lst:filterbank_bad\]](#lst:filterbank_bad) is an example of an incorrect code, and Listing [\[lst:filterbank_good\]](#lst:filterbank_good) is an example of the code that behave correctly. The difference between Listing [\[lst:filterbank_bad\]](#lst:filterbank_bad){reference-type="ref" reference="lst:filterbank_bad"} and Listing [\[lst:filterbank_good\]](#lst:filterbank_good)is that the recursive calls in the filterbank function are written directly in the inner function to be returned, and the recursive calls in the filterbank function are written with `let` binding out of the inner function[^2]. Similarly, in the `dsp` function that will be called by the audio driver in *mimium*, the difference is whether the filterbank function is executed inside `dsp` or bound with `let` once in the global context. +An example is the higher-order function `filterbank`, which duplicates `filter` function `N` times parametrically, and adds them together. Listing [\[lst:filterbank_bad\]](#lst:filterbank_bad) is an example of an incorrect code, and Listing [\[lst:filterbank_good\]](#lst:filterbank_good) is an example of the code that behave correctly. The difference between Listing [\[lst:filterbank_bad\]](#lst:filterbank_bad) and Listing [\[lst:filterbank_good\]](#lst:filterbank_good)is that the recursive calls in the filterbank function are written directly in the inner function to be returned, and the recursive calls in the filterbank function are written with `let` binding out of the inner function[^2]. Similarly, in the `dsp` function that will be called by the audio driver in *mimium*, the difference is whether the filterbank function is executed inside `dsp` or bound with `let` once in the global context. -In the case of normal functional language, if all the functions used in a composition do not contain destructive assignments, the calculation process will not change even if the variable bound by `let` is manually replaced with its term (beta reduction), as in the conversion from Listing [\[lst:filterbank_good\]](#lst:filterbank_good) to Listing [\[lst:filterbank_bad\]](#lst:filterbank_bad){reference-type="ref" reference="lst:filterbank_bad"}. +In the case of normal functional language, if all the functions used in a composition do not contain destructive assignments, the calculation process will not change even if the variable bound by `let` is manually replaced with its term (beta reduction), as in the conversion from Listing [\[lst:filterbank_good\]](#lst:filterbank_good) to Listing [\[lst:filterbank_bad\]](#lst:filterbank_bad). -But in *mimium*, there are two major stages of evaluation, 0: the code is evaluated in the global environment (concretizing the signal processing graph) at first, and 1: the dsp function is repeatedly executed (actual signal processing) and the function may involve implicit internal state updates. Therefore, even though the code does not include destructive assignments, the recursive execution of the `filterbank` function is performed only once in Listing [\[lst:filterbank_good\]](#lst:filterbank_good){reference-type="ref" reference="lst:filterbank_good"} for the evaluation of the global environment, whereas in Listing [\[lst:filterbank_bad\]](#lst:filterbank_bad){reference-type="ref" reference="lst:filterbank_bad"}, every sample the dsp function is executed, the recursive function is executed and a closure is generated. Since the initialization of the internal state in the closure is performed at the time of closure allocation, in the example of Listing[\[lst:filterbank_bad\]](#lst:filterbank_bad){reference-type="ref" reference="lst:filterbank_bad"}, the internal state of the closure after the evaluation of `filterbank` is reset at each time step. +But in *mimium*, there are two major stages of evaluation, 0: the code is evaluated in the global environment (concretizing the signal processing graph) at first, and 1: the dsp function is repeatedly executed (actual signal processing) and the function may involve implicit internal state updates. Therefore, even though the code does not include destructive assignments, the recursive execution of the `filterbank` function is performed only once in Listing [\[lst:filterbank_good\]](#lst:filterbank_good) for the evaluation of the global environment, whereas in Listing [\[lst:filterbank_bad\]](#lst:filterbank_bad), every sample the dsp function is executed, the recursive function is executed and a closure is generated. Since the initialization of the internal state in the closure is performed at the time of closure allocation, in the example of Listing[\[lst:filterbank_bad\]](#lst:filterbank_bad), the internal state of the closure after the evaluation of `filterbank` is reset at each time step. ```rust {#lst:filterbank_bad .Rust float="" floatplacement="H" label="lst:filterbank_bad" language="Rust" caption="\\it Wrong example of the code that duplicate filter parametrically."} fn bandpass(x,freq){ @@ -376,7 +376,7 @@ fn filterbank(n,filter){ This means that the major compiler optimization techniques such as the constant folding and the function inlining can not simply be appropriated. Those optimizations should be done after the evaluation of a global context and before evaluating `dsp` function. -To solve this situation, introducing distinction whether the term should be used in global context evaluation(Stage 0) and in the actual signal processing(stage 1) in type system. This can be realized with Multi-Stage Computation[@Taha1997]. Listing [\[lst:filterbank_multi\]](#lst:filterbank_multi){reference-type="ref" reference="lst:filterbank_multi"} is the example of `filterbank` code using BER MetaOCaml's syntaxes `..` which will generate evaluated program used in a next stage, and `~term` which embed terms evaluated at the previous stage[@kiselyov2014a]. +To solve this situation, introducing distinction whether the term should be used in global context evaluation(Stage 0) and in the actual signal processing(stage 1) in type system. This can be realized with Multi-Stage Computation[@Taha1997]. Listing [\[lst:filterbank_multi\]](#lst:filterbank_multi) is the example of `filterbank` code using BER MetaOCaml's syntaxes `..` which will generate evaluated program used in a next stage, and `~term` which embed terms evaluated at the previous stage[@kiselyov2014a]. `filterbank` function is evaluated in stage 0 while embedding itself by using `~`. @@ -384,7 +384,7 @@ This multi-stage computation code has a same semantics in a generative signal gr # Conclusion -[\[sec:conclusion\]](#sec:conclusion){reference-type="ref" reference="sec:conclusion"} +[\[sec:conclusion\]](#sec:conclusion) This paper proposed $\lambda_{mmm}$, an intermediate representation for the programming languages for music and signal processing with the virtual machine and instruction set to run it. $\lambda_{mmm}$enables to describe generative signal graph and its contents in a single syntax and semantics. However, user have to be responsible to write codes that does not create escapable closures during the dsp execution and this problem would be difficult to understand by novice users. @@ -396,3 +396,6 @@ JP19K21615). Also great thanks for many anonymous reviewers. [^1]: Reason for this is that it is easy to implemented on `enum` data structure on Rust, a host language of the latest *mimium* compiler. Operands bitwidth and alignment may be changed in the future. [^2]: In the previous specification of *mimium* in [@matsuura2021a], the binding of new variable and destructive assignment were the same syntax(`x = a`) but the syntax for the variable binding has changed to use `let` keyword. + +::: {#refs} +::: \ No newline at end of file diff --git a/src/main_cite.md b/src/main_cite.md new file mode 100644 index 0000000..623333e --- /dev/null +++ b/src/main_cite.md @@ -0,0 +1,436 @@ +## ABSTRACT + +This paper proposes $\lambda_{mmm}$:a call-by-value simply-typed lambda calculus-based intermediate representation of programming languages for music that deal with synchronous signal processing, as well as a virtual machine and instruction set to run $\lambda_{mmm}$. Digital signal processing can be represented with a syntax that incorporates the internal states of delay and feedback into the lambda calculus. $\lambda_{mmm}$ is defined as a superset of the lambda calculus, which allows users to construct a generative signal processing graph and its execution in an identical semantics. On the other hand, due to its specification, a problem was found that when dealing with higher-order functions, the users have to determine whether they are executed in the global environment evaluation or in the DSP execution, and a solution was proposed by introducing multi-stage computation. + +# Introduction {#sec:intro} + +A number of programming languages for sound and music have been developed to date, but not many have strongly formalised semantics. One language that is both rigorously formalised and practical is Faust \[1\], which combines blocks with inputs and outputs with five primitive operations - parallel, sequential, split, merge and recursive connection. By having basic arithmetics and delay as a primitive block, any type of signal processing can be written in Faust. In a later extension, macros based on a term rewriting system has introduced that allows the higher abstraction of systems with an arbitrary number of inputs and outputs \[2\]. + +This strong abstraction capability through formalisation enables Faust to be translated to various backends, such as C++ and Rust. On the other hand, BDA lacks theoretical and practical compatibility with common programming languages: although it is possible to call external C functions in Faust, the assumption is basically pure function calls without memory allocation and deallocation. Therefore, while it is easy to embed Faust in another language, it is not easy to call another language from Faust. + +In addition, macros in Faust are independent as a term rewriting system that generates BDA based on pattern matching. Therefore, even though the distinction between real and integer types does not exist in BDA, the arguments for pattern matching implicitly required to be an integer, which causes compile errors. This implicit typing rules are not intuitice for novice users. + +Proposing a computational model for signal processing that is based on the more generic computational models, such as the lambda calculus has the potential to interoperate between many different general-purpose languages, and also facilitate the appropriation of existing optimisation methods and the implementation of compilers and run-time. + +Currently, it has been proved that BDA can be converted to a general-purpose functional language in the form of using Arrows, a higher-level abstraction of monads\[3\]. But higher-order functions on general-purpose functional languages are often implemented on the basis of dynamic memory allocation and release, which makes it difficult to use them in host languages for the real-time signal processing. + +Also, Kronos \[4\] and W-calculus \[5\] are examples of attempts at lambda calculus-based abstraction, while being influenced by Faust. Kronos is based on the theoretical foundation of System-$F\omega$, a lambda computation in which the type itself is the object of the lambda abstraction (a function can be defined that computes the type and returns a new type). The W-calculus limits the systems it represents to linear time-invariant ones and defines a more formal semantics, aiming at automatic proofs of the linearlity and an identity of graph topologies. + +Previously, the author designed a programming language for music *mimium* \[6\]. It adds the basic operations of delay and feedback to lambda-calculus, signal processing can be expressed concisely while having a syntax close to that of general-purpose programming languages(especially, the syntax of *mimium* is designed to be looks like Rust language). + +One of the previous issues with *mimium* was the inability to compile the codes which contains a combination of recursive or higher-order functions and stateful functions because the compiler can not be determine the data size of the internal state of the signal processing. + +In this paper, the syntax and semantics of $\lambda_{mmm}$, a superset of the call-by-value simply-typed lambda calculus are explained, as a computation model that is supposed to be an intermediate representation of *mimium*. Also, a virtual machine and its instruction set are proposed to execute this computation model practically. Lastly, a space for optimization for running *mimium* using $\lambda_{mmm}$will be discussed. + +# Syntax {#sec:syntax} + +$$ +\begin{aligned} +\tau_p ::= & R\ &[real] \\ + \ | & N\ &[nat] \\ +\tau ::= & \tau_p\ & \\ + \ | & \tau \to \tau \ &[function] \\ + % |&\quad \langle \tau \rangle +\end{aligned} +$$ + +$$ +\begin{aligned} + v_p \; ::=& \ r \quad r \in \mathbb{R} \\ + |& \ n \quad n \in \mathbb{N}\\ + v \; ::=&\ v_p \\ + |& \ cls(\lambda\ x.e, E) \\ + %%|& \quad (e_1,e_2) \quad & [product]\\ + %%|& \quad \pi_n e \quad n\in \mathbb{N},\; n>0 \quad & [project]\\ + %%|& \quad \langle e \rangle \quad & [code] \\ + %%|& \quad \textasciitilde e \quad & [escape] +\end{aligned}$$ + +$$ +\begin{aligned} +e \; ::=& \ x &x \in {v_p} \ & [value]\\ + |& \ \lambda x.e & & [lambda]\\ + |& \ let\; x = e_1\; in\; e_2 & & [let]\\ + |& \ fix \; x.e & & [fixpoint]\\ + |& \ e_1 \; e_2 & & [app]\\ + |& \ if\; (e_c)\; e_t\; else\; e_e \; & & [if] \\ + |& \ delay\; n \; e_1 \; e_2 &n \in \mathbb{N}\ & [delay]\\ + |& \ feed \; x.e & & [feed]\\ + |& ... & & \\ + %%|& \quad (e_1,e_2) \quad & [product]\\ + %%|& \quad \pi_n e \quad n\in \mathbb{N},\; n>0 \quad & [project]\\ + %%|& \quad \langle e \rangle \quad & [code] \\ + %%|& \quad \textasciitilde e \quad & [escape] +\end{aligned} +$$ +```{=html} +
+``` +[]{#fig:syntax_v label="fig:syntax_v"}``{=html}Figure 1. Definition of Types, Values and Terms of the [``{=html}λ``{=html}``{=html}``{=html}m``{=html}``{=html}m``{=html}``{=html}m``{=html}``{=html}]{.math .inline}(Basic arithmetics are omitted).``{=html} +```{=html} +
+``` +```{=html} + +``` +Definition of types and terms of the $\lambda_{mmm}$ are shown in Figure [1](#fig:syntax_v). + +Two terms are added in addition to the usual simply-typed lambda calculus, $delay e_1 e_2$ that refers a previous value of $e_1$ to $e_2$ sample before, and $feed x.e$ abstraction that the user can refer the result of the evaluation of the $e$ one unit time before as $x$ during the evaluation of $e$ itself. + +## Syntactic sugar of the feedback expression in *mimium* {#sec:mimium} + +``` rust +fn onepole(x,g){ + x*(1.0-g) + self*g + } +``` + +[*Listing 1. Example of the code of one-pole filter in mimium.*]{#lst:onepole} + +*mimium* by the author has a keyword $self$ that can be used in function definition, that refers to the previous return value of the function. The example code of the simple one-pole filter function is shown in Listing [1](#lst:onepole). This code can be expressed in $\lambda_{mmm}$ as Figure [2](#fig:onepole){reference-type="ref" reference="fig:onepole"}. + +$$ +\begin{aligned} + let\ & onepole = \\ + & \ \lambda x. \lambda g.\ feed\ y.\ x *(1.0 - g) + y * g \ in\ ... +\end{aligned} +$$ +```{=html} +
+``` +[]{#fig:onepole label="fig:onepole"}``{=html}Equivalent expression to Listing ``{=html}\[lst:onepole\]``{=html} in [``{=html}λ``{=html}``{=html}``{=html}m``{=html}``{=html}m``{=html}``{=html}m``{=html}``{=html}]{.math .inline}.``{=html} +```{=html} +
+``` +```{=html} + +``` +## Typing Rule {#sec:typing} + +\$\$ +```{=tex} +\begin{gathered} +\frac{\Gamma, x:\tau_a \vdash e:\tau_b}{\Gamma \vdash \lambda x.e:\tau_a \to \tau_b }\ \textrm{[T-LAM]}\\ +\frac{ \Gamma \vdash e_1:N \quad \Gamma \vdash e_2:\tau }{\Gamma \vdash delay\ e_1\ e_2 : \tau}\ \textrm{[T-DELAY]}\\ + +\frac{\Gamma, x : \tau_p \vdash e: \tau_p }{\Gamma \vdash feed\ x.e:\tau_p} \textrm{[T-FEED]}\\ + + +\frac{ \Gamma \vdash e_c : R\quad \Gamma \vdash e_t:\tau\quad \Gamma \vdash e_e:\tau }{\Gamma \vdash if\ (e_c)\ e_t\ e_e\ : \tau}\ \textrm{[T-IF]}\\ +\end{gathered} +``` +\$\$ + +```{=html} +
+``` +[]{#fig:typing label="fig:typing"}``{=html}Figure 3. Excerpt of the typing rules for [``{=html}λ``{=html}``{=html}``{=html}m``{=html}``{=html}m``{=html}``{=html}m``{=html}``{=html}]{.math .inline}.``{=html} +```{=html} +
+``` +```{=html} + +``` +Additional typing rules to usual simply-typed lambda calculus are shown in Figure [3](#fig:typing). + +As primitive types, there are a real number type to used in most of signal processing and a natural number type that is used to indice of delay. + +In the W-calculus, a starting point of designing $\lambda_{mmm}$, function types can takes tuples of real numbers and return tuples of real numbers. This means that higher-order functions cannot be written. While this restriction is reasonable as a design choice for a language for signal processing since higher-order functions require data structures that require dynamic memory allocation, such as closures, for their implementation, it also lacks the generality of the lambda calculus. + +In $\lambda_{mmm}$, the problem of memory allocation for closures is left to the implementation of the runtime in the Section[4](#sec:vm), and higher-order functions are allowed. However, the $feed$ abstraction does not allow function types as its input and output. Allowing the return of function types in the $feed$ abstraction means that it is possible to define functions whose processing contents change time-to-time. While this may be interesting theoritically, there are currently no practical cases in real-world signal processing, and it is expected to further complicate implementations. + +# Semantics {#sec:semantics} + +\$\$ +```{=tex} +\begin{gathered} +& +\frac{E^n \vdash e_1 \Downarrow v_1 \ n>v_1 \ E^{n-v_1} \vdash e_2 \Downarrow v_2}{E^n \vdash\ delay\ n\ e_1\ e_2 \Downarrow v_2}\ &\textrm{[E-DELAY]} \\ + +& +\frac{}{E^n \vdash\ \lambda x.e \Downarrow cls(\lambda x.e , E^n) }\ &\textrm{[E-LAM]} \\ + +& +\frac{ E^{n-1} \vdash e \Downarrow v_1\ E^n, x \mapsto v_1 \vdash e \Downarrow v_2 }{E^n, x \mapsto v_2\ \vdash\ feed\ x\ e \Downarrow v_1}\ &\textrm{[E-FEED]} \\ + +& +\frac{E^n \vdash e_c \Downarrow n \quad n > 0\ E^n \vdash e_t\ \Downarrow v\ }{E^n \vdash\ if (e_c)\ e_t\ else\ e_t \Downarrow v }\ &\textrm{[E-IFTRUE]}\\ + +& +\frac{E^n \vdash e_c \Downarrow n \quad n \leqq0\ E^n \vdash e_e\ \Downarrow v\ }{E^n \vdash\ if (e_c)\ e_t\ else\ e_t \Downarrow v }\ &\textrm{[E-IFFALSE]}\\ + +& +\frac{E^n \vdash e_1 \Downarrow cls(\lambda x_c.e_c, E^n_c) E^n \vdash e_2 \Downarrow v_2\ E^n_c,\ x_c \mapsto v_2 \vdash e_c \Downarrow v }{E^n \vdash\ e_1\ e_2 \Downarrow v }\ &\textrm{[E-APP]} +\end{gathered} +``` +\$\$ + +The excerpt of operational semantics of the $\lambda_{mmm}$is shown in Figure [\[fig:semantics\]](#fig:semantics){reference-type="ref" reference="fig:semantics"}. This big-step semantics is a conceptual explanation of the evaluation that, when the current time is $n$, the previous evaluation environment $t$ samples before can be referred to as $E^{n-t}$ , and that when the time \< 0, the evaluation of any term is evaluated to the default value of its type (0 for the numeric types). + +Of course, if we tried to execute this semantics in a straightforward manner, we would have to redo the calculation from time 0 to the current time every sample, with saving all the variable environments at each sample. In practice, therefore, a virtual machine is defined that takes into account the internal memory space used by delay and feed, and the $\lambda_{mmm}$terms are converted into instructions for that machine before execution. + +# VM Model and Instruction Set {#sec:vm} + +A model for the virtual machine and its instruction set to run $\lambda_{mmm}$ is based on Lua version 5.0\[7\]. + +When executing a computational model based on lambda calculus, the problem is how to handle a data structure called a closure that captures the variable environment where the inner function is defined, to refer the outer variables from the inner function context. If the dictionary data of names and values of variables are paired with inner function, implementation of the compiler(intepreter) is simple, but run-time performance is limited. + +On the contrary, a runtime performance can be improved by performing a process called closure transformation (or lambda lifting), which analyses all the names of outer variables referred by the inner function and transforms the inner function by adding argument so that the variables can be referred explicitly, but the compiler implementation of the transformation is relatively complex. + +The Lua VM takes an intermediate approach between these two by adding the VM instructions `GETUPVALUE` / +`SETUPVALUE`, which allows the outer variables to be referenced dynamically at runtime. The implementation of compiler and VM using *Upvalue* is simpler than closure conversion, while at the same time preventing execution performance degradation, as outer variables can be referenced via the call stack rather than on the heap memory unless the closure object escapes from the context of the original function\[8\]. + +Also, Upvalue helps interoperations between other programming languages, as Lua can be easily embedded through C language API and when implementing external libraries in C, programmer can access to upvalues of Lua Runtime not only the stack values in C API. + +## Instruction Set {#sec:instruction} + +VM Instructions for $\lambda_{mmm}$ differs from Lua VM in the following respects. + +1. Since *mimium* is a statically typed language unlike Lua, instructions for basic arithmetics are provided for each type. + +2. The call operation is separated into the normal function call and the call of closure to handle higher-order statefull functions(See [4.2](#sec:vmstructure){reference-type="ref" reference="sec:vmstructure"} for details). + +3. If statements are realised by a combination of two instructions, `JMP` and `JMPIFNEG`, whereas the Lua VM uses a dedicated `TEST` instruction. + +4. Instructions related to for loop, the `SELF` instruction used for object-oriented programming and the `TABLE`-related instructions for metadata references to variables are omitted in *mimium* as they are not used. + +5. Instructions related to list-related data structures are also omitted in this paper, as the implementation of data structures such as tuples and arrays was omitted in the description of the $\lambda_{mmm}$ in this paper. + +Instructions in $\lambda_{mmm}$ VM are 32bit data with operation tag and 3 operands. Currently, a bit width for the tag and each operands are all 8 bit[^1]. + +The VM of $\lambda_{mmm}$ is a register machine like the Lua VM after version 5, although the VM has no real register but the register number simply means the offset index of the call stack from the base pointer at the point of execution of the VM. The first operand of most instructions is the register number in which to store the result of the operation. + +The list of instructions is shown in Figure [\[fig:instruction\]](#fig:instruction) (basic arithmetic operations are partly omitted). The notation for the instruction follows the Lua VM paper \[7, p. 13\]. From left to right, the name of operation, a list of operands, and pseudo-code of the operation. When using each of the three operands as unsigned 8 bits, they are denoted as `A B C`. When used with a signed integer, prefix `s` is added, and when the two operand fields are used as one 16 bits, an suffix `x` is added. For example, when B and C are merged and treated as signed 16 bits, they are denoted as `sBx`. + +In pseudo-code describing an functionality, `R(A)` means that data is moved in and out through the register (call stack) according to the numerical value of the operand `A`. `K(A)` means that it retrieves the `A`-th number in the static variable field of the compiled programm. `U(A)` means that referring `A`-th Upvalue of the current function. + +In addition to Lua's Upvalue operation, 4 operations related to internal state variables over time, `GETSTATE`, `SETSTATE`, +`SHIFTSTATE` and `DELAY` are added. + + MOVE A B R(A) := R(B) + MOVECONST A B R(A) := K(B) + GETUPVALUE A B R(A) := U(B) + SETUPVALUE A B U(B) := R(A) + GETSTATE A R(A) := SPtr[SPos] + SETSTATE A Sptr[SPos] := R(A) + SHIFTSTATE sAx SPos += sAx + DELAY A B R(A) := update_ringbuffer(SPtr[SPos],R(B)) + JMP sAx PC +=sAx + JMPIFNEG A sBx if (R(A)\<0) then PC += sBx + CALL A B C R(A),\...,R(A+C-2) := program.functions\[R(A)\](R(A+1),\...,R(A+B-1)) + CALLCLS A B C Sptr := vm.closures\[R(A)\].Sptr +     R(A),\...,R(A+C-2) := vm.closures\[R(A)\].fnproto(R(A+1),\...,R(A+B-1)) + Sptr := vm.global_sptr + CLOSURE A Bx vm.closures.push(closure(program.functions\[R(Bx)\])) R(A) := vm.closures.length - 1 + CLOSE A close stack variables up to R(A) + RETURN A B return R(A), R(A+1)\...,R(A+B-2) + ADDF A B C R(A) := R(B) as float + R(C) as float + SUBF A B C R(A) := R(B) as float - R(C) as float + MULF A B C R(A) := R(B) as float * R(C) as float + DIVF A B C R(A) := R(B) as float / R(C) as float + ADDF A B C R(A) := R(B) as int + R(C) as in + ...Other basic arithmetics continues for each primitive types... + +## Overview of the VM structure {#sec:vmstructure} + +The overview of a data structure of the VM, program and the instantiated closure for $\lambda_{mmm}$ is shown in Figure [\[fig:vmstructure\]](#fig:vmstructure){reference-type="ref" reference="fig:vmstructure"} . In addition to the normal call stack, the VM has a storage area for managing internal state data for feedback and delay. + +This storage area is accompanied by data indicating the position from which the internal state is retrieved by the `GETSTATE` / `SETSTATE` instructions. This position is modified by `SHIFTSTATE` operation. The the actual data in the state storage memory are statically layed out at compile time by analyzing function calls that include references to `self`, call of `delay` and the functions which will call such statefull functions recursively. + +However, in the case of higher-order functions that receive a function as an argument and return another function, the layout of the internal state of the given function is unknown at the compilation, so an internal state storage area is created for each instantiated closure separately from the global storage area held by the VM instance itself. The VM switches the `State_Ptr`, which points the internal state storage to be used, at each closure call, to the storage area on the closure, and returns a pointer pointing to the global storage area each time the closure context ends. + +Instantiated closures also hold the storage area of Upvalues. Until the closure exits the context of the parent function ("Open Closure"), Upvalues holds a negative offset on the stack at the ongoing execution. Because this offset value can be determined at compile time, stored in the function prototype in the program. For instance, if the Upvalue indexes in the program were `[4,3]`, `GETUPVALUE 6 1` means that, take `3` from the upvalue indexes and get value from `R(-2)` (3-5) over the base pointer and store it to `R(6)`. + +When the closure escapes from the original function with +`RETURN` instruction, inserted `CLOSE` instruction before the return, which causes, Actual upvalues are moved from stack to somewhere on the heap memory. This Upvalue may be referenced from multiple locations when using nested closures, and some form of garbage collection needed to free memory after it is no longer referred. + +![image](lambdammm_vm_structure.pdf) + +## Compilation to the VM instructions + +``` {#lst:bytecodes_onepole .rust float="" floatplacement="H" label="lst:bytecodes_onepole" caption="\\it Compiled VM instructions of one-pole filter example in Listing \\ref{lst:onepole}"} +CONSTANTS:[1.0] + fn onepole(x,g) state_size:1 + MOVECONST 2 0 // load 1.0 + MOVE 3 1 // load g + SUBF 2 2 3 // 1.0 - g + MOVE 3 0 // load x + MULF 2 2 3 // x * (1.0-g) + GETSTATE 3 // load self + MOVE 4 1 // load g + MULF 3 3 4 // self * g + ADDF 2 2 3 // compute result + GETSTATE 3 // prepare return value + SETSTATE 2 // store to self + RETURN 3 1 +``` + +Listing [\[lst:bytecodes_onepole\]](#lst:bytecodes_onepole) shows an basic example when the *mimium* code in Listing [\[lst:onepole\]](#lst:onepole) is compiled into VM bytecode. When `self` is referenced, the value is obtained with the `GETSTATE` instruction, and the internal state is updated by storing the return value with the `SETSTATE` instruction before returning the value with `RETURN` from the function. Here, the actual return value is obtained by the second `GETSTATE` instruction in order to return the initial value of the internal state when time=0. + +For example, when a time counter is written as `| | {self + 1}`, it is the compiler's design choice whether the return value of time=0 should be 0 or 1 though the latter does not strictly follow the semantics E-FEED in Figure [\[fig:semantics\]](#fig:semantics). If the design is to return 1 when time = 0, the second `GETSTATE` instruction can be removed and the value for the `RETURN` instruction should be `R(2)`. + +A more complex example code and its expected bytecode instructions are shown in Listing [\[lst:fbdelay\]](#lst:fbdelay) and Listing [\[lst:bytecodes_fbdelay\]](#lst:bytecodes_fbdelay). The codes define delay with a feedback as `fbdelay`, the other function `twodelay` uses two feedback delay with different parameters, and `dsp` finally uses two `twodelay` function. + +Each after the referring to `self` through `GETSTATE` instruction, or call to the other statefull function, +`SHIFTSTATE` instruction inserted to move the `StatePtr` forward to prepare the next non-closure function call. Before exits function, `StatePtr` is reset to the same position as that the current function context has begun by `SHIFTSTATE` (A sum of the operand for `SHIFTSTATE` in a function must be always 0). + +``` {#lst:fbdelay .rust .Rust float="" floatplacement="H" label="lst:fbdelay" language="Rust" caption="\\it Example code that combines self and delay without closure call."} +fn fbdelay(x,fb,dtime){ + x + delay(1000,self,dtime)*fb +} +fn twodelay(x,dtime){ + fbdelay(x,dtime,0.7) + +fbdelay(x,dtime*2,0.8) +} +fn dsp(x){ + twodelay(x,400)+twodelay(x,800) +} +``` + +``` {#lst:bytecodes_fbdelay .rust float="" floatplacement="H" label="lst:bytecodes_fbdelay" caption="\\it Compiled VM instructions of one-pole filter example in Listing \\ref{lst:fbdelay}"} +CONSTANTS:[0.7,2,0.8,400,800,0,1] +fn fbdelay(x,fb,dtime) state_size:2 +MOVE 3 0 +GETSTATE 4 +SHIFTSTATE 1 +DELAY 4 2 +MOVE 5 1 +MULF 4 4 5 +ADDF 3 3 4 +SHIFTSTATE -1 +GETSTATE 4 +SETSTATE 3 +RETURN 4 1 + +fn twodelay(x,dtime) state_size:4 +MOVECONST 2 5 //load "fbdelay" prototype +MOVE 3 0 +MOVE 4 1 +MOVECONST 5 0 //load 0.7 +CALL 2 3 1 +SHIFTSTATE 2 //=state_size of fbdelay +MOVECONST 3 5 //load "fbdelay" prototype +MOVE 4 0 +MOVECONST 5 1 //load 2 +MULF 4 4 5 +MOVECONST 5 0 //load 0.7 +CALL 3 3 1 +ADDF 3 3 4 +SHIFTSTATE -2 +RETURN 3 1 + +fn dsp (x) +MOVECONST 1 6 //load "twodelay prototype" +MOVE 2 0 +MOVECONST 3 3 //load 400 +CALL 1 2 1 +SHIFTSTATE 4 //=state_size of twodelay +MOVECONST 2 6 +MOVE 2 3 //load "twodelay prototype" +MOVE 3 0 +MOVECONST 3 4 //load 400 +CALL 2 2 1 +ADD 1 1 2 +SHIFTSTATE -4 +RETURN 1 1 +``` + +# Discussion : Different behaviour depending on the position of let binding {#sec:discussion} + +Because *mimium* treats functions that have internal states which change over time, when higher-order functions are used, there is a counterintuitive behavior compared to general functional programming languages. + +An example is the higher-order function `filterbank`, which duplicates `filter` function `N` times parametrically, and adds them together. Listing [\[lst:filterbank_bad\]](#lst:filterbank_bad) is an example of an incorrect code, and Listing [\[lst:filterbank_good\]](#lst:filterbank_good) is an example of the code that behave correctly. The difference between Listing [\[lst:filterbank_bad\]](#lst:filterbank_bad) and Listing [\[lst:filterbank_good\]](#lst:filterbank_good)is that the recursive calls in the filterbank function are written directly in the inner function to be returned, and the recursive calls in the filterbank function are written with `let` binding out of the inner function[^2]. Similarly, in the `dsp` function that will be called by the audio driver in *mimium*, the difference is whether the filterbank function is executed inside `dsp` or bound with `let` once in the global context. + +In the case of normal functional language, if all the functions used in a composition do not contain destructive assignments, the calculation process will not change even if the variable bound by `let` is manually replaced with its term (beta reduction), as in the conversion from Listing [\[lst:filterbank_good\]](#lst:filterbank_good) to Listing [\[lst:filterbank_bad\]](#lst:filterbank_bad). + +But in *mimium*, there are two major stages of evaluation, 0: the code is evaluated in the global environment (concretizing the signal processing graph) at first, and 1: the dsp function is repeatedly executed (actual signal processing) and the function may involve implicit internal state updates. Therefore, even though the code does not include destructive assignments, the recursive execution of the `filterbank` function is performed only once in Listing [\[lst:filterbank_good\]](#lst:filterbank_good) for the evaluation of the global environment, whereas in Listing [\[lst:filterbank_bad\]](#lst:filterbank_bad), every sample the dsp function is executed, the recursive function is executed and a closure is generated. Since the initialization of the internal state in the closure is performed at the time of closure allocation, in the example of Listing[\[lst:filterbank_bad\]](#lst:filterbank_bad), the internal state of the closure after the evaluation of `filterbank` is reset at each time step. + +``` {#lst:filterbank_bad .rust .Rust float="" floatplacement="H" label="lst:filterbank_bad" language="Rust" caption="\\it Wrong example of the code that duplicate filter parametrically."} +fn bandpass(x,freq){ + //... +} +fn filterbank(n,filter){ + if (n>0){ + |x,freq| filter(x,freq+n*100) + + filterbank(n-1,filter)(x,freq) + }else{ + 0 + } +} +fn dsp(){ //called by audio driver. + filterbank(3,bandpass) +} +``` + +``` {#lst:filterbank_good .rust .Rust float="" floatplacement="H" label="lst:filterbank_good" language="Rust" caption="\\it Corrected example of the code that duplicate filter parametrically."} +fn filterbank(n,filter){ + let next = filterbank(n-1,filter) + if (n>0){ + |x,freq| filter(x,freq+n*100) + + next(x,freq) + }else{ + 0 + } +} +let myfilter = filterbank(3,bandpass) +fn dsp(){ + myfilter(x,1000) +} +``` + +``` {#lst:filterbank_multi .rust .Rust float="" floatplacement="H" label="lst:filterbank_multi" language="Rust" caption="\\it Example of filterbank function using multi-stage computation in a future specification of mimium."} +fn filterbank(n,filter){ + .< if (n>0){ + |x,freq| filter(x,freq+n*100) + + ~filterbank(n-1,filter)(x,freq) + }else{ + 0 + } >. + } + fn dsp(){ + ~filterbank(3,bandpass) (x,1000) + } +``` + +This means that the major compiler optimization techniques such as the constant folding and the function inlining can not simply be appropriated. Those optimizations should be done after the evaluation of a global context and before evaluating `dsp` function. + +To solve this situation, introducing distinction whether the term should be used in global context evaluation(Stage 0) and in the actual signal processing(stage 1) in type system. This can be realized with Multi-Stage Computation\[9\]. Listing [\[lst:filterbank_multi\]](#lst:filterbank_multi) is the example of `filterbank` code using BER MetaOCaml's syntaxes `..` which will generate evaluated program used in a next stage, and `~term` which embed terms evaluated at the previous stage\[10\]. + +`filterbank` function is evaluated in stage 0 while embedding itself by using `~`. + +This multi-stage computation code has a same semantics in a generative signal graph generation and execution of the signal processing, in contrast to that Faust have 2 different semantics of the term rewriting macro and BDA. + +# Conclusion + +[\[sec:conclusion\]](#sec:conclusion) + +This paper proposed $\lambda_{mmm}$, an intermediate representation for the programming languages for music and signal processing with the virtual machine and instruction set to run it. $\lambda_{mmm}$enables to describe generative signal graph and its contents in a single syntax and semantics. However, user have to be responsible to write codes that does not create escapable closures during the dsp execution and this problem would be difficult to understand by novice users. + +# Acknowledgments + +This work was supported by JSPS KAKENHI (Grant No. +JP19K21615). Also great thanks for many anonymous reviewers. + +[\[1\] ]{.csl-left-margin}[Y. Orlarey, D. Fober, and S. Letz, "Syntactical and semantical aspects of Faust," *Soft Computing*, vol. 8, no. 9, pp. 623--632, 2004, doi: [10.1007/s00500-004-0388-1](https://doi.org/10.1007/s00500-004-0388-1).]{.csl-right-inline} + +[\[2\] ]{.csl-left-margin}[A. Gräf, "Term Rewriting Extension for the Faust Programming Language," in *International Linux Audio Conference*, 2010. Available: [https://hal.archives-ouvertes.fr/hal-03162973 https://hal.archives-ouvertes.fr/hal-03162973/document](https://hal.archives-ouvertes.fr/hal-03162973 https://hal.archives-ouvertes.fr/hal-03162973/document)]{.csl-right-inline} + +[\[3\] ]{.csl-left-margin}[B. R. Gaster, N. Renney, and T. Mitchell, "OUTSIDE THE BLOCK SYNDICATE: TRANSLATING FAUST'S ALGEBRA OF BLOCKS TO THE ARROWS FRAMEWORK," in *Proceedings of the 1st International Faust Conference*, Mainz,Germany, 2018.]{.csl-right-inline} + +[\[4\] ]{.csl-left-margin}[V. Norilo, "Kronos: A Declarative Metaprogramming Language for Digital Signal Processing," *Computer Music Journal*, vol. 39, no. 4, pp. 30--48, 2015, doi: [10.1162/COMJ_a_00330](https://doi.org/10.1162/COMJ_a_00330).]{.csl-right-inline} + +[\[5\] ]{.csl-left-margin}[E. J. G. Arias, P. Jouvelot, S. Ribstein, and D. Desblancs, "The [W-calculus]{.nocase}: A Synchronous Framework for the Verified Modelling of Digital Signal Processing Algorithms," in *Proceedings of the 9th ACM SIGPLAN international workshop on functional art, music, modelling, and design*, New York, NY, USA: Association for Computing Machinery, 2021, pp. 35--46. doi: [10.1145/3471872.3472970](https://doi.org/10.1145/3471872.3472970).]{.csl-right-inline} + +[\[6\] ]{.csl-left-margin}[T. Matsuura and K. Jo, "Mimium: A self-extensible programming language for sound and music," in *Proceedings of the 9th ACM SIGPLAN International Workshop on Functional Art, Music, Modelling, and Design*, in FARM 2021. New York, NY, USA: Association for Computing Machinery, Aug. 2021, pp. 1--12. doi: [10.1145/3471872.3472969](https://doi.org/10.1145/3471872.3472969).]{.csl-right-inline} + +[\[7\] ]{.csl-left-margin}[R. Ierusalimschy, L. H. de Figueiredo, and W. Celes, "The Implementation of Lua 5.0," *JUCS - Journal of Universal Computer Science*, vol. 11, no. 7, pp. 1159--1176, Jul. 2005, doi: [10.3217/jucs-011-07-1159](https://doi.org/10.3217/jucs-011-07-1159).]{.csl-right-inline} + +[\[8\] ]{.csl-left-margin}[R. Nystrom, *Crafting Interpreters*. Daryaganj Delhi: Genever Benning, 2021.]{.csl-right-inline} + +[\[9\] ]{.csl-left-margin}[W. Taha and T. Sheard, "Multi-Stage Programming with Explicit Annotations," *SIGPLAN Notices (ACM Special Interest Group on Programming Languages)*, vol. 32, no. 12, pp. 203--214, Dec. 1997, doi: [10.1145/258994.259019](https://doi.org/10.1145/258994.259019).]{.csl-right-inline} + +[\[10\] ]{.csl-left-margin}[O. Kiselyov, "The Design and Implementation of BER MetaOCaml," in *[Proceedings of the 12th International Symposium on Functional and Logic Programming]{.nocase}*, M. Codish and E. Sumii, Eds., Cham: Springer International Publishing, 2014, pp. 86--102. doi: [10.1007/978-3-319-07151-0_6](https://doi.org/10.1007/978-3-319-07151-0_6).]{.csl-right-inline} + +[^1]: Reason for this is that it is easy to implemented on `enum` data structure on Rust, a host language of the latest *mimium* compiler. Operands bitwidth and alignment may be changed in the future. + +[^2]: In the previous specification of *mimium* in \[6\], the binding of new variable and destructive assignment were the same syntax(`x = a`) but the syntax for the variable binding has changed to use `let` keyword. diff --git a/src/md_citeproc.sh b/src/md_citeproc.sh new file mode 100755 index 0000000..787cdf0 --- /dev/null +++ b/src/md_citeproc.sh @@ -0,0 +1,3 @@ +#!/bin/bash + +pandoc main.md -f markdown+hard_line_breaks+smart -t markdown-citations+hard_line_breaks-fenced_divs-native_divs-native_spans-raw_html --citeproc --bibliography=ref.bib --biblatex --csl=ieee -o main_cite.md \ No newline at end of file