Topics

1

General Discussion / clangd compilation server

« on: February 13, 2017, 07:22:40 PM »

https://reviews.llvm.org/rL294291

This is a concept that I think was discussed a couple of years ago.  It provides the compiler as a service rather than a library.   I thought it was an interesting idea back when it was first mentioned, but now someone has done it for Clang.

2

Implementation Details / incremental arrays

« on: January 20, 2017, 04:35:51 AM »

I was going through the language reference and finally read the section on incremental arrays.  Very nice!  That should eliminate a lot of ugly boilerplate early set up.

What are the limitations on the array additions?  Can they be in any compilation unit where the array is visible or do they have to be in the same compilation unit (i.e. file)?

3

Ideas / other data type extensions

« on: January 30, 2015, 08:01:28 PM »

In a previous post, I noted that specifying the endian-ness of a variable would be very useful.  When doing DSP-like operations in multimedia code, saturating arithmetic would be very useful.  It is possible to wrap this in a short inline function or macro in C, but then you will not use special instructions in CPUs that have them.

I thought about underflow/overflow traps too, but that is more than just a small extra type modifier.

Other thoughts?

Best,
Kyle

4

Ideas / control endian-ness of data and bit structs

« on: January 12, 2015, 08:19:45 PM »

I was thinking again about Bas' addition of bit fields in such a nice way into the system.  I have some code that implements a fairly ugly protocol (industrial control systems) and there are few bit fields, but the endian-ness of the bytes in the words is very important. 

I have lots of little inline (type safe and the compilers generally do smart things with them) functions that convert the values back and forth between host and target endian types. 

Given that I am looking at this kind of code a lot right now, I thought about things that would make my life a lot easier for low level hardware and protocol support.

• add keywords for designating endian-ness.  i.e. new "little" and "big" keywords that would be used in places where you also use unsigned or volatile today.
• bit structs

C is pretty good at handling bytes.  With packed structs, you can do a lot, but you still have to handle endian problems manually.

foo: int32 little_endian;
bar: uint16 big_endian;

