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 ... 6
1
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 ;)

2
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 README.md
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 http://c2lang.org/site/build_system/intro/

As always, other ideas/feedback is welcome.

3
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 row..no

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() -> foo_bar)
  • The syntax breaks more with the ansiC style

What do you think?

4
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..

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

6
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..


7
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..

8
Implementation Details / Re: incremental arrays
« on: January 29, 2017, 11:16:30 AM »
The intention was indeed to remove a lot of macro magic by allowing incremental arrays. Currently all parts must be
in the same file I think, but I don't think there are problems when allowing multiple files in same module (since the order is
specified in the recipe).

9
Ideas / Re: Vectors in combination with semi-automatic memory management
« on: January 04, 2017, 08:04:00 AM »
C has a perfect mechanism to clean up what you allocate in a function: the stack.

When you need some piece of memory that has a bigger lifetime than the function, you use malloc.
So I'm a bit confused as well what you want. In C++ destructor functions are used to do the stuff you describe
(with smartpointer concepts).


10
Ideas / Re: Enum classes
« on: January 04, 2017, 07:45:40 AM »
Most modern C compilers will give a warning on this. In C2 this will just be an error and requires an
explicit cast to work..

11
Ideas / Re: Enum classes
« on: January 02, 2017, 08:30:36 PM »
The big advantage of explicit enum types would be to catch mistakes like:
Code: [Select]
type Temperature enum int8 {
  Low,
  High,
}

type State enum int8 {
  Begin,
  End,
}

State state = High;  // <- wrong enum constant

In languages where an enum is just an integer, the above would be perfectly fine. Currently the C2 compiler
catches these issues (but ATM doesn't give a nice diagnostic msg yet). So internally, enum constants have
the type of the enum (and not just int8). Maybe that's enough for now, since the only other advantage is being
able to have different enum types in the same module, with same enum constants (eg. both have a 'Middle')...

12
Ideas / Re: Struct Functions - part 2
« on: January 02, 2017, 08:19:35 PM »
In C2 'this' is not a keyword. It's just the name of the first argument used in struct functions. You are allowed
to use any name you want. The question was whether to let developers skip the 'this.member' and just type 'member'
inside struct functions. The compiler would then convert 'member' to '<name_of_arg0>.member'.
This way struct functions are a lot more similar to C++ class functions (where you are also allowed to use 'this->member'),
but can also just use 'member'.

13
General Discussion / Re: Pthreads
« on: January 02, 2017, 08:15:04 PM »
I think that in general most modern solutions tend to trade complexity for disk-space. Disk space is cheap, while
complexity is growing. So, for example, instead of having a complex package system with a lot of dependency-tracking,
a (big) application would just provide all the libs it needs itself. This is also basically the idea of Docker and such.

While I agree that it is often a good trade, it also feels a bit like admitting to a loss.

Building software can be quite straightforward, as shown by many (non-mainline) languages such as Ada etc. Remember
that the C2 compiler knows everything it needs to build the C2 code in the project. The only other things it needs to understand
are libraries (basically collections of symbols with some plumbing) and linking (format depends on platform). For stuff like
opening a file, C2 re-uses llvm libraries.

While it would be very nice to solve all the libc legacy, that is simply not a realistic way forward for C2 at the moment. So there
will be different versions of C2 libc for different platforms. Since C2 does *not* target Windows, most *nix systems don't differ
too much to cause real problems..  :)



14
General Discussion / Re: Question: how are growable arrays implemented?
« on: January 02, 2017, 03:44:32 PM »
C2 doesn't have growable arrays in the sense that they can grow during runtime. They can 'grow' during compilation. The C2 compiler just
merges all the 'array += value' declarations and creates a single (static) array. The may goal was to avoid having to use complicated macros when
you want to extend both an enum and a  data structure that uses the enum constants as index.

15
General Discussion / Re: C-domain useful features
« on: December 10, 2016, 09:26:03 AM »
Exactly, It's also a explicit non-goal to make the language help developers. What!?!?

With C2 my ideas is to restrict to language a bit more. This is similar to Python with the
one-way to do things. So if something is allowing in C, but in any of my project we would
disallow a certain construction (by agreement), in C2 this would simply be forbidden in the
language. This will make C2 programs more consistent and easier to read.

Pages: [1] 2 3 ... 6