summaryrefslogtreecommitdiff
path: root/src/c_backend.ml
AgeCommit message (Collapse)Author
2018-04-10Porting some minisail changes to sail2 branchAlasdair Armstrong
This commit primarily changes how existential types are bound in letbindings. Essentially, the constraints on both numeric and existentially quantified types are lifted into the surrounding type context automatically, so in ``` val f : nat -> nat let x = f(3) ``` whereas x would have had type nat by default before, it'll now have type atom('n) with a constraint that 'n >= 0 (where 'n is some fresh type variable). This has several advantages: x can be passed to functions expecting an atom argument, such as a vector indexing operation without any clunky cast functions - ex_int, ex_nat, and ex_range are no longer required. The let 'x = something() syntax is also less needed, and is now only really required when we specifically want a name to refer to x's type. This changes slightly the nature of the type pattern syntax---whereas previously it was used to cause an existential to be destructured, it now just provides names for an automatically destructured binding. Usually however, this just works the same. Also: - Fixed an issue where the rewrite_split_fun_constr_pats rewriting pass didn't add type paramemters for newly added type variables in generated function parameters. - Updated string_of_ functions in ast_util to reflect syntax changes - Fixed a C compilation issue where elements of union type constructors were not being coerced between big integers and 64-bit integers where appropriate - Type annotations in patterns now generalise, rather than restrict the type of the pattern. This should be safer and easier to handle in the various backends. I don't think any code we had was relying on this behaviour anyway. - Add inequality operator to lib/flow.sail - Fix an issue whereby top-level let bindings with annotations were checked incorrectly
2018-03-22Fix C compilation for CHERI and MIPSAlasdair Armstrong
First, the specialisation of option types has been fixed by allowing the specialisation of constructor return types - this essentially means that a constructor, such as Some : 'a -> option('a) can get specialised to int -> option(int), rather than int -> option('a). This means that these constructors are treated like GADTs internally. Since this only happens just before the C translation, I haven't put much effort into making this very robust so far. Second, there was a bug in C compilation for the typing of return expressions in non-unit contexts, which has been fixed. Finally support for vector literals that are non-bitvectors has been added.
2018-03-19Fixes to C backend for RISCV-compilationAlasdair Armstrong
Can now compile RISCV. Requires some library tweaks before it'll pass any tests, Also adds hyperlinks to wip latex output
2018-03-14Fix toplevel pattern compilationAlasdair Armstrong
Comment out partially working optimisation passes for now
2018-03-13Polymorphic option types now compile to CAlasdair Armstrong
Fixed an issue whereby an option constructor that was never constructed, but only matched on, would cause compilation to fail. Temporarily fixed an issue where union types that can be entirely stack-allocated were not being treated as such, by simply heap-allocating all unions. Need to adapt the code generator to handle this case properly. Fixed a further small issue whereby multiple union types would confuse the type specialisation pass. Added a test case for compiling option types. RISCV now generates C code, but there are still some bugs that need to be squashed before it compile and work.
2018-03-12ELF loading for C backendAlasdair Armstrong
Add a flag to Sail that allows for an image of an elf file to be dumped in a simple format using linksem, used as sail -elf test.elf -o test.bin This image file can then be used by a compiled C version of a sail spec as with ocaml simply by ./a.out test.bin
2018-03-09Specialise constructors for polymorphic unionsAlasdair Armstrong
Also work on making C backend compile RISC-V
2018-03-07Make union types consistent in the ASTAlasdair Armstrong
Previously union types could have no-argument constructors, for example the option type was previously: union option ('a : Type) = { Some : 'a, None } Now every union constructor must have a type, so option becomes: union option ('a : Type) = { Some : 'a, None : unit } The reason for this is because previously these two different types of constructors where very different in the AST, constructors with arguments were used the E_app AST node, and no-argument constructors used the E_id node. This was particularly awkward, because it meant that E_id nodes could have polymorphic types, i.e. every E_id node that was also a union constructor had to be annotated with a type quantifier, in constrast with all other identifiers that have unquantified types. This became an issue when monomorphising types, because the machinery for figuring out function instantiations can't be applied to identifier nodes. The same story occurs in patterns, where previously unions were split across P_id and P_app nodes - now the P_app node alone is used solely for unions. This is a breaking change because it changes the syntax for union constructors - where as previously option was matched as: function is_none opt = match opt { Some(_) => false, None => true } it is now matched as function is_none opt = match opt { Some(_) => false, None() => true } note that constructor() is syntactic sugar for constructor(()), i.e. a one argument constructor with unit as it's value. This is exactly the same as for functions where a unit-function can be called as f() and not as f(()). (This commit also makes exit() work consistently in the same way) An attempt to pattern match a variable with the same name as a union-constructor now gives an error as a way to guard against mistakes made because of this change. There is probably an argument for supporting the old syntax via some syntactic sugar, as it is slightly prettier that way, but for now I have chosen to keep the implementation as simple as possible. The RISCV spec, ARM spec, and tests have been updated to account for this change. Furthermore the option type can now be included from $SAIL_DIR/lib/ using $include <option.sail>
2018-03-02Use sail_lib.lem values in C backendAlasdair Armstrong
Rather than just using strings to represent literals, now use value types from sail_lib.lem to represent them. This allows for expressions to be evaluated at compile time, which will be useful for future optimisations involving constant folding and propagation, and allows the intermediate bytecode to be interpreted using the same lem builtins that the shallow embedding uses. To get this to work I had to tweak the build process slightly to allow ml files to import lem files from gen_lib/. Hopefully this doesn't break anything!
2018-03-01Cleanup intermediate bytecode representation in C backendAlasdair Armstrong
2018-02-27Fix some bugs in C compilation, and optimise struct updatesAlasdair Armstrong
Fix some issues where some early returns in functions would cause memory leaks, and optimize struct updates so the struct is not copied uneccesarily. Also make C print_bits match ocaml version output, and update tests.
2018-02-26Add some obvious optimisations to C backend.Alasdair Armstrong
With these optimisations on, now get about 10x performance over OCaml.
2018-02-23Fix some bugs in C compilationAlasdair Armstrong
Fixed an issue with pattern matching on enums Fixed an issue whereby fix_early_returns would cause memory leaks Added optimizations for some of the builtins used in the decode function. Optimizations are turned on with the -O flag.
2018-02-22More updates to C backendAlasdair Armstrong
Add support for short-ciruiting and/or. I forgot about this in the original ANF specification and not having it causes problems for the ARM spec.
2018-02-21Can now compile aarch64/no_vector into CAlasdair Armstrong
Now compiles to C and builds a working executable. Just need to correctly implement all the library builtins (some are still stubs), and it should work.
2018-02-21Have aarch64/no_vector compiling to CAlasdair Armstrong
Just need to implement builtins, fix-up a few re-write passes, and integrate some kind of elf-loading and it should work.
2018-02-19Have generic vectors working in C backendAlasdair Armstrong
2018-02-16Add __TakeColdReset function to aarch64_no_vectorAlasdair Armstrong
Turns out the __TakeColdReset function is actually in the v8.3 XML. I went and looked for it, and it's there, it just wasn't being picked up by ASL parser because it's not called from any instructions. I added a new field to the json config files for ASL parser that can tell it about any such special functions that it should guarantee to include. Also fixed a bug in C loop compilation
2018-02-16Can now compile aarch64/duopod to CAlasdair Armstrong
Goes through the C compiler without any errors, but as we still don't have all the requisite builtins it won't actually produce an executable. There are still a few things that don't work properly, such as vectors of non-bit types - but once those are fixed and the Sail library is implemented fully it should work.
2018-02-15C backend can now handle record literals and record update syntax correctlyAlasdair Armstrong
2018-02-15List support in C backendAlasdair Armstrong
2018-02-13Support for large bitvector literals in C backendAlasdair Armstrong
2018-02-12Add support for top-level letbindings to C backendAlasdair Armstrong
2018-02-09Improve IR pretty-printing for debuggingAlasdair Armstrong
2018-02-09Formalize C backend intermediate representation in OttAlasdair Armstrong
Describes precisely the intermediate representation used in the C backend in an ott grammar, and also removes several C-isms where raw C code was inserted into the IR, so in theory this IR could be interpreted by a small VM/interpreter or compiled to LLVM bytecode etc. Currently the I_raw constructor for inserting C code is just used for inserting GCC attributes, so it can safely be ignored. Also augment and refactor the instruction type with an aux constructor so location information can be propagated down to this level.
2018-02-08Can now generate control flow graphs with C backendAlasdair Armstrong
Option -ddump_flow_graphs when used with -c will create graphviz files for each function in the specification with control and data dependencies shown.
2018-02-07Have exceptions working in C backendAlasdair Armstrong
2018-02-06Compile union types in C backendAlasdair Armstrong
2018-02-06Work on handling exceptions in C backendAlasdair Armstrong
2018-02-01More work on C compilationAlasdair Armstrong
Can now compile things like early returns. The same approach should work for exception handling as well. Once that's in place, just need to work a bit more on getting union types to work + the library of builtins, then we should be able to compile and run some of our specs via C. Also added some documentation in comments for the general approach taken when compiling (need many more though).
2018-02-01More work on running sail tests compiled to CAlasdair Armstrong
2018-02-01Can now compile some simple sail programs to CAlasdair Armstrong
2018-01-31More updates to C backend - matching and tuplesAlasdair Armstrong
2018-01-30Updates to C backendAlasdair Armstrong
2018-01-29Further updates to C backendAlasdair Armstrong
2018-01-26More work on C backendAlasdair Armstrong
2018-01-25Add pattern completness check for match statementsAlasdair Armstrong
Gives warnings when pattern matches are incomplete, when matches are redundant (in certain cases), or when no unguarded patterns exist. For example the following file: enum Test = {A, C, D} val test1 : Test -> string function test1 x = match x { A => "match A", B => "this will match anything, because B is unbound!", C => "match C", D => "match D" } val test2 : Test -> string function test2 x = match x { A => "match A", C => "match C" /* No match for D */ } val test3 : Test -> string function test3 x = match x { A if false => "never match A", C => "match C", D => "match D" } val test4 : Test -> string function test4 x = match x { A if true => "match A", C if true => "match C", D if true => "match D" } will produce the following warnings Warning: Possible redundant pattern match at file "test.sail", line 10, character 5 to line 10, character 5 C => "match C", Warning: Possible redundant pattern match at file "test.sail", line 11, character 5 to line 11, character 5 D => "match D" Warning: Possible incomplete pattern match at file "test.sail", line 17, character 3 to line 17, character 7 match x { Most general matched pattern is A_|C_ Warning: Possible incomplete pattern match at file "test.sail", line 26, character 3 to line 26, character 7 match x { Most general matched pattern is C_|D_ Warning: No non-guarded patterns at file "test.sail", line 35, character 3 to line 35, character 7 match x { warnings can be turned of with the -no_warn flag.
2018-01-24Have some simple sail programs compiling to CAlasdair Armstrong
2018-01-24More work on C compilationAlasdair Armstrong
2018-01-24More work on experimental C backendAlasdair Armstrong
2018-01-23Started working on C backend for sailAlasdair Armstrong
Also updated some of the documentation in the sail source code