MSYS2/CLANG64 build success and some comments
Closed this issue ยท 5 comments
Hi,
I was able to easily build the oberon-lang repo on MSYS2/CLANG64 platform:
pacman -S mingw-w64-clang-x86_64-toolchain
pacman -S mingw-w64-clang-x86_64-boost
pacman -S mingw-w64-clang-x86_64-cmake
git clone https://github.com/zaskar9/oberon-lang.git
cd oberon-lang/
mkdir build
cd build
cmake .. -G "MSYS Makefiles"
make
Makefiles could be updated with support:
uname -s
MINGW64_NT-10.0-19045
MSYS2/CLANG64 platform is new, but seems to be stable and is an good option on the windows platform.
I was curious if I could use this compiler for embedded development and found some issues affecting this:
- The SYSTEM module seems missing. Several procedures here is needed for direct memory access.
- The SET type seems missing. This is useful for bit manipulation.
- There is a trick used in with binary constants which is useful: 'SYSTEM.ADR(
$0808 FFFF C3C3 C3C3 FFFF$ );' - The target triple configuration is not exposed for cross compilation.
I was thinking to build the compiler with the LLVM-embedded-toolchain-for-Arm
project as the Oberon language is really suited to this role with it simplicity and limited footguns compared to well known languages :-)
Hi Runar,
thanks for your interest in my Oberon compiler!
To give you a little bit of context, oberon-lang
is the side project of a side project of mine. It started out as a programming project that I designed for my Compiler Construction course at the University of Konstanz. Since then, I've added some features in my spare time, mainly to implement a couple of concepts that I teach in my course. My hope is that it will be a complete Oberon compiler one day, but there is no set timeline as the resources that I can dedicate to it are very scarce.
Nevertheless, I'm very grateful for your comments and I will add them to my list of missing features, along with open arrays, record inheritance, the CHAR
data type, etc. I'm currently refactoring the interplay of the parser and the semantic analyzer as it has become too inflexible to support the addition of these new features. By the way, I manage the development branches on the internal GitLab server of my university and simply push the main branch to GitHub occasionally to give access to colleagues who are not working at the Univeristy of Konstanz.
Last but not least, I was very pleased to read that you got my code to compile. As far as I know, you're only the second person after me to even try that!
I believe this is a project which deserve much more attention as it is very well structured, portable and targets the excellent LLVM infrastructure, therefore potensial supporting many platforms and have access to state of the art compiler technology.
It seems to be very close to being complete and usable.
I will keep a look at the progress and maybe later when the refactor is complete, contribute at least with testing out and reporting findings.
I confirm that cross compilation is working with the LLVM-embedded-toolchain-for-Arm
.
Turns out that exposing the target triplet is not sufficient as there is a large amount of configuration behind the scene i Clang depending on platform, cpu, os choices. So in order to get this correctly I compiled the Oberon file to LLVM IR and feed this to Clang.
I therefore believe we should remove the target triple argument unless we recreate the Clang logic connected to this and
expose further options as shown below.
Session run with qemu emulator with adapted c code example
> cat hello.mod
MODULE Hello;
(* Import `printf` function from C <stdio.h> library. *)
PROCEDURE printf(format: STRING; ...): INTEGER; EXTERN;
BEGIN
printf("Hello\n")
END Hello.
> oberon-lang.exe --filetype ll hello.mod
> clang --target=armv6m-none-eabi -march=armv6m -mfpu=none -mfloat-abi=soft -lcrt0-semihost -lsemihost -g -T ./ldscripts/microbit.ld -o hello.elf hello.ll
warning: overriding the module target triple with thumbv6m-none-unknown-eabi [-Woverride-module]
> llvm-objcopy -O ihex hello.elf hello.hex
> qemu-system-arm -M microbit -semihosting -nographic -device loader,file=hello.hex
Hello
Turns out that Clang will override any target information present in the IR file.
I post this here so that others can find this information and for feedback.
Perhaps not impressive, but I am very excited to get this working as compilation to embedded targets is usually a total pain in the ass and very often you need to use buggy tool chains from suppliers.
Update
The SET
data type (as a 32-bit word) is now available. Also available are the predefined set-related procedures INCL
, EXCL
, and ORD
. I've tried to make sets as efficient as possible by folding and evaluating as much as possible at compile-time. The run-time code that is generated for sets is a litany of shl
, lshr
, and
, or
, and xor
operations. ๐
Note: Adding the new data type has changed the symbol file format, making it incompatible with the previous version. As a consequence liboberon
has to be recompiled first.
Excellent!
I will take a look and also add relevant tests to the unittests suite.