Many hardware systems are controlled by bit fields and those fields may be big or little endian.  Some (there are engineers who probably need to rethink some of their designs) have both :-(

How about a "bitstruct"?

bitstruct [160] {
    control: integer [0..30];
    clear_interrupts: integer [31..31];
    command: integer [32..37];
    ugly_field: integer [38..42,49..53];
    ...
}

The array-like statement [160] defines the number of bits.  Fields within the bitstruct specify where the field is in the bits. 

It is common enough, though thankfully not that common, for some fields to be split into two or more sections.  I showed that with the "ugly_field" example.  I have seen cases where the most significant bits are before the least significant bits.  In that case we'd have something like:

ugly_field: integer [49..53, 38..42];

Ugly!

I am not sure how you would want the little_endian and big_endian keywords to work here.  Maybe you would specify it with the bit ranges like in ugly_field?

I just thought I would throw that out there.

Best,
Kyle

5

General Discussion / CLike

« on: September 25, 2014, 07:27:54 PM »

I'm not sure what to make of this project:

https://github.com/combinatorylogic/clike

It seems to target some of the same things as C, but has some advanced features.  I have not tried it yet.  I am a bit confused by the link with Mono (C#)

Best,
Kyle

6

General Discussion / friendly C

« on: September 03, 2014, 12:46:40 AM »

John Regehr has a new blog post about "friendly C".  This is not any sort of syntax change, and thus may not be all that useful here, but instead is a set of changes he wants to make to how compilers handle C code to make the results less surprising.

http://blog.regehr.org/archives/1180

I haven't been caught by undefined behavior in C compilers too often, but some of the cases I've read about can be very, very difficult to debug.

Best,
Kyle

7

General Discussion / SPECS: a new/old syntax for C++

« on: July 14, 2014, 06:37:01 PM »

While covering more than C, SPECS was an interesting attempt to create a more sane syntax for C++.  Ultimately, as can be seen, it failed to be adopted, but there is some very interesting stuff in there.

I find it interesting to see how many of the projects to fix the old C syntax have hit on the same things.  I don't like some of the things in SPECS, but it appears to be very well thought out.  Damian Conway is a very, very smart person (I know of him from the Perl world).

Here is a link:

http://www.csse.monash.edu.au/~damian/papers/PDF/SPECS.pdf

Note that SPECS was from 1996.  Almost 20 years ago.

Best,
Kyle

8

General Discussion / a sister project?

« on: July 11, 2014, 08:32:33 PM »

C! is a language that seems to have many of the same goals as C2.  It looks like it was more or less abandoned a year ago, but there is a lot there. 

git://git.lse.epita.fr/cbang.git

They target many of the same things: simpler syntax, ambiguous int sizes etc. and come up with some of the same ideas and some different.  I am reading through the intro docs now. 

The compiler was implemented in OCaml.  I do not know that yet, but hopefully I can figure out enough to follow it.

Best,
Kyle

9

Ideas / Weird ideas #5: "always on" compiler

« on: July 02, 2014, 12:29:03 AM »

This idea is not mine. I am not sure who came up with it.  I have seen it referenced from time to time for several years, most lately on the PiLuD mailing list.

The idea is this:

Instead of running the compiler when you have changed a file, make the compiler always run in the background and notice when a file changes. 

This can be accomplished now by combining some standard Linux tools (inotifytools etc.) with gcc/make.  But, it is not packaged all together.

So, the technology is there, but what can you do with it?  One of the ways this could work with C2 would be to trigger the compiler when a file changed.   Since C2 has a built in build system, you do not need as many extra tools. 

The inotifywait program can be run on a directory and will spit out a stream of things that changed.  This can be used with shell scripts to prototype something like this very quickly.  Now imagine that this was built in to the C2 compiler:

$> c2 --watch ~/myProject
$> cd myProject
$ myProject> vi main.c2
...

The nice part about decoupling the compiler from any IDE is that you can play with both the IDE and the compiler without worrying about the other one.  I.e. I can use vi, you can use emacs.  The compiler stays the same.

Best,
Kyle

10

Ideas / Built-in recipe handler/make replacement

« on: June 20, 2014, 11:28:10 PM »

I have read the point about having the compiler handle dependency resolution etc. so that there are fewer tools. 

I would like to point out that Java started that way.  Javac will go find included packages and compile the code if necessary.  However, in practice, this proved to be insufficient and now I almost always see Ant, Maven, or other build systems used instead.  I am not sure of all the reasoning behind this, but I can think of a few things:

0) it never really worked for more than very simple things. 

1) if there is any code generation going on (think yacc), then javac could not handle it.

2) going outside java for some artifacts did not work.  I.e when building a WAR file, you need all the crufty XML, images, static HTML etc. etc. as well as the .jar and/or .class files.

3) NIH syndrome.  Why else would we have make, cmake, scons, etc. etc. etc. etc. etc.

4) changes and additions to the build system required a release of the whole compiler.

I think go does most of the work for compiling Go code.  So, there is some backlash against separate tools.

I am not saying that combining the build system into one tool with the compiler is wrong, but there are some tradeoffs that should be thought about.

One example I really like is git.  The core git code (the plumbing) is a small set of tightly linked programs (they were in shell, now mostly C I think).  On top of that is the "porcelain" that provides varied and higher-level interfaces.   Go is much this way too, I believe. 

The caveat to all this is how does a different executable know how to link together various modules to run a program?  C has several steps to get to an executable.  The linker step is not part of the compiler (conceptually).  In C2 it is.  Modules make this a little trickier.  Certainly the pain of keeping Makefiles up to date is something to be avoided!

How can C2 keep that simplicity but avoid the problems that Java, for instance, ran into?

Best,
Kyle

11

Ideas / Weird ideas #4: standard bit fields etc.

« on: June 20, 2014, 09:26:22 PM »

Currently, the ordering and some of the semantics of bitfields appear to be implementation dependent.  It would be nice if C2 specified the exact ordering of bit fields and their behavior on all platforms. 

