Messages

76

General Discussion / Overwriting fields in init struct.

« on: November 18, 2018, 04:11:57 PM »

In this article:

https://lwn.net/Articles/444910/

The following method is discussed for setting better defaults of vtables than having NULL in C for the Linux kernel:

Code: [Select]

#define FOO_DEFAULTS  .bar = default_bar, .baz = default_baz
struct foo_operations my_foo = { FOO_DEFAULTS,
  .bar = my_bar,
};

The usefulness here is that having a meaningful default method, the test for NULL can be avoided. So instead of:

Code: [Select]

if (my_foo.bar != NULL) my_foo.bar();

We can simply use:

Code: [Select]

my_foo.bar();

Since the default method is assumed to be correct for the situation.

Currently in C2, this would not be possible. While I understand the need to "error proof" things, I think this should not be forbidden in C2, and instead produce a warning that can be supressed using an @(override), like this:

Code: [Select]

#define FOO_DEFAULTS  .bar = default_bar, .baz = default_baz
Foo_operations my_foo = { FOO_DEFAULTS,
  .bar = my_bar @(override),
};

OR by setting a @(weak) on the default:

Code: [Select]

#define FOO_DEFAULTS  .bar = default_bar @(weak), .baz = default_baz @(weak)
Foo_operations my_foo = { FOO_DEFAULTS,
  .bar = my_bar,
};


77

Implementation Details / I found this about implementing C very interesting

« on: November 18, 2018, 01:44:05 AM »

http://amp-blog.robertelder.org/building-broken-c-parsers/

78

Implementation Details / Re: Defer

« on: November 17, 2018, 02:00:03 PM »

Losing the boilerplate of cleanup at exit is great.

79

Ideas / Re: Readability of keywords "uint32", "float64" etc

« on: November 17, 2018, 01:59:04 PM »

I would have prefered using the well known Java convention of:

byte = i8
short = i16
int = i32
long = i64
float = f32
double = f64

Then extend to unsigned:

char = u8
ushort = u16
uint = u32
ulong = u64

However, if we want to support: i/u24 i/u48, f128 then that naming scheme is better. I prefer shorter if numbers are added. For the real horror example: NSUInteger of Objective-C on mac. That one is 32 bits or 64 depending on architecture. Aside from the obvious problem of 32/64 bit, the real pain is writing 4 uppercase followed by lower case. Hard to type as well as overly long.

80

Ideas / Re: Unified style for numbering system

« on: November 17, 2018, 01:44:20 AM »

What is the usecase? C2 supports standard binary, octal and hex notation. Why would this be needed?

81

Ideas / Re: other data type extensions

« on: November 16, 2018, 08:25:53 PM »

What could be done for C2 is to add a few things:

1. A way to ask (at compile time) what sort of overflow behaviour the processor supports.
2. A way to ask (at compile time) endianness of the processor.
3. A way to do wrapping add as built-in function
4. A way to do trapped add as built-in function
5. A way to ask (at compile time) how fast the a certain type of add is (fast, slow, emulated)

Those would only need to be macro defines.

82

Ideas / Re: Keyword "float" is not good to identify numbers

« on: November 16, 2018, 08:08:59 PM »

There are two dimensions:

1. What reads best
2. What people are used to

I'd say that with sufficient familiarity of a term, it becomes easier to understand than something with an objectively better name. "float32, float64, f32, f64" is in use a lot, "real32, real64" isn't.

I have a weak spot for "real" out of nostalgia for Pascal, but I'd say I'm an exception.

83

Ideas / Allow compile time variables (Part of macro proposal)

« on: November 16, 2018, 11:31:12 AM »

I suggest the introduction of macro compile time variables, prefixed with the sigil $. These can only hold compile time values and are evaluated top down.

This is a variant of what already exists in C, but in a syntactically more friendly way.

For example this would be ok:

Code: [Select]

macro swap(a, b) {
  $x = typeof(a);
  static_assert(typeof(b) == $x);
  $x temp = a;
  a = b;
  b = a;
}

