Topics

16

Ideas / Big Renames

« on: June 03, 2014, 02:15:29 PM »

After a lot of thinking, I've decided to finally rename package -> module and use -> import.
A module is more a part of something bigger, while a package has something complete in
the name. Also it conforms to a lot of new generation languages.

17

Implementation Details / Update from LLVM 3.3 -> 3.4

« on: May 21, 2014, 08:32:00 PM »

Hi,

Upgrading from Clang/LLVM 3.3 to the latest 3.4 has been on the TODO list for a while, but has been
pushed minutes ago. The nasty part was that I had to manually compile GCC 4.8.2 on Ubuntu 12.04
32-bit (my laptop) to get to compile LLVM/Clang at all. On my desktop (Arch 64 bit, GCC 4.9.x), I
required some testing. The upgrade was a lot less work then the 3.2 -> 3.3 upgrade, so maybe the
Clang internal API seems to be stabilizing as well..

18

General Discussion / Results of language-enabled dependency generation

« on: May 12, 2014, 12:46:03 PM »

Today I've pushed the functionality to let the C2 compiler generate the full dependency graph for a project.
The output is in XML form and shows types, (global)variables and functions and their complete relationship.
Also the containing package is show and optionally the file they're in. (yes functions are in a single file! no
header/c-file issues here  )

To show how this works, I've analysed the puzzle.c2 example (c2lang.org/docs/puzzle.c2).
The resulting architecture is show in c2lang.org/docs/puzzle_arch1.png.
Then I refactored it, by extracting some functions/vars into a separate file (really easy, just move them to
a new file, add that to recipe and done). This results in c2lang.org/docs/puzzle_arch2.png.

While the example is very small, it already starts showing the potential of the language/tools.
The next step will be to integrate these into c2reto (C2 refactor tool), so that drag-n-drop refactoring
and continuous visualization is possible. I can't wait to see how that works out!

19

Implementation Details / update wk17

« on: April 23, 2014, 08:29:28 PM »

Hi,

Current progress on the C2 compiler has focused on the Analyser. Currently there are
over 250 unit tests to make sure it keeps working. Not an easy thing. Recently I've
added some checks for array initializations. While I've been programming C for a long
time, I've never realized just how many details there are to a compiler. Some situations:

    int[]   a;    // @error{definition of variable with array type needs an explicit size or an initializer}
    char[] b;   // @error{definition of variable with array type needs an explicit size or an initializer}

    int[]   c = 10;  // @error{array initializer must be an initializer list}
    char[]  d = 20;  // @error{array initializer must be an initializer list or string literal}
    uint8[] e = 20;  // @error{array initializer must be an initializer list or string literal}

    int[]   f = "foo"; // @error{array initializer must be an initializer list}
    char[]  g = "bar";
    uint8[] h = "faa";

    char[3] i = "bar";
    char[3] j = "hello"; // @error{initializer-string for char array is too long}

and that's just a tiny part.
But with a *Lot* of small steps, we're getting there. Slowly more and more situations
are being handled. While C2 is still a far way from being a full fledged C alternative,
the Analyser part is definitely showing it's advantages over gcc/clang. Getting warnings
about unused struct fields and unused types is very nice!

Hopefully the next update won't take as long as this one...

Bas

20

General Discussion / Interesting site (warning: radical ideas)

« on: April 08, 2014, 07:31:34 AM »

For those who want to 'think outside the box' about software development,
I've found a very nice ideas and set of tools, called Rebol.

http://www.rebol.com/

Gives some food for thought.

21

Ideas / Switch statement

« on: March 27, 2014, 09:11:44 AM »

Some new languages like C# changed the default behavior of a case statement so that it breaks by default.
I wonder if this would be an good for C2 as well. It would make writing case statements for concise, but we'd
need a keyword to specify fallthrough (fallthrough, next, ?). I currently lean to the default-break, unless there
are good arguments for default-fallthrough.

22

General Discussion / Integer Literal checking

« on: March 12, 2014, 01:22:11 PM »

