Messages

211

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

212

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

213

Implementation Details / MILESTONE: multi-file and multi-pkg compilation!

« on: May 16, 2013, 08:41:57 PM »

It's been a while, since my last post, but that doesn't mean nothing is happening with C2.
The IR and C code generation have been refactored to a visitor pattern like clang uses. This allows us to take more
advantage of the clang code.

Additionally, the compilation has been changed from 'by file' to 'by package'. This means that each
C2 package is turned into one LLVM::Module. This is already working, which is pretty amazing. So you can
cut up your code and put types, global vars and functions in any order in any file of the same package and
C2 will compile it for you and still give you the performance optimization level of C statics. Wow!

Also multi packages (in multi files) is also working with the code generator generating (Module) external function
declarations for calls to other package functions.

What's currently really missing is a Unit test framework. I've looked into the LLVM framework, but don't
understand it far enough to incorporate it into C2 also.

The C2 compiler currently only generation IR code. With some LLVM/Clang tools, you can just compile this
to a normal .o / executable, but it would be nice if C2C could do that for you. So hopefully by the end of
June, this will be implemented.

Stay tuned!
Bas

214

General Discussion / Interesting article on Modules

« on: April 26, 2013, 08:04:57 AM »

I've found an interesting article on Modules and why the #include system doesn't work well. Check:

https://github.com/llvm-mirror/clang/blob/a2b3d58bb135dffeae3b73732adf38dff3682b46/docs/Modules.rst

It describes the case for a C2-like use/import system quite well 

215

Implementation Details / Clang::SourceManager

« on: March 29, 2013, 10:29:26 AM »

One 'problem'(challenge) I'm running into is that the clang SourceManager (that's used to handle
the C file and all its includes) cannot really handle multiple C (or C2) files. So the current implementation
of the c2compiler has 1 SourceManager per C2 file. The problem with this is that SourceLocations (for
Diagnostic messages etc) is resolved by the Sourcemanager, but in C2 this would require both the
SourceLocation and a pointer to the right SourceManager, which is really bad (since sourcelocations
are used everywhere). I've looked into the design of SourceManager, but it's not clear how much effort
it's gonna take to modify it to support multiple 'main' files. This would be option 1.

Option 2 would be to translate the clang SourceLocations to something else that can be translated
back to a SourceManager and the original SourceLocation. Hmm...

216

Ideas / Re: unifying '->' and '.' member accessors

« on: March 29, 2013, 10:24:45 AM »

Seems everyone is in favour, I'll put this on the list of things to be done. Hopefully it'll be in the next few weeks..

217

Ideas / unifying '->' and '.' member accessors

« on: March 07, 2013, 07:58:40 AM »

Hi,

I'm wondering whether to unify the accessors -> (for pointer types) and . (dot) for non-pointer structs/unions.
So both pointer and non-pointer types would simply use the dot. no more a->b.c, just a.b.c
The compiler can easily detect this, so implementation wont be a problem i think.

The advantage of this would be that it's easier for the programmer and less work when changing types from pointer
to non-pointer or reverse.
The dis-advantage would be that it doesn't show the member type at the calling site. I personally don't think this
is bad.

Any feedback?

218

Ideas / Re: C2 Package system

« on: February 19, 2013, 12:45:27 PM »

Thanks for your feedback!

I've added the 'use <long> as <short>' construction.
Additionally I've added the 'use <long> local' and 'use <long> as <short> local' construction.
The keyword local can thus optionally be added to a use statement. When added this means
that symbols from the used package can be used without package prefix. Any ambiguity still
causes an error.
So for stdio, the developer could do 'use stdio local' and then use 'printf' without prefix.

219

Joining / Registration

« on: February 15, 2013, 04:14:45 PM »

I had to turn off auto-registration, because the forum got completely spammen within 24 hours
(even with catcha and email registration)..

So for those who want to register, please mail me (bas @ this site) the username you want and i'll
manually register you.

Sorry for the inconvenience.

Bas

220

Ideas / C2 Package system

« on: February 05, 2013, 01:58:11 PM »

There was quite some interest in C2 at Fosdem'13 and I had some great
discussions afterwards. So that was very nice. Additionally there were
some great Ada presentations, which got me thinking as well.

This post is a RFC (request for comments) about the C2 package system. I
have some ideas and would like your feedback.

In brief, the current package design is:
- every file is in a package.
- multiple files can belong to the same package.
- when using symbols (functions/types/vars) from other packages, the packages
  has to be 'used' like:
   'use utils;'
- when using symbols from other packages, you only need to specify the package
  prefix if there are conflicts (A::Type and B::Type), otherwise you can just
  use Type.
- the package operator is '::'
- you can only use public types as return/argument type for functions.

The ideas i'm toying with are:
A. replace the '::' with '.', so package::symbol becomes package.symbol.
  The advantage would be better readability, but it would blur the distinction
  between struct.member and package.symbol.
B. The 2nd idea is to always require the full naming (so package::symbol)
  for external symbols. The disadvantage of this is more typing, while the
  advantage would be that adding a symbol to an external package will never
  break the using code. For example: if you have package T that uses packages
  A and B and there is a type A.Type, adding B.Type will break T.
C. Adding an optional 'as Y' option to use statements. So
  use my_long_package as mlp;
  This can partly negate the disadvantages for point B.
D. Each package symbol can be public or not. I'm thinking about adding a third
  option, just for type: 'opaque'. Opaque types may be used as (return/argument)
  types in public functions, but the clients can only use them to pass around
  (not derefence/use them). Clients would be able to allocate them on the stack,
  since sizeof() could be used on opaque types.
  The advantage of this keyword is that it makes the opaque-pointer pattern
  explicit. Also clients would only need a recompile if the sizeof() changes
  effectively.

So I'm interested in your opinions about:
Q: (A) what would be a better package operator? :: or . ?
Q: (B) require full specification of external symbols? (is this worth it/how
    big would the problem really be?/add -lax-naming option?)
Q: (C) What do you think about use <long> as <short>?
Q: (D) Any other options?
Q: any other ideas?

NOTE: I had to disable forum registration for SPAM reasons, but I'd be happy
to create an account for anymore. Just mail me your email/login-name.

Cheers,
Bas