{"id":24974784,"url":"https://github.com/wkaisertexas/sipc","last_synced_at":"2026-05-04T03:33:02.437Z","repository":{"id":275503652,"uuid":"926268149","full_name":"wkaisertexas/sipc","owner":"wkaisertexas","description":"Extending the Tiny Imperative Language into the Simple Imperative Language","archived":false,"fork":false,"pushed_at":"2025-02-02T23:43:59.000Z","size":0,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":1,"default_branch":"main","last_synced_at":"2025-02-03T00:25:55.122Z","etag":null,"topics":["llvm","tipcc"],"latest_commit_sha":null,"homepage":"","language":"C++","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/wkaisertexas.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2025-02-02T23:31:11.000Z","updated_at":"2025-02-02T23:44:02.000Z","dependencies_parsed_at":"2025-02-03T00:36:06.551Z","dependency_job_id":null,"html_url":"https://github.com/wkaisertexas/sipc","commit_stats":null,"previous_names":["wkaisertexas/sipc"],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/wkaisertexas%2Fsipc","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/wkaisertexas%2Fsipc/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/wkaisertexas%2Fsipc/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/wkaisertexas%2Fsipc/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/wkaisertexas","download_url":"https://codeload.github.com/wkaisertexas/sipc/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":246150459,"owners_count":20731419,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["llvm","tipcc"],"created_at":"2025-02-03T20:42:42.605Z","updated_at":"2026-05-04T03:32:57.414Z","avatar_url":"https://github.com/wkaisertexas.png","language":"C++","funding_links":[],"categories":[],"sub_categories":[],"readme":"[![Build Status](https://github.com/matthewbdwyer/tipc/actions/workflows/build-and-test.yml/badge.svg?branch=main)](https://github.com/matthewbdwyer/tipc/actions/workflows/build-and-test.yml)\n[![codecov.io](https://codecov.io/gh/matthewbdwyer/tipc/coverage.svg?branch=main\u0026flag=codecoverage)](https://codecov.io/gh/matthewbdwyer/tipc?branch=main)\n[![codecov.io](https://img.shields.io/endpoint?logo=codecov\u0026logoColor=blue\u0026url=https%3A%2F%2Fmatthewbdwyer.github.io%2Ftipc%2Fdoccoverage.json)](https://codecov.io/gh/matthewbdwyer/tipc?branch=main)\n\ntipc\n=========\nA compiler from TIP to llvm bitcode\n\n## Extension from TIP to SIP\n\n- [Solution 1: Extending the TIP parser to the SIP parser - Writeup](./SOLUTION1.md)\n- [Solution 2:  Extending the front end to support SIP  - Writeup](./SOLUTION2.md)\n- [Solution 3: Weeding Pass, Type System, Type Constraints](./SOLUTION3.md)\n- [Solution 4: Code Generation](./SOLUTION4.md)\n\n## SIP Language\n\nThe SIP language is a superset of the tip language. The same way all C programs are valid C++ programs, all valid tip programs are valid sip programs.\n\nAdded grammar as a part of SIP,\n\n1. Boolean literals (`true` and `false`)\n2. Combining expressions with logical operators\n3. Arrays and array literal syntax\n4. Indexing into an array\n5. Arithmetic negation and modulo support\n6. The addition of the  `\u003e=`, `\u003c`, and `\u003c=` operators\n7. Terries and nested ternaries\n8. Range-style for loops for(a : b) where a is an array\n9. For loops where the range is non-deterministic. For (a in b by 2) where you skip over two elements\n\n## TIP Language, Interpreter, and Analyzers\n\nTIP is a \"Tiny Imperative Programming\" language developed by Anders M\u0026#248;ller and Michael I. Schwartzbach for the [Static Program Analysis](https://cs.au.dk/~amoeller/spa/ \"Static Program Analysis\") lecture notes that they developed for graduate instruction at Aarhus University.\n\nAccompanying those notes is a [Scala implementation](https://github.com/cs-au-dk/TIP/) that provides a number of static analysis implementations and interpreter-based evaluators.\n\nThis project implements `tipc` which compiles TIP programs into LLVM bitcode.  Linking that bitcode with the [runtime library](./rtlib) routines and standard libraries will produce an executable.\n\n## Dependencies\n\n`tipc` is implemented in C++17 and depends on a number of tools and packages, e.g., [ANTLR4](https://www.antlr.org), [Catch2](https://github.com/catchorg/Catch2), [CMake](https://cmake.org/), [Doxygen](https://www.doxygen.nl/), [loguru](https://github.com/emilk/loguru), [Java](https://www.java.com), [LLVM](https://www.llvm.org).  To simplify dependency management the project provides a [bootstrap](bin/bootstrap.sh) script to install all of the required dependencies on linux ubuntu and mac platforms; if you are using `portal.cs.virginia.edu` to build then you can replace this script with running `module load \u003cpathto\u003e/tipc/conf/modulefiles/tipc/F24`, where `\u003cpathto\u003e` is the path to where you have installed `tipc`.\n\n## Building tipc\n\nThe project uses [GitHub Actions](https://docs.github.com/en/actions) for building and testing and [CodeCov](https://codecov.io) for reporting code and documentation coverage.  The [build-and-test.yml](.github/workflows/build-and-test.yml) file provides details of this process.  If you would prefer to build and test manually then read on.\n\nAfter cloning this repository you can build the compiler by moving to into the top-level directory and issuing these commands:\n\n```bash\n./bin/bootstrap.sh\n. ~/.bashrc\nmkdir build\ncd build\ncmake ..\nmake\n```\n\nThe build process will download an up to date version of ANTLR4 if needed, build the C++ target for ANTLR4, and then build all of `tipc` including its substantial body of unit tests.  This may take some time - to speed it up use multiple threads in the `make` command, e.g., `make -j6`.\n\nYou may see some warnings, e.g., CMake policy warnings, due to some of the packages we use in the project.  As those projects are updated, to avoid CMake feature deprecation, these will go away.\n\nWhen finished the `tipc` executable will be located in `build/src/`.  You can copy it to a more convenient location if you like, but a number of scripts in the project expect it to be in this location so don't move it.\n\nThe project includes more than 300 unit tests grouped into several executables. The project also includes more than 90 system tests. These are TIP programs that have built in test oracles that check for the expected results. For convenience, there is a `runtests.sh` script provided in the `bin` directory.  You can run this script to invoke the entire collection of tests. See the `README` in the bin directory for more information.  \n\nAll of the tests should pass.\n\n### Ubuntu Linux\n\nOur continuous integration process builds on both Ubuntu 22.04 and 20.04, so these are well-supported.  We do not support other linux distributions, but we know that people in the past have ported `tipc` to different distributions. \n\n### Mac OS\n\nOur continuous integration process builds on macOS 12 and macOS 13 so modern versions of macOS are well-supported.  `tipc` builds on both Intel and Apple Silicon, i.e., Apple's M1 ARM processor.  \n\n### Windows Subsystem for Linux\n\nIf you are using a Windows machine, tipc can be built in the Windows Subsystem for Linux (WSL). [Here](https://docs.microsoft.com/en-us/windows/wsl/install-win10#update-to-wsl-2) are instructions to install WSL and upgrade to WSL2. It is highly recommended to upgrade to WSL2. Once installed, you should install\n[Ubuntu 20.04](https://docs.microsoft.com/en-us/windows/wsl/install-win10#update-to-wsl-2). Once finished, you can open a virtual instance of Ubuntu and follow \nthe instructions above to build tipc. \n\nYou may recieve an error saying \"No CMAKE_CXX_COMPILER could be found\" when running `cmake ..`. If this is the case, you should install g++ with the command: `sudo apt-get install g++`.\n\n## Using tipc\n\nThe `tipc` compiler has a limited set of options available through the `--help` flag.\n```\nOVERVIEW: tipc - a TIP to llvm compiler\n\nUSAGE: tipc [options] \u003ctip source file\u003e\n\nOPTIONS:\n\nGeneric Options:\n\n  --help                 - Display available options (--help-hidden for more)\n  --help-list            - Display list of available options (--help-list-hidden for more)\n  --version              - Display the version of this program\n\ntipc Options:\nOptions for controlling the TIP compilation process.\n\n  --asm                          - emit human-readable LLVM assembly language\n  --do                           - disable bitcode optimization\n  --log=\u003clogfile\u003e                - log all messages to logfile (enables --verbose 3)\n  -o=\u003coutputfile\u003e                - write output to \u003coutputfile\u003e\n  --pa=\u003cAST output file\u003e         - print AST to a file in dot syntax\n  --pcg=\u003ccall graph output file\u003e - print call graph to a file in dot syntax\n  --pi                           - perform polymorphic type inference\n  --pp                           - pretty print\n  --ps                           - print symbols\n  --pt                           - print symbols with types (supercedes --ps)\n  --verbose=\u003cint\u003e                - enable log messages (Levels 1-3) \n                                    Level 1 - Basic logging for every phase.\n                                    Level 2 - Level 1 and type constraints being unified.\n                                    Level 3 - Level 2 and union-find solving steps.\n```\nBy default it will accept a `.tip` file, parse it, perform a series of semantic analyses to determine if it is a legal TIP program, generate LLVM bitcode, and emit a `.bc` file which is a binary encoding of the bitcodes.  You can see a human readable version of the bitcodes by running `llvm-dis` on the `.bc` file.\n\nTo produce an executable version of a TIP program, the `.bc` file must be linked with the bitcode for [tip_rtlib.c](rtlib/tip_rtlib.c).  Running the `build.sh` script in the [rtlib](rtlib) directory once will create that library bitcode file.\n\nThe link step is performed using `clang` which will include additional libraries needed by [tip_rtlib.c](rtlib/tip_rtlib.c).  \n\nFor convenience, we provide a script [build.sh](bin/build.sh) that will compile the tip program and perform the link step.  The script can be used within this git repository, or if you define the shell variable `TIPDIR` to the path to the root of the repository you can run it from any location as follows:\n```\n$ cd\n$ more hello.tip\nmain() { return 42; }\n$ $HOME/tipc/bin/build.sh hello.tip\n$ ./hello\nProgram output: 42\n$ $HOME/tipc/bin/build.sh -pp -pt hello.tip\nmain() \n{\n  return 42;\n}\n\nFunctions : {\n  main : () -\u003e int\n}\n\nLocals for function main : {\n\n}\n```\n\n## Working with tipc\n\nThe instructions above, and the scripts described below, make it possible to develop from the command line.  This gives you lots of control, but it means you will miss the benefit of modern IDEs.   Below we describe how to set up the CLion IDE for use with the project.\n\n### Command line\n\nDuring development you need only run build steps 1 through 5 a single time, unless you modify some `CMakeLists.txt` file.  Just run `make` in the build directory to rebuild after making changes to the source.\n\nIf you do need to add a source file then you will have to edit the appropriate `CMakeLists.txt` file to add it.  In this case, you should:\n  - `cd build`\n  - `rm CMakeCache.txt`\n  - `cmake ..`\n\nwhich will regenerate the makefiles that you can then run, by typing `make`, to build.\n\nNote that the `tipg4` directory has a standalone ANTLR4 grammar.  It's README describes how to build it in isolation and run it using the ANTLR4 jar file.\n\n### The bin directory\nTo facilitate development of `tipc` we have collected a number of helper scripts into the `bin` directory of the project. Among them are scripts to run the entire test bed (`runtests.sh`), to run a code coverage analysis (`gencov.sh`), and to generate the project documentation (`gendocs.sh`).  Please see the `README` in the bin directory for example usages.  \n\nWhen rebuilding and rerunning tests you may get errors about \nfailing to merge `gcov` files. This happens when `gcov` files linger from previous\nruns. To cleanup these messages, simply run the `cleancov.sh` script.\n\n### CLion\n\n[CLion](https://www.jetbrains.com/clion/) is C++ IDE that can be used to develop and build tipc. CLion can be installed with the JetBrains suite of tools, or as a standalone tool [here](https://www.jetbrains.com/help/clion/installation-guide.html#standalone). Once installed, you can start a 30 day trial license or, as a student, you can get a free educational license [here](https://www.jetbrains.com/community/education/#students).\n\nThese instructions are with respect to CLion 2023.1.3, but older or new versions work similarly - though the UI may be a bit different.\n\nIf you are building for the first time with CLion, follow the first two steps of the installation process to install any needed tipc dependencies. \n\nFrom the `File` menu select `New` and then `Project from Version Control`.  You can type in the URL for this github repository and then hit the `Clone` button.   The scripts described above assume a directory structure, but a little bit of setup will synchronize your CLion project with those assumptions and allow for easy development using both CLion and scripts, when needed.\n\nFrom the `CLion` menu select `Build, Execution, Deployment` and then `CMake`.  You want to change the `Build directory` to `build` and then define an `Environment` variable.   When you ran the `bootstrap.sh` script it defined a shell variable `LLVM_DIR` in your `.bashrc`.  Copy that definition into the `Environment` field under `Cache variables`.  Your `Settings` should look as follows:\n\n![CLion CMake Settings](docs/assets/clion/clion_settings_for_tipc.png)\n\nNow you can click `Apply` and then `OK` to complete the setup.\n\nThe project can now be built or rebuilt by clicking the \"Build\" button in the toolbar.\n\nCLion has great debugging support as well as test coverage support for the Catch2 tests included in the project.  You will rarely need to use the commandline scripts, but if you do just move to `~/CLionProjects/tipc` and you can execute them there to:\n 1. resolve `gcov` merge errors by running `cleancov.sh`\n 2. run system tests with `runtests.sh`\n 3. generate documentation with `gendocs.sh`\n\nCLion also has some nice plugins.  For example, there is an [ANTLR v4](https://plugins.jetbrains.com/plugin/7358-antlr-v4) plugin that allows you to more easily develop extensions to the grammar for TIP.  Installation is easy, just click on the `Install to CLion ...` button on the web-page.  Then right click on any rule and select `Test Rule ...` and two frames pop up at the bottom of the UI: the left frame allows you to type in fragments of input and the right frame shows the resulting parse tree.\n\n### Log Messages\nWhen working on the tipc compiler, it may be helpful to enable logging messages when testing your changes on programs. We have inserted logging messages using loguru. These can be turned using the flag `--verbose [x]` where x is a number between 1-3. These messages get more verbose as you increase x. The first setting shows when symbols are added to the symbol table and when type constraints are generated for the type solver. The second setting shows the previous information and type constraints being unified. The third setting shows types being search for and added into the type graph. When adding to theses features, you can add logging messages by adding a line `LOG_S(x)` where x is an integer to describe the level of log verbosity you want. You can use the existing levels or make new levels.\n\n## Code Style\ntipc follows [llvm coding\nstandards](https://llvm.org/docs/CodingStandards.html#llvm-coding-standards).\n`clang-format` is used to apply the llvm style rules. The following command can\nbe used to apply the llvm style across the tipc `src` directory. \n```bash\nfind src -iname *.h -o -iname *.cpp | xargs clang-format -style=llvm -i\n```\n\nUsing [pre-commit](https://pre-commit.com/) we can enforce styling before each\ncommit. This is encourged to keep a uniform style across the codebase. Install\npre-commit by following the\n[instructions](https://pre-commit.com/#installation) in their documentation.\nThen, install the tipc hooks by running,\n```bash\npre-commit install\n```\n\nNow, `c++` and `cmake` formatting will be checked before each commit. \n\n## Documentation\n\nThe TIP grammar, [tipg4](./tipg4/TIP.g4), is implemented using ANTLR4.  This grammar is free of any semantic actions, though it does use ANTLR4 rule features which allow for control over the tree visitors that form key parts of the compiler.  This allows the structure of the grammar to remain relatively clean, i.e., no grammar factoring or stratification needed.  \n\nThe `tipc` compiler is has a pretty classic design.  It is comprised of four phases:\n * [frontend](./src/frontend) takes care of parsing, constructing an AST representation, and pretty printing\n * [semantic analysis](./src/semantic) that performs assignability, symbol, and type checking\n * [code generation](./src/codegen) that produces LLVM bitcode from an AST and emits a binary\n * [optimization](./src/optimizer) that runs a few LLVM optimization passes to improve the bitcode\n\nDoxygen [documentation](https://matthewbdwyer.github.io/tipc) for the project is \navailable for the project.  The documentation is a work in progress \nand will improve over time.\n\nThe `tipc` driver program only produces a bitcode file, `.bc`. You need to link it \nwith the [runtime library](./rtlib/tip_rtlib.c) which define the processing of command \nline arguments, which is non-trivial for TIP, establish necessary runtime structures, \nand implement IO routines. A [script](./bin/build.sh) is available to link binaries \ncompiled by `tipc` with the runtime library.\n\n## Goals and Plans\n\nThe goal of this project is to provide a starting point for project work in an undergraduate compilers course.  As such it similar to lots of other compiler projects, but there are some differences.\n\nFirst and foremost, the TIP language includes a number of rich features, e.g., high-order functions, and type inference, and the `tipc` compiler targets LLVM - a key component of a production compiler infrastructure.  These choices are intentional and while they create some challenges the project is intended to help demystify complex language features, e.g., parametric polymorphism, by illustrating how they can be realized.\n\nSecond, the project attempts to use modern software development practices, e.g. Doxygen for in-code documentation, unit testing with Catch2, continuous integration with GitHub Actions, and code coverage with `lcov`.  \n\nThird, the project intentionally makes heavy use of the [Visitor pattern](https://en.wikipedia.org/wiki/Visitor_pattern) which is quite appropriate in the context of a compiler.  Our use of it is intended to demonstrate how this type of abstract design element in a system can yield conceptual simplicity and savings in development.   The project currently uses 6 visitors that extend [ASTVisitor](./src/frontend/ast/ASTVisitor.h) and another visitor from ANTLR4.\n\nFinally, the project is implemented in C++17 using modern features.  For example, all memory allocation uses smart pointers, we use unique pointers where possible and shared pointers as well, to realize the [RAII](https://en.wikipedia.org/wiki/Resource_acquisition_is_initialization) pattern.  Again this presents some challenges, but addressing them is illustrated in the `tipc` code base and hopefully they provide a good example for students.  \n\nThe project is a work-in-progress in the sense that we are planning to perform corrective maintenance, as needed, as well as perfective maintenance.  For the latter, we expect to make a new release of the project in early August every year.  This release will focus on improving the use of modern C++\nand to incorporate better design principles, patterns, and practices.\nWe welcome issue reports and pull-requests along these lines.\n\n## Differences from TIP and Limitations\n\nOther than issues related to the efficiency of the code that it generates, the `tipc` compiler has two limitations.\n\n`tipc` supports a variant of the TIP language semantics in a few ways.  It implements the `!=` operator which allows us to conveniently write self-contained system tests and it implements the [C operator precedence rules](https://en.cppreference.com/w/c/language/operator_precedence), whereas the original TIP uses a few different rules.  This surfaces in the interplay between pointer dereference and field access.  An expression `*r.f` is interpreted as `*(r.f)` according t the C precedence rules and as `(*r).f` according to the [TIP Scala](https://github.com/cs-au-dk/TIP) implementation.  If in doubt, add parentheses to express your meaning.\n\nBy default `tipc` implements the unification-based monomorphic type inference algorithm used in the [Scala implementation](https://github.com/cs-au-dk/TIP/).  `tipc` also support a form of polymorphic type inference using the `--pi` option.  To use polymorphic type inference programmers can add the `poly` keyword to a function declaration, but `tipc` will only perform polymorphic type inference for such functions if they are non-recursive.\n\nThere is also a difference in type inference related to records.  The type system that ensures that any expression appearing in the record position of a field access expression is in fact a record, but it does not infer precise record typing.  Instead the strategy used is to define an *uber* record that consists of all of the fields referenced across the program. Code generation for records will allocate a global record and then explicitly initialize fields present in a record expression. If the record is being created via an `alloc` expresion, the fields that aren't explictly set will be set to a default value 0, as we allocate memory using the C function `calloc`. If the record is being created without explictly allocating memory for it, the fields that aren't explictly set will not be given any value, but may still be referenced. This can lead to some unexpected behavior.  Consider this TIP program:\n```\nmain() { var r; r = {g:1}; return access(r); }\naccess(r) { return r.f; }\n```\nThe record expression, `{g:1}`, forces the global record to contain a field `g`, and the access expression `r.f`, forces the presence of field `f`. Because `r` is not being allocated using an `alloc` expression, access will return whatever value was in memory at the location of `r.f`. \nOne might prefer that this program yield a type error, but that would require a more sophisticated type system.  We chose not to implement that to manage the complexity of what is primarily a pedagogical project. If instead, r is allocated using `alloc` like the following:\n```\nmain() { var r; r = alloc {g:1}; return access(r); }\naccess(r) { return r.f; }\n```\nThe record expression default initializes `f` to `0` and this is the value that is accessed and returned from the call to `access` and then from `main`.  \n\nSecond, TIP allows memory allocation, yet its runtime system does not include a garbage collector.  \nThe TIP program [recordLeak.tip](test/system/leak/recordLeak.tip), shown below, leaks memory because the `alloc` constructor causes the record to be allocated on the heap:\n```\n// recordLeak.tip\nfoo(x,y,z){\n    var rec;\n    rec = alloc {l: x, m: y, n: z};\n    return (*rec).m;\n}\n\nmain(){\n    var i, j, a;\n    a = 0;\n    i = 0;\n    j = 0;\n    while (1000000000 \u003e i) { \n      while (1000000000 \u003e j) { \n        a = a + foo(3,2,4);\n        j = j + 1;\n      }\n      i = i + 1;\n    }\n    return 0;\n}\n```\nThis is a valid tip program which can be compiled into an executable using and observe it's memory usage using:\n```\n/path/to/tipc/bin/build.sh --do test/system/leak/recordLeak.tip\n./recordLeak \u0026; top\n```\nYou can then kill top using `Ctrl+C` and then kill the ./recordleak with `fg` and `Ctrl+C`. It's important that you disable the optimizer with the `--do` flag. Otherwise, the optimizer would be smart enough to simply return the `y` parameter's value. If we remove the alloc from `foo`, as we do in [recordNoLeak.tip](test/system/leak/recordNoLeak.tip), then the record is allocated on the call stack and it is reclained when the call to `foo` returns:\n```\n// recordNoLeak.tip\nfoo(x,y,z){\n    var rec;\n    rec = {l: x, m: y, n: z};\n    return (*rec).m;\n}\n\nmain(){\n    var i, j, a;\n    a = 0;\n    i = 0;\n    j = 0;\n    while (1000000000 \u003e i) { \n      while (1000000000 \u003e j) { \n        a = a + foo(3,2,4);\n        j = j + 1;\n      }\n      i = i + 1;\n    }\n    return 0;\n}\n```\nWe can find that this program will not create a memory leak because rec will be allocated on the stack instead of the heap as the alloc would.  \n\nIncorporating a garbage collector is a possible future extension to the runtime library.\n\n## Resources\nTo fully understand this project quite a bit of background is required.\nWe collect a number of resources that we think can be helpful in that regard.\n\n### C++ Resources\nIf you find yourself unfamiliar with certain aspects of the C++ programming\nlanguage we encourage you to explore the *Back To Basics* videos that have\nbeen presented at [CppCon](https://cppcon.org/). Provided below are links\nto a number of these videos, as well as to other resources that are relevant \nto this project.\n\n#### Move Semantics\n+ [Move Semantics (part 1 of 2)](https://youtu.be/St0MNEU5b0o)\n+ [Move Semantics (part 2 of 2)](https://youtu.be/pIzaZbKUw2s)\n\n#### Value Categories\n+ [Understanding Value Categories](https://youtu.be/XS2JddPq7GQ)\n+ [“New” Value Terminology](https://www.stroustrup.com/terminology.pdf)\n\n#### Smart pointers\n+ [Smart Pointers](https://youtu.be/xGDLkt-jBJ4)\n\n### CMake Resources\n+ [CMake docs](https://cmake.org/cmake/help/v3.7/)\n+ [More Modern CMake](https://youtu.be/y7ndUhdQuU8)\n+ [Oh No! More Modern CMake](https://youtu.be/y9kSr5enrSk)\n\n### Catch2 and Unit Testing Resources\n+ [Catch2 docs](https://github.com/catchorg/Catch2/tree/master/docs)\n+ [Modern C++ Testing with Catch2](https://youtu.be/Ob5_XZrFQH0)\n\n### LLVM Resources\n\nTo understand this code, and perhaps extend it, you will want to become familiar with the [core LLVM classes](http://llvm.org/docs/ProgrammersManual.html#the-core-llvm-class-hierarchy-reference).  It can be difficult to absorb all of the information in this type of documentation just by reading it.  A goal-directed strategy where you move back and forth between reading code and reading this documentation seems to work well for many people.\n\nIf you are familiar with the [LLVM tutorial](https://llvm.org/docs/tutorial/) you will see its influence on this compiler which leverages idioms, strategies, and code fragments from the tutorial.  The LLVM tutorials are a great starting point for understanding the APIs in the context of compiling.\n\nThere is lots of great advice about using LLVM available:\n  * https://www.cs.cornell.edu/~asampson/blog/llvm.html\n  * the [LLVM Programmer's Manual](http://llvm.org/docs/ProgrammersManual.html) is a key resource\n  * someone once told me to just use a search engine to find the LLVM APIs and its a standard use case for me, e.g., I don't remember where the docs are I just search for `llvm irbuilder`\n  * LLVM has some nuances that take a bit to understand.  For instance, the [GEP](https://llvm.org/docs/GetElementPtr.html) instruction, which `tipc` uses quite a bit given that it emits calls through a function table.\n  * LLVM15+ have implemented the concept of \"Opaque Pointers\", this removes all the typed pointer implementations and associated functions.\n    * [LLVM Docs on OpaquePointers](https://llvm.org/docs/OpaquePointers.html) talks about this in reasonable detail.\n    * [Here](docs/OpaquePointers.md) is a Quick summary of the change and how that affects tipc.\n### Git Resources\n+ [Pro Git Book](https://git-scm.com/book/en/v2)\n+ [Git For Ages 4 And Up](https://www.youtube.com/watch?v=1ffBJ4sVUb4)\n\n### CLion Resources\n* [Using Git in CLion](https://www.jetbrains.com/help/clion/using-git-integration.html)\n* [Using CLion with WSL](https://www.jetbrains.com/help/clion/how-to-use-wsl-development-environment-in-clion.html#wsl-tooclhain)\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fwkaisertexas%2Fsipc","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fwkaisertexas%2Fsipc","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fwkaisertexas%2Fsipc/lists"}