• Stars
    star
    269
  • Rank 152,662 (Top 4 %)
  • Language
    C++
  • License
    Other
  • Created over 11 years ago
  • Updated about 1 year ago

Reviews

There are no reviews yet. Be the first to send feedback to the community and the maintainers!

Repository Details

OrangeC Compiler And Tool Chain

OrangeC

OrangeC Compiler And Tool Chain

Project Build Status: Build status Appveyor Build status Github Actions

Documentation status: Documentation Status

Coverity scan status: Coverity Scan Build Status

Orange C is currently a Win32 C++ compiler. Long term it is going to be retargetable.

The Orange C package also includes a C compiler for .Net, which compiles to MSIL/CIL. It is an offshoot of Orange C that is retargeted for .NET. Documentation may be found here: OCCIL documentation

Source Code for Orange C is released under the GNU General Public License version 3.

Current languages targeted by Orange C are C++14 and C11.

The tools in this package that aren't specific to this toolchain are also available in standalone repositories. This includes the ORC resource compiler,omake makefile utility, and a C++ library to generate and parse .NET assemblies.

The compiler can be built with various C++14 compilers, however, by default it is configured to use the Visual Studio 2022 community edition. A solution exists which will build all files in the project, or you can use the project's omake program to build it from the command line (you can also use MSBUILD if so inclined)

It is also possible to build with mingw32-make, recently we've also fixed that to work under the variants of MSYS2.

The compiler uses a binary output format, a variant of the IEEE-695 OMF. There are utilities to convert to the text version of IEEE-695. I've preferred this since it is easier to debug…

The make program is eerily similar to GNU make, however, with me never having the pleasure of actually using GNU make I don't know how close I got. The code was developed independently of GNU make, and without ever looking at the sources for GNU make.

At the moment there is only partial support for retargeting the compiler and toolchain. The toolchain introduces an extra phase to the usual compile-assemble-link process in the form of a post-link step called a downloader. Essentially the downloader takes the output of the linker and turns it into an OS-friendly executable file for whatever OS is being targeted. There are presently downloaders for WINDOWS 32 bit PE files, several DOS 32-bit file formats, and a downloader that generates HEX files for burning to EPROM.

The linker supports specification files to allow customization of the link and download processes; these files basically select a downloader based on command line switches and then guide the link process in generating an image that can be processed by the downloader. Meta-data may be added to the linker output using this mechanism as well, for example it is used in setting up default values for the objects in the PE file.

There is some support for retargeting the assembler; the instruction set may be completely customized in an architecture description file, which makes a set of tables to guide the translation from text to binary code. This is used to retarget the assembler code generation, and will eventually also be used in the compiler. There is some other data such as for assembler directives which will also eventually be placed into the architecture description…. And long term there is a goal of placing directives for translating the intermediate code into assembly language statements there as well.

There has been some thought as to eventually making this an x64 compiler, however, that would take a bit of effort as it wasn't well-supported while developing the code. Mostly, there are a lot of place that long-long values need to be passed around in the tools, where only int values are being passed around.

The Appveyor CI project for this repository builds a setup file after each checkin. It uses omake fullbuild to do this. See the file build.md for instructions on how to build the project.

The Read The Docs project for this repository verifies the documentation after each checkin.

For the project's history see the file HISTORY.md.