Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - bas

Pages: [1] 2 3 ... 7
General Discussion / Re: State of progress?
« on: July 15, 2018, 09:24:39 PM »
C2 is definitely not going as fast as I would like, but it's definitely not dead either. Work and family life does
take a big toll on available time. Luckily it's already quite usable, so people (me included) can play around
with it to get a feel and evaluate it for parts that could be improved.

Parts where C2 still needs developers:
- LLVM IR  generation
- inline assembly support
- some tooling (syntax highlighting, style formatting)

Ideas / Re: What about initialization in conditions?
« on: June 27, 2018, 09:01:32 AM »
Currently in C++ it's possible to do (using pointer now)

Code: [Select]
while (Ptr* p = getPointer()) {

This compiles to the exact same thing. So each iteration, p is assigned a value from a call to getPointer().
So this call could have an internal iterator state and return NULL once it's done. These type of constructions
are also used in clang itself because they lower the scope of p.

General Discussion / Re: Struct "inheritance"
« on: June 27, 2018, 08:57:23 AM »
struct 'inheritance' in already possible in C by just having the other struct as (first) member.
Also, you can already have object-oriented like features by adding function pointers in a
struct (also in C). Those two cover you example already..

General Discussion / Re: Complex numbers
« on: June 25, 2018, 09:00:29 AM »
Since C2 is a descendant of C and has no symbol-mangling, function overloading (multiple functions with same name bit with different arguments)
is not supported. I recently looked at Zig ( a bit and they allow putting functions on many constructs, like types, enums etc. This could
also be implemented in C2..

Code: [Select]
type Color enum u8 { Red, Green, Blue }

func bool Color.isRed(const Color* color) {
  return *color == Red

General Discussion / Re: Struct "inheritance"
« on: June 25, 2018, 07:53:02 AM »
I think your proposal would complicate the language and create more corner cases. The only thing gained would be
that instead of a developer could use Right?

I agree with your extension idea. When compiling C2 code, the compiler has a global view
of the code (ie not per-file, but the whole lib/binary). Thus there can never be multiple functions
with the same name. This also goes for struct functions. While it would be possible to let other
modules add functions to a struct; these functions would have to be globally unique.

This does not have to be a problem, but the error message might be an indication for the developer
to refactor some code..

Ideas / Re: What about initialization in conditions?
« on: June 23, 2018, 07:29:29 AM »
Making the scope of variables smaller is always a good thing.
C2 currently already supports the (C++) syntax of

Code: [Select]
while (Height h = getHeight()) {

So in terms of formal syntax, this means

Code: [Select]
while ( decl/expr ) {

instead of

Code: [Select]
while ( expr ) {

While making the scope smaller is nice, we also should try to allow avoid complex constructions like
Code: [Select]
while ( u32 x = get(), u32 y = getY(); x < y && x > 0) {

because this makes the code unreadable. Maybe a single decl would be a middle way that
covers most situations and avoids excess complexity..

When a struct (Type) is defined in some module, it makes sense to also place the operations on
that type in the same module. This way, they are automatically shared between all users of that module.
Also it prevents ambiguity, that there can only be one function named x for that type. So there can
never be a A.x() in one module and B.x() in another.

Implementation Details / Rebased on clang-60
« on: March 28, 2018, 08:43:13 PM »
C2C is now based on LLVM/Clang 6.0. The port was rather easy and took 20 minutes (excluding time to build LLVM/Clang).
The only nasty thing was a shift in arguments in include/clang/Basic/DiagnosticSemaKinds.def. This gives runtime asserts,
but luckily one of the unit tests broke, so it was very easy to detect and locate.

The performance seems to be the same and I've noticed no other differences. The clang binary does seem to have grown
another 5MB (87 -> 92 MB), all nice features I'm sure ;)

Implementation Details / cross-compilation using build file
« on: March 22, 2018, 10:27:54 PM »
I've recently added the concept of a build file to C2. I would like to explain some design choices here.

The C2 compiler used to use a single configuration file called the recipe. The recipe describes:
  • which targets and type (executable or library
  • which source files for each target
  • the configuration options
  • some output options (whether to generate-c, deps, refs, etc)
  • which libraries the targets depend on
So the recipe only specifies which dependencies, not where to find them. Because C2 is also meant
for embedded systems where cross-compilation is a basic need, it should be easy to do. To handle
this, there now is a build file that specifies:
  • The target triple (eg arm-unknown-linux-gnueabi or x86_64-unknown-linux-gnu)
  • A list of library search directories
  • toolchain settings for the C-backend
When using a build file, C2C will only use paths from that build file. This makes it trivial
to isolate cross-builds between different targets. No need for sysroot like constructs.

The general idea is that the recipe file is written by the develops of the project. If the project has a lot
of configuration options (which could change the files that need to be compiled), a 'make menuconfig'
like tool could generate this.

The build file is either written by users or generated by a 3rd party build system like yocto/buildroot etc
The same recipe could be used to build for different targets by using a different build file for each.

To demonstrate this, the C2-examples archive has a working example for Ubuntu 17.04. See the
for instructions.

Future work
Currently C2 uses a <triple> subdirectory in each library directory, so it can hold libraries for multiple targets.
This is handy for now, but in a real system, an (external) build system will already have populated a sysroot-like
directory with all required libs. So this directory will be removed in the future.

Another step will be to add a Cargo-like (from Rust) tool that reads the recipe, downloads all required libraries and
generates the build file.

Cross-compilation for ansi-C is quire a hassle. Hopefully C2 can make this a lot easier.
For more documentation see

As always, other ideas/feedback is welcome.

Ideas / Struct Function declaration
« on: April 15, 2017, 09:22:04 PM »
With the current syntax, I think it's quite unclear when a function is a struct function. I would
like to try to make this more explicit. So hereby some ideas.

Code: [Select]
func void point_add(Point* p, int32 x) { .. }    // current syntax

func void Point_add(Point* p, int32 x) { .. }   // allow Upper-case as first char, so looks more like type Point

func void point_add[Point](Point* p, int32 x) { ..} /// hmm, 3 points in a

func void point_add(Point* p, int32 x) @{structfunc} { ..} // via attribute
func void point_add(Point* p, int32 x) @{struct='Point'} { ..} // via attribute, nr 2

func void Point.add(Point* p, int32 x) { .. }   // most explicit, via member operator


I like the last option best. The two arguments against it are:
  • it's harder to see what the c- function name is (point_add in all cases). The is actually currently
        the same for module attributes as well ( -> foo_bar)
  • The syntax breaks more with the ansiC style

What do you think?

General Discussion / Re: VLA crash
« on: March 15, 2017, 08:37:44 AM »
The issue reproduces nicely indeed. There seem to be several issues here. The first one
is that array subscript expressions were not marked at compile-time-constant (if they were).
That is fixed on a branch now. Since C2 allows more then C sometimes, I'll look carefully
at the order of evaluation, since it's otherwise easy to get loops in constant declarations
that we have to detect/avoid..

General Discussion / Re: Typo in manual
« on: March 06, 2017, 09:36:44 PM »
I hope you have a very pleasant flight eh experience from now on ;)

General Discussion / Re: Diffs to C99 and C11
« on: February 16, 2017, 04:50:44 PM »
There is a page called 'Changes from C' in the documentation that highlights some big changes. Otherwise
there are many smaller changes. Just look at some code fragments in the examples/ dir and the unit tests.

Macros in C/C++ work by including (copy-pasting) a header file into a .c/cpp file. The preprocessor then does
textual replacements. This is very flexible, but also prevents the compiler from many useful diagnostics
(or at least makes it very hard). There is a post about macros on the forum that explains the different use
cases for macros.

Variable length arrays are supported in function scope (just like newer C standards). At global scope, C2 allows
'adding' items from different parts of the code, but essentially at runtime these are fixed size. Multi-dimensional arrays
are supported just like C/C++.

OpenMP is not in the planning yet..

General Discussion / Re: clangd compilation server
« on: February 16, 2017, 04:45:06 PM »
Thanks for mentioning it here. I did catch something of it some time ago. This solution is nice for large C/C++ codebases
where compilation times are non-trivial. For C2 I haven't even found a good reason to multi-thread yet... (1.8 Mloc/sec parsing,
800Kloc/sec with analysis). Since the latest vim (7 if I remember correctly) they support pipes that can be used by plugins
to for example talk to a persistent server/daemon like this..

Pages: [1] 2 3 ... 7