Integer Literals in code are constants like 10, 20, -100, etc
The analyser in c2c currently distinguishes between 3 types of expressions:
fully compile-time-constant:  basically any number
partial compile-time-contant: a + 10
not compile time constant: a, calc()

Full:
char a = 128;   -> error 128 not in range of char, range [0, 127]
char b = 800 - 700;    // ok, since 100 is in range
So the entire expression is evaluated and checked against the range.

None:
char a = b;    // error if type of b is larger than char.
So just the types are checked

Partial: (this is where it starts to get fuzzy)
char a = 128 + b;  // (b = char) so should this be allowed?
or the previous example:
char b = 800 - 700 + a;   // char a, should this be allowed?

Here there are some choices I think:
1 don't check any ranges of partial ctc expressions
2 only allow subexpressions to be of same < smaller type/value
3 check if range could be ok(Clang has a crude implementation of this)

I would prefer option 2, since it is the most safe option, but it would
restrict programmers too much perhaps. I think this would be ok,
but what do you guys think?

Bas

23

Ideas / D-language Modules/Imports

« on: March 05, 2014, 10:11:00 AM »

Hi,

I've studied the Module/Import system of the D language (dlang.org). D is a
language that tries to be a better C++. It's good to see that there are lots
of similarities between D and C2. This means that more people make the same
choices, which probably means that can't be that bad.

Similarities are:

• Concept of Package(C2)/Module(D)
• Package/Module have public/private symbols
• D static import are equal to C2 use
• D non-static import are equal to C2 use local (allows symbol use without prefix)
• Use(C) / Import(D) statement
• Import Aliases: use as (C2) / import io = c.stdio (D)

Differences are:

• D modules are single file, whereas C2 Packages can consist of multiple files
• D allowes Modules to be prefixed with a 'Pakage', c.stdio
• C2 has a build-system, D uses external one (like Make)
• D allows public import, C2 doesn't have this concept
• D allows multiple import in 1 line: import a,b, C2 doesn't
• D allows scoped import, C2 doesn't
• C2 doesn't need the module scope operator like D (.x)

I'm very interested in the public import feature. Does anyone have experience with this
(drawbacks, large-scale problems, advantages?)

Another think I'm still thinking about is the concept of something bigger than
C2 Packages. In D these are called Modules, but D also has a concept of Package.
The only use I discovered was that the compiler automatically looks for pkg.module
in pkg/module.d. But maybe in C2 we can use this for something else..

Finally, I think 'Module' reflects the meaning a bit better than 'Package', so
maybe C2 will also follow this. Package was currently chosen to create distinction
from clang's 'Modules' concept.

Anymore?

Bas

24

General Discussion / C improvements

« on: February 26, 2014, 03:43:47 PM »

There are initiatives that try to improve the current C language. Below is a list of
initiatives I know of, but I'm also interested if there are others I don't know of yet.