The example above is a bit contrived as in the above example we could simply have:

Code: [Select]

macro swap(a, b) {
  static_assert(typeof(b) == typeof(b));
  typeof(a) temp = a;
  a = b;
  b = a;
}

But still, it serves as an example on how to use it.

84

Ideas / Require "type" where type is used outside of declarations.

« on: November 16, 2018, 11:22:26 AM »

For example, instead of

Code: [Select]

sizeof(Foo)
sizeof(a)
sizeof(i32)

Require

Code: [Select]

sizeof(type Foo)
sizeof(a)
sizeof(type i32)


85

Implementation Details / Defer

« on: November 16, 2018, 01:35:18 AM »

After several nights of work I'm finally done with defer  One big leap for simpler resource management.

Here's hoping it will be accepted folks! 

86

Implementation Details / Re: Code formatting of C2's c++

« on: November 16, 2018, 01:32:12 AM »

We can certainly use 4, but I'd just mention that this is different from how the current code looks that uses 4.

- Row breaks comments. I don't know if this is a good idea.

- Is it possible to require { } on if-else where each is a single statement?

Eg:

Code: [Select]

if (Res.isUsable()) Cases.push_back(Res.get());
else return StmtError();

// =>

if (Res.isUsable()) {
  Cases.push_back(Res.get());
} else {
  return StmtError();
}

Note that single line ifs are fine! Just not anything multi-line should have { }

Sometimes linebreak is weird:

Code: [Select]

    StmtResult Res = Actions.ActOnDeclaration(id->getNameStart(), idLoc, type.get(), InitValue.get());
// becomes
   StmtResult Res =
       Actions.ActOnDeclaration(id->getNameStart(), idLoc, type.get(), InitValue.get());
// instead of
    StmtResult Res = Actions.ActOnDeclaration(id->getNameStart(), idLoc,
                                              type.get(), InitValue.get());


87

Implementation Details / Re: Code formatting of C2's c++

« on: November 16, 2018, 01:21:13 AM »

It looks like spaces went from 3 -> 4? 

88

Implementation Details / Re: LLVM/C gen

« on: November 15, 2018, 03:35:09 PM »

I started to work on IR generation, but found it extremely painful to even implement something as simple as a while-loop DESPITE WORKING DIRECTLY FROM THE IMPLEMENTATION IN THE CLANG SOURCE!

I think it's amazing that people manage to work with LLVM given how extremely poor the documentation is for actually finding what "function X" does. That the LLVM docs and examples are constantly outdated does not help very much.

The best advice I found was someone who wrote "I write some C code and look at what the LLVM IR output is". One webservice to do that is http://ellcc.org/demo/index.cgi

Some overview of the LLVM IR output should be done as well to make sure we use the diagnostics in LLVM.

89

Ideas / Re: Overloading of functions

« on: November 15, 2018, 03:30:23 AM »

Overloading functions requires some sort of name-mangling scheme. – Unless you do it using something like C's __Generic, and that's more of an alias.

90

Implementation Details / LLVM/C gen

« on: November 15, 2018, 03:27:49 AM »

The two backends makes it a bit hard to keep feature parity of both. LLVM is far behind, but what is the strategy?

Using C, a nice thing is that we can start bootstrapping early if we'd like to(!) We can build parts of the server in C2, then compile to C and then automatically copy that code into the main source!

On the other hand, keeping the same behaviour between LLVM and C isn't easy. I've looked at Clang's LLVM gen, and it produces a lot of optimized code by leveraging intrinsics for certain "known" functions. So for example, if Clang sees sqrt, it can swap the normal library version for a LLVM intrinsic. To complicate things further, those are target dependent So there are *massive* amounts of work to do – on the LLVM gen.

Obviously if we get more people behind the project then that might be an easier thing to do. Without a lot of people spending time on C2 it will have a hard time being anywhere near optimized.

So what would the plan be?