programming language compiler
Go to file
Sven Vogel b786b3e156 added function return type 2024-08-04 16:20:23 +02:00
.github/workflows fixed: implicit function _fullpath 2024-06-05 11:49:55 +02:00
dep fixed: linker crashing 2024-06-10 00:11:53 +02:00
examples added examples 2024-06-10 02:12:20 +02:00
lib added stdlib tests 2024-08-02 18:01:39 +02:00
sdk added driver test 2024-07-21 01:36:44 +02:00
src added function return type 2024-08-04 16:20:23 +02:00
tests added function return type 2024-08-04 16:20:23 +02:00
.clang-format added .clang-format 2024-05-26 19:03:23 +02:00
.env added driver test 2024-07-21 01:36:44 +02:00
.gitignore added test for llvm vars 2024-05-27 16:47:32 +02:00
.gitmodules added git submodule tomlc99 2024-05-31 12:05:22 +02:00
CMakeLists.txt added token and parser rules for function return value 2024-08-02 18:48:24 +02:00
Dockerfile added driver test 2024-07-21 01:36:44 +02:00
LICENSE added GPLv2.0 license 2024-04-10 13:44:50 +02:00
README.md changed ASCII diagram to mermaid chart 2024-07-19 22:07:35 +02:00
ci-build.sh fixed: implicit function _mkdir 2024-06-05 11:54:27 +02:00
run-check-test.sh Merge remote-tracking branch 'origin/implement-stanard-library' into integrate-library 2024-06-10 00:29:51 +02:00
run-docker-build.sh fixed: llvm dependencies in sdk 2024-05-27 21:22:06 +02:00
run-lib-build.sh added io library 2024-05-25 13:50:21 +02:00

README.md

gemstone logo

Open source programming language compiler based on LLVM, GLib and GNU Bison/Flex
capable of multi target cross compilation powered by simple build system.



About

Gemstone is a programming language compiler (short: GSC) written in C based on flex and GNU bison. It uses LLVM to produce optimized native binaries for many platforms and uses its own builtin build system for more complex project management.

Architecture

Gemstone is a LALR enabled non-reentrant compiler utilizing a linear flow of components. The compiler has multiple stages of operation, each representing a crucial step in compilation.

---
title: GSC Architecture Overview
---
flowchart LR
    lex["`**Lexical Analysis**
        tokenization via flex`"]
    bison["`**Syntax Analysis**
        parsing via bison`"]
    set["`**Semantic Analysis**
        parse tree generation`"]
    llvm["`**Codegen**
        code generation via LLVM`"]
    driver["`**Linking**
          Linkage via Clang/GCC`"]
    
    start(("Start")) --> lex
    
    subgraph compile AST
        lex --> bison
    end
    
    subgraph Validation
        bison --> import{"Import/Include?"}
        import --> |yes| ast[[compile AST]] --> merge["Merge AST"] --> import
        import --> |no| set
        set --> llvm
    end

    stop(("End"))

    subgraph Codegen
        llvm --> lib{"Produce Library?"}
        lib -->|no| driver --> executable(["Executable"])
        lib -->|yes| library(["Library"])
    end
    
    library --> stop
    executable --> stop

Dependencies (build)

Windows 11

MSYS2

Install MSYS2 under Windows 11. Open the MingGW64 environment. Install the following packages:

pacman -S mingw-w64-x86_64-gcc mingw-w64-x86_64-glib2 bison flex mingw-w64-x86_64-llvm cmake git make

Clone the repository and build the gemstone compiler:

cmake . && make release

GNU/Linux

Requires:

  • GCC
  • CMake
  • Make
  • bison
  • flex
  • LLVM
  • Glib 2.0

Writing Tests

Since the project is build and configured through CMake it makes sense to rely for tests on CTest. All tests are located in the subfolder tests. In this directory is a CMakeLists.txt which specifies which tests are to be run. Actual tests are located in folders within tests and contain a final CMakeLists.txt which specifies what to run for a single test.

tests
  └─ test_group1
      └─ CMakeLists.txt  # specify tests in this group
      └─ ...             # test files of group 1
      
  └─ test_group2
      └─ CMakeLists.txt  # specify tests in this group
      └─ ...             # test files of group 2
      
  └─ CMakeLists.txt      # specify test groups to run
  
CMakeLists.txt           # build configuration

Development with VSCode/Codium

Recommended extensions for getting a decent experience are the following:

In order to remove false error messages from clangd CMake has to be run once in order generate compile_commands.json.

Build

The build pipeline is configured with CMake in the file CMakeLists.txt. In order to avoid dependency and configuration issues the recommended way to build is by using the provided docker containers. All tools required for building (cmake, make, gcc, lex, yacc) are installed inside the SDK container (see Dockerfile sdk/Dockerfile). For creating the build pipeline build the Dockerfile in the root folder of this repository. This takes the current SDK and copies the source files into the home of the build user. Then the make targets are generated. Running make release will build gemstone from source in release mode. The generated binaries can be found either in bin/release/gsc or bin/debug/gsc depending on the chosen target. The following graph visualizes the build pipeline:

flowchart LR
    
    subgraph Docker 
        alpine[Alpine Linux] --> sdk[SDK] --> dev[Devkit]
    end
    
    subgraph Build 
        dev --> |generate parser| bison[Bison]
        dev --> |generate lexer| flex[Flex]
        bison --> cc[GCC/Clang/MSVC]
        flex --> cc
        cc --> debug
        cc --> release
        cc --> check
    end
    

Docker images

Currently, the SDK is based on Almalinux 9.3, an open source distro binary compatible to RHEL 9.3.

The following images can be found in the offical repository at Docker Hub:

  • SDK
  • Devkit