• Clang modules
• Link-time optimization
• Clang Virtual FS (http://www.phoronix.com/scan.php?page=news_item&px=MTYwOTM)
• #pragma once
• pre-compiled headers
• Amalgation (merging c/h files together into 1 big file)

While these initiatives are nice, I feel they fall short of really improving the language. This is
understandable, because they try to remain compatible with C on a language level. I feel that
keeping this compatibitily at a lower (link/library?) level, allows for far greater improvements.
Hopefully we'll be able to demonstrate some in C2.

Edit: interesting LTO link: http://hubicka.blogspot.co.uk/2014/04/linktime-optimization-in-gcc-1-brief.html

Bas

25

Implementation Details / update wk41

« on: October 13, 2013, 04:11:11 PM »

A short update. The cpp/h files have been move to component subdirs. This makes it easier to show the
depenencies. Changing a components now requires less knowledge about the whole system.

Secondly the builtin types have been renamed.
i8 -> int16
i16 -> int32
..
u8 -> uint8
u32 -> uint32
..
f32 -> float32
f64 -> float64
This improves code readability.

26

Implementation Details / update wk37-wk40

« on: October 08, 2013, 09:03:58 PM »

Since it's sometimes hard to see what's happening by looking at the codebase; I though it'd be nice to
just start a regular 2-4 week update post series. This will be the first one.

The past 4 weeks saw quite some work on the analyser:

• symbol lookup and error-messages have been improved with the help of unit tests.
• better analysis of -> and . operators
• better analysis of type conversions, also in function arguments/return types
• bugfixes

I've added a feature to generate a dot file with the package dependencies (with the --deps argument). This file
can be converted into an image using:
dot -T png deps.dot > image.png

A LHS/RHS-argument (left/right-hand side) has been added to  analyseExpr(), so it can now check unused variables
and un-initialized use in the near-future.

And last but not least, c2c has been updated to LLVM/Clang 3.3 (from 3.2). This was not a big issue, since
the changes needed to clang are quite small. So pulling this update will require you to update as well (c2c
will not remain backwards compatible with 3.2).

The coming period will hopefully result in:

• file-dependency generation (the idea is to generate a Design Structured Matrix file)
• finally fixing the type of numeric constants (not so easy)
• start of implicit casts (needed for IR-code generation)

Bas

27

General Discussion / clang article on Modules

« on: August 26, 2013, 09:44:06 AM »

Clang seems to be roughly going in the same direction as C2 by using a 'Modules' strategy:

http://clang.llvm.org/docs/Modules.html

Interesting read. It basically tries to solve some of the same problems as C2. In my opinion
this is very nice, but ultimately will fail to solve the problems completely since staying compatible
has some very severe restrictions. Nonetheless, very interesting.

28

Ideas / Syntax of const pointers

« on: July 17, 2013, 07:39:26 PM »

I'm currently working on the Type system of C2 and ran into a syntax issue that
I would like to think about more and get more input about.

I'll start by briefly describing the syntax of (ansi-)C in this regard:

Code: [Select]

const intmeans an integer that cannot be changed.

Code: [Select]

int*a pointer to an integer. So far so good. Now for the tricky part:

Code: [Select]

const int*
int const*Both are equal and describe a pointer to an integer that cannot be changed. The pointer itself can be changed to point
at something else. Syntax here is already becoming more vague.

Code: [Select]

int* constOkaaaay So this is a constant pointer to an int. The int can be changed (through the pointer), but the pointer itself
will always point to the same int.

Code: [Select]

const int* constThe final version, both the pointer and the value it points to cannot be changed.

Since C2 tries to improve C, this piece of trickery begs to be upgraded.
I currently see 3 options:
1. Add some parentheses

ansi-C	->	C2
const int		const int
const int*		(const int)*
int* const		const (int*)
const int* const		const (const int*)

This does make it a bit more clear, but the syntax suffers also.

2. Require 2 steps for certain types:

ansi-C	->	C2
const int		const int
const int*		(const int)*
int* const		type IPtr int*; const IPtr
const int* const		type CIPtr const int*; const CIPtr

3. <Your idea here>

So please feel free to post.

29

General Discussion / Interesting article on linker problems

« on: July 17, 2013, 07:19:30 PM »

I came across a blog article about possible linker problems:

http://eli.thegreenplace.net/2013/07/09/library-order-in-static-linking/

The more I articles like these I read, the more I think C2 might be a good step
ahead. Tell me what you think.

Regards,
Bas

30

Implementation Details / Today: large update

« on: June 14, 2013, 09:11:11 PM »

Hi,

While I've been busy in general, I've managed to do some work on C2!
I've just pushed 48 patches to the C2Compiler archive. Included in the update are:

• parsing+analysing enum types and enum constants
• the analyser now checks a lot more (duplicate default cases, etc)
• c-code generation for the entire AST
• c-code generation can now generate headers
• c-code generation can generate 1 file per package or 1 file with everything
• IR-code generation can generate 1 file (Module) per package or 1 file with everything
• parsing ternary operator
• bugfixes
• replaced printf's with proper error messages

Next on the line is checking the left-hand values of expressions. For example int a = "hello"; should not be
allowed  .
After that the analysis part has a solid base and work can continue on loading external C libraries/headers,
like stdio.h.

Have fun! (I have),
Bas