This comes from a discussion I started on LinkedIn in the "Plain Old C Programming" group.  Chris Ryan pointed out the problems with bit fields. 

Best,
Kyle

12

Ideas / Weird ideas #3: resource control

« on: June 19, 2014, 03:04:48 AM »

I was not sure what to call this.  One of the things I like about C# is the "using" construct because you can clean up afterward. 

Go has a similar concept, but very different syntactically with deferred functions:

f := open(...)
defer close(f)

I probably have the syntax wrong. 

The idea is that at the end of the block or function, the resource (a file here) is handled.  In this case closed.

I have started trying to build something like this with macros in C but have not gotten very far.

The idea I had was something like this:

Code: [Select]

using(buf = malloc(42)) {
   ... do savage and unnatural things to buf ...
} finally {
   free(buf);
}

The part inside the "using" would allocate or lock or create something and the code inside the finally part would clean it up.  I don't like the syntax because it seems imbalanced (parentheses for allocation and curly braces for clean up), but I like the idea a lot.  If general enough you could use it to lock mutexes, open files etc. etc.

Thoughts?

Best,
Kyle

13

Ideas / Weird ideas #2: variable sized structures

« on: June 19, 2014, 02:50:04 AM »

A common idiom in C is something like this:

typedef struct {
   int foo_count;
   struct foo[0];
} foo_list;

That foo[0] part (GCC syntax, MSVC is foo[]) means "don't allocate any space for this, but let me access the array of elements later".  It is heavily used for binary protocols and things where you want array access semantics to the foo elements, but you do not know in advance how many there might be and you are passed a blob of data.

I find the 0 or empty brackets ([]) to be something of a hack.  I would prefer a small syntactic change to use foo[...] or something like that.    At least to my eye, this means more clearly "we do not know how many there will be at this time".

Note that this is different from a dynamically sized array.  For that, you need a hidden count of the actual array size.  In fact, the implementation of a dynamic array might very well look like the example above.  I am not sure if using the same syntax for both would be a good idea.

Best,
Kyle

14

Ideas / Weird ideas #1: primitive data type sizes

« on: June 19, 2014, 02:41:27 AM »

Having ported code back and forth between platforms in C, one of the things that is very frustrating is the very vague definitions of "int", "short", "char", "long", "float" and "double".  While it is true that there were CPUs where a machine word was not 8, 16, 32 or 64 bits, that is extremely rare now.  I can't think of a single processor (that is actually used) where that is not the case now.  Chuck Moore's FORTH CPUs are the only ones I can think of and those are not exactly mainstream.

I find myself never using int, short, or char, and instead I always include stdint.h and use int32_t, int16_t and int8_t.  I need to know what size those integral types are.

Java made this mandatory.  "int" in Java is a signed 32 bit in.  Period.  No exceptions.  "long" is a signed 64-bit int.  Again, no exceptions.  While it is very annoying that Java decided that unsigned integers were not interesting, this conformity across platforms is quite handy.    I can use an int in a for loop in Java without worrying about what might happen if it is actually 16-bits on that platform.

I think it would be interesting if C2 would define char, short, int and long (and float and double) to be what people usually think they are (unless you are Microsoft): 8, 16, 32 and 64-bit words.  The translation to IR is straightforward if I understood the LLVM docs correctly (very possibly not!).  Any translation to C would be a simple mapping to one of the intX_t types.

Thoughts?

Best,
Kyle

15

Ideas / Apple's proposed addition of modules to C/C++

« on: June 19, 2014, 02:27:42 AM »

I know this has been hashed over, but Apple made a serious proposal for modules for C.  I thought that it was fairly well thought out.

http://llvm.org/devmtg/2012-11/Gregor-Modules.pdf?=submit

I thought that there was something else to see, but this is what I find with Google...

From what I remember at the time, the C and C++ language committees are (or at least were) seriously considering this proposal.  It seems pretty well thought out. 

Obviously C2 does not need the backward compatible parts, which is a large part of it!  But, there may be something to be learned.  If you've already seen this, feel free to ignore this post :-)

Best,
Kyle