Commit 9f137df6 authored by Camil Staps's avatar Camil Staps 🐧

Cleanup: remove old files; restructure source

parent f5105dad
This diff is collapsed.
......@@ -18,8 +18,8 @@ optimise < "Clean System Files/fsieve.abc" > "Clean System Files/fsieve.opt.abc"
optimise < "$CLEAN_HOME/lib/StdEnv/Clean System Files/StdReal.abc" > "$CLEAN_HOME/lib/StdEnv/Clean System Files/StdReal.opt.abc"
# Generate bytecode
bytecode "Clean System Files/fsieve.opt.abc" -o "Clean System Files/fsieve.obc"
bytecode "$CLEAN_HOME/lib/StdEnv/Clean System Files/StdReal.opt.abc" -o "$CLEAN_HOME/lib/StdEnv/Clean System Files/StdReal.obc"
bcgen "Clean System Files/fsieve.opt.abc" -o "Clean System Files/fsieve.obc"
bcgen "$CLEAN_HOME/lib/StdEnv/Clean System Files/StdReal.opt.abc" -o "$CLEAN_HOME/lib/StdEnv/Clean System Files/StdReal.obc"
# Link bytecode
link "Clean System Files/fsieve.obc" "$CLEAN_HOME/lib/StdEnv/Clean System Files/StdReal.obc" i_system.abc -o fsieve.bc
......@@ -40,13 +40,13 @@ blocks, and introduces many new ABC instructions for frequently used blocks.
Usage: `optimise < ABC > OABC`
### bytecode
### bcgen
Generates bytecode from ABC files.
Usage: `bytecode (O)ABC [(O)ABC ...] -o OBC`
Usage: `bcgen (O)ABC [(O)ABC ...] -o OBC`
In principle, `bytecode` can handle multiple ABC files and link them together.
In principle, `bcgen` can handle multiple ABC files and link them together.
However, this is not used any more since we have a linker. Thus, it is safer to
generate bytecode for every tool separately and link them together with `link`.
......
\RequirePackage{tikz}
\pgfkeys{/tikz/node args/.store in=\clean@args}
\pgfkeys{/tikz/clean/.style={%
every node/.style={
clean node,
node args=0,
draw,
minimum height=1.5em
},
->,
node distance=1em
}}
\newdimen\clean@ya
\newdimen\clean@yb
\newdimen\clean@x
\pgfdeclareshape{clean node}{
\inheritsavedanchors[from=rectangle]
\inheritanchor[from=rectangle]{west}
\inheritanchor[from=rectangle]{north}
\inheritanchor[from=rectangle]{east}
\inheritanchor[from=rectangle]{south}
\inheritanchor[from=rectangle]{north west}
\inheritanchor[from=rectangle]{north east}
\inheritanchor[from=rectangle]{south west}
\inheritanchor[from=rectangle]{south east}
\anchor{arg1}{\pgf@process{\northeast}\pgf@xa=\pgf@x\pgf@process{\pgf@anchor@rectangle@center}\pgf@x=\pgf@xa\advance\pgf@x by 3pt}
\anchor{arg2}{\pgf@process{\northeast}\pgf@xa=\pgf@x\pgf@process{\pgf@anchor@rectangle@center}\pgf@x=\pgf@xa\advance\pgf@x by 9pt}
\anchor{arg3}{\pgf@process{\northeast}\pgf@xa=\pgf@x\pgf@process{\pgf@anchor@rectangle@center}\pgf@x=\pgf@xa\advance\pgf@x by 15pt}
\anchor{arg1.west}{\pgf@process{\northeast}\pgf@xa=\pgf@x\pgf@process{\pgf@anchor@rectangle@center}\pgf@x=\pgf@xa\advance\pgf@x by 0pt}
\anchor{arg2.west}{\pgf@process{\northeast}\pgf@xa=\pgf@x\pgf@process{\pgf@anchor@rectangle@center}\pgf@x=\pgf@xa\advance\pgf@x by 6pt}
\anchor{arg3.west}{\pgf@process{\northeast}\pgf@xa=\pgf@x\pgf@process{\pgf@anchor@rectangle@center}\pgf@x=\pgf@xa\advance\pgf@x by 12pt}
\anchor{arg1.north}{\pgf@process{\northeast}\advance\pgf@x by 3pt}
\anchor{arg2.north}{\pgf@process{\northeast}\advance\pgf@x by 9pt}
\anchor{arg3.north}{\pgf@process{\northeast}\advance\pgf@x by 15pt}
\anchor{arg1.east}{\pgf@process{\northeast}\pgf@xa=\pgf@x\pgf@process{\pgf@anchor@rectangle@center}\pgf@x=\pgf@xa\advance\pgf@x by 6pt}
\anchor{arg2.east}{\pgf@process{\northeast}\pgf@xa=\pgf@x\pgf@process{\pgf@anchor@rectangle@center}\pgf@x=\pgf@xa\advance\pgf@x by 12pt}
\anchor{arg3.east}{\pgf@process{\northeast}\pgf@xa=\pgf@x\pgf@process{\pgf@anchor@rectangle@center}\pgf@x=\pgf@xa\advance\pgf@x by 18pt}
\anchor{arg1.south}{\pgf@process{\southwest}\pgf@ya=\pgf@y\pgf@process{\northeast}\pgf@y=\pgf@ya\advance\pgf@x by 3pt}
\anchor{arg2.south}{\pgf@process{\southwest}\pgf@ya=\pgf@y\pgf@process{\northeast}\pgf@y=\pgf@ya\advance\pgf@x by 9pt}
\anchor{arg3.south}{\pgf@process{\southwest}\pgf@ya=\pgf@y\pgf@process{\northeast}\pgf@y=\pgf@ya\advance\pgf@x by 15pt}
\anchor{center}{\pgfpointorigin}
\backgroundpath{%
\pgfpathrectanglecorners
{\pgfpointadd
{\southwest}
{\pgfpoint{\pgfkeysvalueof{/pgf/outer xsep}}{\pgfkeysvalueof{/pgf/outer ysep}}}}
{\pgfpointadd
{\pgfpoint{\clean@args *6pt}{0}}
{\pgfpointadd
{\northeast}
{\pgfpointscale{-1}{\pgfpoint{\pgfkeysvalueof{/pgf/outer xsep}}{\pgfkeysvalueof{/pgf/outer ysep}}}}}}
\pgfusepathqstroke
\ifnum\clean@args>0
\southwest\clean@ya=\pgf@y
\northeast\clean@yb=\pgf@y
\clean@x=\pgf@x
\foreach\arg in {1,...,\clean@args}{%
\pgfpathmoveto{\pgfpoint{\clean@x}{\clean@yb}}
\pgfpathlineto{\pgfpoint{\clean@x}{\clean@ya}}
\pgfusepathqstroke
\pgfpathcircle{\pgfpointadd{\pgfpoint{3pt}{.5\clean@yb}}{\pgfpoint{\clean@x}{.5\clean@ya}}}{1pt}
\pgfusepathqfillstroke
\global\advance\clean@x by 6pt
}
\fi
}
}
\documentclass[a4paper]{article}
\usepackage{geometry}
\usepackage[backend=biber,natbib]{biblatex}
\bibliography{library}
\usepackage{clean}
\usepackage{cleveref}
\usepackage{minted}
\setminted{fontsize=\footnotesize,xleftmargin=3em}
\usepackage{subcaption}
\usepackage{tikz}
\usetikzlibrary{calc,positioning}
\tikzset{
doc/.pic={
\coordinate (-east) at (0.309,0);
\coordinate (-west) at (-0.309,0);
\coordinate (-south) at (0,-0.4);
\coordinate (-north) at (0,0.4);
\draw[pic actions] (-0.309,-0.4) -- ++(0,0.8) -- ++(0.518,0) -- ++(0,-0.1) -- ++(0.1,0) -- ++(0,-0.7) -- cycle;
\draw[pic actions] (0.209,0.4) -- ++(0.1,-0.1);
\draw[pic actions] (-0.209,-0.1) -- ++(0.418,0);
\draw[pic actions] (-0.209, 0) -- ++(0.418,0);
\draw[pic actions] (-0.209, 0.1) -- ++(0.418,0);
},
bin/.pic={
\coordinate (-east) at (0.309,0);
\coordinate (-west) at (-0.309,0);
\coordinate (-south) at (0,-0.4);
\coordinate (-north) at (0,0.4);
\draw[pic actions] (-0.309,-0.4) -- ++(0,0.8) -- ++(0.518,0) -- ++(0,-0.1) -- ++(0.1,0) -- ++(0,-0.7) -- cycle;
\draw[pic actions] (0.209,0.4) -- ++(0.1,-0.1);
\node at (0,0.05) {\scriptsize\texttt{100}};
\node at (0,-0.2) {\scriptsize\texttt{001}};
}
}
\title{Cross-Platform Dynamics in Clean\footnote{For brevity, this handout does not contain references. See our previously handed out topic page for details.}}
\author{Camil Staps\footnote{Radboud University Nijmegen} \and Erin van der Veen\footnotemark[2]}
\begin{document}
\maketitle
\section{Dynamics}
In strongly typed languages, it is often useful to be able to box expressions of arbitrary type.
Thus, in the program below the sum of a list of numbers can be computed, ignoring the fact that the numbers have different types:
\begin{minted}{clean}
dynsum :: [Dynamic] -> Maybe Real
dynsum [] = Just 0.0
dynsum [x :: Real:xs] = (+) x <$> dynsum xs
dynsum [x :: Int :xs] = (+) (toReal x) <$> dynsum xs
dynsum _ = Nothing
Start = dynsum [dynamic 37, dynamic 5.0]
\end{minted}
%
Dynamics can also contain not fully evaluated expressions.
This is especially useful to store functions or infinite data structures, as in \mintinline{clean}{dynamic [1..]}.
To be able to share dynamics between programs, on 32-bit Windows an interface exists which can dynamically link object code into any application,
thus allowing programs to share the code of functions needed to evaluate the expression in a dynamic.
A concrete example where dynamics can be useful is Soccer-Fun.\footnote{\url{http://www.cs.ru.nl/P.Achten/SoccerFun/SoccerFun.html}}
Soccer-Fun is an educational project in Clean in which participants write the AI for a simple football team.
Currently, there is no convenient way to play against other teams without sharing your code (which you want to keep secret).
If one would be able to store their team in a dynamic, serialise that dynamic and share it with others,
a simple interface can be added to the Soccer-Fun GUI to save and load teams as dynamics.
The main issue with this is that teams consist of both data and code and Soccer-Fun can run on multiple platforms.
Therefore we need a way to (un)serialise data and code in a platform-independent manner.
\section{Clean}
In conventional (imperative) programs the state of the program is defined by: the registers, the stack and the heap.
This is not the case in most modern functional programming languages.
In Clean, for example, the state is defined by: the registers, the A-Stack (for references to the graph), the B-Stack (for basic values), the C-Stack (for return addresses) and the graph (comparable to the heap).
Graph rewriting (a more efficient version of term rewriting where the terms are represented as nodes in a graph) is used to reduce the program to it's normal form.
The way the graph must be rewritten is defined in the graph rewriting rules.
When writing a Clean program one is, in essence, providing instructions on how the graph must be rewritten.
As an example, consider the program to compute $4!$ below.
The first three rewriting steps of the program are shown in \cref{fig:rewriting}.
\begin{minted}{clean}
fac :: Int -> Int
fac 0 = 1
fac n = n * fac (n-1)
Start = fac 4
\end{minted}
%
\begin{figure*}[t]
\small
\centering
\begin{subfigure}[b]{.2\linewidth}
\centering
\begin{tikzpicture}[clean]
\node (start) {\texttt{Start}};
\end{tikzpicture}
\caption{Initially.}
\end{subfigure}%
\begin{subfigure}[b]{.2\linewidth}
\centering
\begin{tikzpicture}[clean]
\node[node args=1] (fac) {\texttt{fac}};
\node[below=of fac.arg1.south] (4) {\texttt{4}};
\draw (fac.arg1) -- (4.north);
\end{tikzpicture}
\caption{Applying \texttt{Start}.}
\end{subfigure}%
\begin{subfigure}[b]{.3\linewidth}
\centering
\begin{tikzpicture}[clean]
\node[node args=2] (times) {\texttt{*}};
\node[below=of times.arg1.south] (4) {\texttt{4}};
\node[node args=1,right=of times.arg2.east] (fac) {\texttt{fac}};
\node[node args=2,right=of fac.arg1.east] (minus) {\texttt{-}};
\node[right=of minus.arg2.east] (1) {\texttt{1}};
\draw (times.arg1) -- (4.north);
\draw (times.arg2) -- (fac.west);
\draw (fac.arg1) -- (minus.west);
\draw (minus.arg1) |- (4.east);
\draw (minus.arg2) -- (1.west);
\end{tikzpicture}
\caption{Applying \texttt{fac n}.}
\end{subfigure}%
\begin{subfigure}[b]{.2\linewidth}
\centering
\begin{tikzpicture}[clean]
\node[node args=2] (times) {\texttt{*}};
\node[below=of times.arg1.south] (4) {\texttt{4}};
\node[node args=1,right=of times.arg2.east] (fac) {\texttt{fac}};
\node[below=of fac.arg1.south] (3) {\texttt{3}};
\draw (times.arg1) -- (4.north);
\draw (times.arg2) -- (fac.west);
\draw (fac.arg1) -- (3.north);
\end{tikzpicture}
\caption{Applying \texttt{-}.}
\end{subfigure}
\caption{Rewriting a Clean node\label{fig:rewriting}.}
\end{figure*}
%
When Clean is compiled, the source code is first translated to ABC-code.
ABC-code is a kind of assembly for an abstract machine specialised for graph rewriting.
The fact that the ABC-Machine is an imperative machine ensures that the translation of a functional program to imperative machine code is a relatively small step.
This, in turn, makes it possible for Clean to target many different architectures.
The goal of our study is to be able to share Clean code and data, wrapped in dynamics, between executables on different platforms.
To do this we generate an abstract, platform-independent bytecode from the ABC-code which can be interpreted by the run-time system.
The interpreter has to interwork with native code:
as an example, consider how the \mintinline{clean}{dynsum} example above is executed when \mintinline{clean}{dynsum} is a native function but the list elements are evaluated by the interpreter.
This oversimplified pipeline is shown in \cref{fig:pipeline}, of which the top line already exists as the standard way to run a Clean program.
The main challenges of this work are:
a small binary bytecode format;
an efficient interpreter (or in the future a Just-in-Time compiler);
an efficient garbage collector;
looking up the relevant symbols for a Clean expression in the bytecode;
stripping and linking the bytecode;
efficient interworking between native code and the interpreter.
\begin{figure*}[b]
\centering
\begin{tikzpicture}
\footnotesize
\pic (src) at (-7,0) {doc};
\node[below=3pt of src-south] {Clean};
\pic (abc) at (-4.5,0) {doc};
\node[below=3pt of abc-south] {ABC};
\draw[->] (src-east) -- node [above] {Compile} (abc-west);
\pic (pgm) at (0,1) {bin};
\node[below=3pt of pgm-south] {Native code};
\draw[->] ($(abc-east)+(0,0.1)$) -- node [left,yshift=1em] {Generate} (pgm-west);
\pic (opt) at (-1.5,-1) {doc};
\node[below=3pt of opt-south] {ABC\textasteriskcentered};
\draw[->] ($(abc-east)-(0,0.1)$) -- node [below,yshift=-1em] {Optimise} (opt-west);
\pic (bbc) at (1.5,-1) {bin};
\node[below=3pt of bbc-south,text width=4em,text centered] {Abstract\\bytecode};
\draw[->] (opt-east) -- node [above] {Generate} (bbc-west);
\node[draw,text width=5em,text centered] (rts) at (4.5,0) {Run-time\\system};
\draw[->] (pgm-east) -- node [above right] {Link} (rts);
\draw[->] (bbc-east) -- node [below right] {Interpret} (rts);
\node[draw] (res) at (7,0) {Result};
\draw[->] (rts) -- node [above] {Run} (res);
\end{tikzpicture}
\caption{The final pipeline.\label{fig:pipeline}}
\end{figure*}
\printbibliography
\end{document}
@article{Abadi1991,
author={Abadi, Mart\'{\i}n and Cardelli, Luca and Pierce, Benjamin and Plotkin, Gordon},
title={Dynamic Typing in a Statically Typed Language},
journal={ACM Transactions on Programming Languages and Systems},
year=1991,
volume=13,
number=2,
pages={237--268}
}
@article{Abadi1995,
author={Abadi, Mart\'{\i}n and Cardelli, Luca and Pierce, Benjamin and R\'emy, Didier},
title={Dynamic Typing in Polymorphic Languages},
journal={Journal of Functional Programming},
number=1,
volume=5,
pages={92--103},
year=1995
}
@report{CleanLang,
author={Plasmeijer, Rinus and {van Eekelen}, Marko and {van Groningen}, John},
title={Clean 2.2 Language Report},
url={http://clean.cs.ru.nl/download/doc/CleanLangRep.2.2.pdf},
year=2011
}
@inproceedings{Jansen2006,
author={Jansen, J. M. and Koopman, P. and Plasmeijer, R.},
title={Efficient interpretation by transforming data types and patterns to functions},
booktitle={Proc. Seventh Symposium on Trends in Functional Programming (TFP 2006)},
pages={73--90},
year=2006
}
@article{Leroy1993,
author={Leroy, Xavier and Mauny, Michel},
journal={Journal of Functional Programming},
number=4,
pages={431--463},
title={Dynamics in ML},
volume=3,
year=1993
}
@phdthesis{VanNoort2012,
author={Thomas {Van Noort}},
title={Dynamic Typing in Type-Driven Programming},
institution={Radboud University Nijmegen},
year=2012
}
@inproceedings{Pil1998,
author={Pil, M. R. C.},
title={Dynamic types and type dependent functions},
booktitle={Proc. of Implementation of Functional Languages (IFL '98)},
pages={169--185},
year=1998
}
@inproceedings{Plasmeijer2008,
author={Plasmeijer, R. and Jansen, J. M. and Koopman, P. and Achten, P.},
title={Declarative Ajax and client side evaluation of workflows using iTasks},
booktitle={10th International ACM SIGPLAN Symposium on Principles and Practice of Declarative Programming (PPDP '08)},
pages={56--66},
year=2008
}
@inproceedings{Vervoort2002,
author={Vervoort, M. and Plasmeijer, R.},
title={Lazy Dynamic Input/Output in the Lazy Functional Language Clean},
booktitle={Implementation of Functional Languages, 14th International Workshop, IFL 2002},
pages={101--117},
year=2002
}
This diff is collapsed.
\documentclass[a4paper]{article}
\usepackage{geometry}
\usepackage[backend=biber,natbib]{biblatex}
\bibliography{library}
\title{Cross-Platform Dynamics in Clean}
\author{Camil Staps\footnote{Radboud University Nijmegen} \and Erin van der Veen\footnotemark[1]}
\begin{document}
\maketitle
\section*{Topic}
Dynamics are data types that store both a value and the type of that value~\cites{Abadi1991,Leroy1993,Abadi1995,Pil1998}.
Such types are useful in strongly typed languages to store values of different types in homogeneous data structures.
Clean is a pure, lazy, strongly-typed functional programming language with builtin support for dynamics~\citep{CleanLang}.
On 32-bit Windows, it is possible to store a dynamic on disk, together with all the corresponding object code,
which allows for sharing of dynamics between different applications~\citep{Vervoort2002}.
This is also possible with expressions that are not completely evaluated.
Clean also supports serialization of any (possibly not completely evaluated) expression,
but these expressions can only be deserialized by the same executable.
Serialization can also be done using generic JSON functions, but these are not able to serialize unevaluated expressions or functions.
Thus, there is currently no way to communicate values of arbitrary type between different executables on different platforms in a type-safe manner.
\section*{Research Approach}
In this study, we extend the Clean runtime system with a custom bytecode interpreter.
We add an executable-independent serialization function,
which can look up the ABC code\footnote{ABC code is the intermediate target language of the Clean compiler. It is a high-level assembly language for an abstract graph rewriting machine.} corresponding to the serialized expression.
This ABC code is optimised and compiled to an efficient, platform-independent bytecode.
This bytecode can then be interpreted by any client application, allowing for type-safe cross-platform communication of arbitrary types.
If time permits, we can extend the system with a Just-in-Time compiler for better performance.
\section*{Related Work}
The \emph{iTasks} system uses the intermediate functional language SAPL rather than ABC for client-side code execution~\cites{Jansen2006,Plasmeijer2008}.
We choose to use ABC because it is more efficient and provides for a shorter pipeline.
John van Groningen has already worked on an ABC optimiser, a code generator for 32-bit bytecode and a proof-of-concept 32-bit interpreter.
This system needs to be extended with a garbage collector, the bytecode needs to become platform-independent and the interpreter needs to be finished.
The system needs to be integrated with the dynamics system using new platform-independent serialization functionality.
\printbibliography
\end{document}
bytecode
bcgen
debug
interpret
link
......
......@@ -10,7 +10,7 @@ override CFLAGS+=\
-lm
DIR:="Clean System Files"
all: optimise bytecode link interpret debug
all: optimise bcgen link interpret debug
CodeSharing: Clean\ System\ Files/interpret.a .FORCE
$(CLM) -IL Platform -IL GraphCopy -no-opt-link -ns $@ -o $@
......@@ -20,20 +20,20 @@ optimise: .FORCE
SRC_BYTECODE:=\
abc_instructions.c\
util.c\
bytecode_gen/bytecode_gen.c\
bytecode_gen/instruction_code.c\
bytecode_gen/instruction_parse.c\
bytecode_gen/instruction_table.c
bcgen.c\
bcgen_instructions.c\
bcgen_instruction_table.c\
parse_abc.c\
util.c
DEP_BYTECODE:=$(subst .c,.h,$(SRC_BYTECODE)) settings.h
bytecode: $(SRC_BYTECODE) $(DEP_BYTECODE)
bcgen: $(SRC_BYTECODE) $(DEP_BYTECODE)
$(CC) $(CFLAGS) $(SRC_BYTECODE) -DBC_GEN -o $@
SRC_LINK:=\
abc_instructions.c\
bcgen_instructions.c\
bytecode.c\
bytecode_gen/instruction_code.c\
link.c\
parse.c\
util.c
......
......@@ -2,7 +2,6 @@
#include <stdlib.h>
#include <string.h>
#include "abci_types.h"
#include "abc_instructions.h"
char *instruction_name(BC_WORD i) {
......
......@@ -2,11 +2,11 @@
#include <stdlib.h>
#include <string.h>
#include "../util.h"
#include "bytecode_gen.h"
#include "instruction_code.h"
#include "instruction_parse.h"
#include "instruction_table.h"
#include "bcgen.h"
#include "bcgen_instructions.h"
#include "bcgen_instruction_table.h"
#include "parse_abc.h"
#include "util.h"
void parse_file(FILE *file) {
char* line = NULL;
......
......@@ -2,10 +2,6 @@
#include <inttypes.h>
#include "../bytecode.h"
#include "instruction_code.h"
struct word {
uint8_t width;
uint64_t value;
......
#include <string.h>
#include "../settings.h"
#include "../util.h"
#include "instruction_code.h"
#include "instruction_parse.h"
#include "instruction_table.h"
#include "bcgen_instructions.h"
#include "bcgen_instruction_table.h"
#include "parse_abc.h"
#include "settings.h"
#include "util.h"
// Global instruction table
inst_element** inst_table;
......
#include "instruction_code.h"
#include "bcgen_instructions.h"
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include "../abc_instructions.h"
#include "../util.h"
#include "bytecode_gen.h"
#include "abc_instructions.h"
#include "bcgen.h"
#include "util.h"
#define max_implemented_instruction_n CMAX-1
......
#pragma once
#include "../abci_types.h"
#include "../bytecode.h"
#include "bytecode.h"
struct label {
char *label_name;
......
......@@ -5,11 +5,6 @@
#include "settings.h"
#ifdef BC_GEN
# include "bytecode_gen/bytecode_gen.h"
# include "bytecode_gen/instruction_code.h"
#endif
/* Size of an instruction in binary bytecode, in bytes */
#define BYTEWIDTH_INSTRUCTION 2
......
......@@ -2,11 +2,11 @@
#include <stdlib.h>
#include <unistd.h>
#include "bcgen_instructions.h"
#include "link.h"
#include "parse.h"
#include "settings.h"
#include "util.h"
#include "bytecode_gen/instruction_code.h"
#define MAX_INPUT_FILES 1024
......
......@@ -10,7 +10,7 @@
#endif
#ifdef LINKER
# include "bytecode_gen/instruction_code.h"
# include "bcgen_instructions.h"
#endif
void init_parser(struct parser *state
......
#include <inttypes.h>
#include "instruction_parse.h"
#include "parse_abc.h"
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <ctype.h>
#include "../abci_types.h"
#include "../util.h"
#include "instruction_code.h"
#include "instruction_table.h"
#include "bcgen_instructions.h"
#include "util.h"
void warning_i (char *error_string,int integer) {
fprintf(stderr, error_string, integer);
......
#pragma once
#include "instruction_table.h"
#include "bcgen_instruction_table.h"
void init_parser(void);
void parse_line(char*, unsigned int);
......
......@@ -2,7 +2,7 @@
CLM=clm
CLMFLAGS="-IL Platform -IL Dynamics -dynamics -exl -desc"
CG=../src/bytecode
CG=../src/bcgen
LINK=../src/link
OPT=../src/optimise
IP=../src/interpret
......@@ -127,7 +127,7 @@ if [ $BENCHMARK -gt 0 ] && [[ $CFLAGS != *"-Ofast"* ]]; then
sleep 1
fi
CFLAGS="$CFLAGS" make -BC ../src optimise bytecode link interpret || exit 1
CFLAGS="$CFLAGS" make -BC ../src optimise bcgen link interpret || exit 1
if [ $RECOMPILE -gt 0 ]; then
rm -r Clean\ System\ Files 2>/dev/null
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment