Messages

166

Ideas / Re: one big design item: Macros

« on: May 03, 2015, 11:03:20 AM »

The issue about macros for use in function and for use outside functions remains tricky to understand.
Maybe this post can clear this up.

In C, parsing a macro is easy, just treat it as text and only look for some symbols like arguments etc. Replace
those and you're done.

In C2, parsing macros is a completely different story. The main difference is that the parser is used to
parse them, not the preprocessor. This offers advantages like better checking etc. I think most people agree
on the semantic part.

But a Parser, cannot simply treat the macro body as text, but needs to really understand the syntax, just like
any other part of the program. As a (pseudo) example, when the parser starts with a function definition, it is in a
state that it expects globals, eg in its own function parseFile().
The call stack might look like this:

Code: [Select]

parseGlobal();
  parseFileDecl();
    parseType();   // the return type
    parseFunctionName();
    parseFunctionArguments();
    parseFunctionBody() {
       while (..) {
         parseStatement();
        }
    }

So to parse a C2 macro, the Parser needs to know what to expect: Can it expect a sequence of Statements (like if, while
, calls, etc). Or should it expect top-level Declarations (like stuff at file scope). It could try to detect, but this would make
the Parser difficult and error-prone again. So a solution would be that the programmer tell the Paser what to expect, so it doesn't have to guess. In Rust this is less of an issue, since most things are Expressions.

I don't think adding this requirement would make the language less simple to use. In C, most macro's can only be used either at function scope or at file scope. But since the preprocessor doesn't care, it's up to the Parser to come up with good error messages.

167

Ideas / Re: one big design item: Macros

« on: May 01, 2015, 08:33:03 AM »

For generics, let me go back to one of the design principles:
C2 tries to be an evolution of C, not a completely new language. Therefore it should
not stray too far from C. Generics is one of those cases I think that might be a really
good option, but simply doesn't fit the C domain. I don't think it could be added as
a simple extra, because it influences a lot of design decisions..

On the macro-part, I think you have some really nice ideas:

• any - I have to think about it more, but it would be nice to always 'type' the argument
• only code expansion - yes, constants/feature selection should not use these macros
• no nesting - check
• macros called like function - yes, one idea to to show some difference at caller by using mymacro!(..) like Rust
• public macros - whether public macros can access non-public decls is something to think about. A macro is part of the interface, but different compilation units could cause problems indeed, well spotted!
• same indentation level - yes this would be required for parsing it well

One other issue to solve is described previously in this thread is whether a macro is meant to be
used at file-scope or at function-scope, because parsing it would be different. For example,
at file-scope, if-statements are invalid.

168

General Discussion / Another programming language initiative

« on: April 19, 2015, 09:11:48 PM »

I recently came across a lot of videos by Jonathan Blow, a game designer/developer who's
apparantly designing a language specifically for game programming. It seems to be called Jai.

if you have time (20+ hours on video... )
https://www.youtube.com/user/jblow888/videos

169

Ideas / Re: one big design item: Macros

« on: April 19, 2015, 09:08:57 PM »

In C2, at a Module level there are 3 types of Decl's: Types, (global) vars and functions. Macros would be
a fourth type of Decl. Just like the other 3 they can be public / not.

The part about local/non-local is pretty important, so maybe I can explain better. Ansi-C macro's are just
plain text expansion, so whether you type

Code: [Select]

if (x > 10) { .. }or

Code: [Select]

typedef struct { .. } my_##x;It's all the same for the preprocessor.
The first example is only valid inside a function body, the second only outside the function body.
So when parsing macros in C2, the parser needs to know what to parse: global syntax or function body syntax.
Global syntax is a bag of Declarations (types, function, etc). Inside functions it's basically a list of Stmts.
The local keyword tells this to the parser. If local the parser will do ParseStmt() iteratively, while otherwise
it will do ParseDecl() iteratively. This also means we cannot use the same macro inside+outside a function. Not
a real problem I think.

In you max(..) example, it's easy to see that generally inlined functions are Always superior to macros, since
you get the type checking etc. In C2 max() could almost always be done with an inline function, since the compile
units are the whole program.

Maybe we can get a more concrete design by just creating a set of use-cases for macros and validating the design
on them. A few I can think of are: (only code-expansion macros, since the features/constants are covered)

• debug:

Code: [Select]

debug("I'm in this function over here");
assert(ptr != 0);


• enum list (keeping enum in sync with other list)

Code: [Select]

addValue(STATE1, 10, "begin", func_begin);


170

Ideas / one big design item: Macros

« on: April 11, 2015, 10:27:17 PM »

One of the big remaining design issues (next to countless smaller ones  ) is the design
of a new macro system that is not based on textual substitution by the preprocessor.

Let's start by looking at the goal of macros:

• Feature selection

Code: [Select]

#ifdef HAVE_FOO_FEATURE
..
#endif


• Constants

Code: [Select]

#define MAX_ITEMS 10

• code expansion

Code: [Select]

#define print_if_positive(x) \
   if (x > 0) printf("value is %d\n", x);

I think each of these is a valid goal. So the new macro system should provide
a solution for each (in some way or another). For the Feature selection, C2 can
use the same way as C; since the C2 compiler also has a preprocessor, it's completely
identical.

The Constants goals is attained in C2 by using const of Numeric types:

Code: [Select]

const int32 MAX_ITEMS = 10;This will just 'replace' all references with 10.

The Code-expansion is the hardest. Since there is no textual replacement, the macro system
has to be language aware. This means that when parsing the macro definition, the parser must
understand what's happening. This results in 2 types of macros: local and non-local. Local macros
can be used inside functions, while non-local macros can only be used outside function
bodies. So local macros are parsed as a series of Statements, while non-local macros are parsed
as a list of global declarations.

The syntax I currently think of is:

Code: [Select]

local macro(x) {
   io.printf("value of "$$x" = %d", x);
}
macro(x) {
func gen_$x() {
}

Open issues:

• Q: are public macros in module X allowed to access non-public Decls in X?
• Q: what to allow as macro arguments?
• Q: what syntax to use for argument replacement, concatenation and stringify?

171

Ideas / Re: other data type extensions

« on: April 09, 2015, 10:53:48 AM »

Interesting discussion indeed. Might be difficult to implement in Rust since they are
in 1.0 beta...

Thx for the link.

172

Ideas / Re: Array types

« on: March 20, 2015, 09:29:08 AM »

It would indeed be nice to let caller choose calling by value (thus copy) or by reference.
External C libraries would make this decision hard indeed. It seems simple but has
many consequences as you already stated...

173

Ideas / Re: Array types

« on: March 11, 2015, 08:16:42 AM »

I'm currently playing with the idea of forbidding passing array types like (int[] a) as function argument. A developer would have to use (int* a). In the function body he/she could do a[4].

Anyone have a any other ideas on this?

174

Implementation Details / Milestone reached!

« on: March 06, 2015, 10:26:41 PM »

C2 just reached another milestone: completely building a (static) library and genarting the c header file!   
The library itself is created by generating c-files and a makefile and then running the makefile. This is of course not the final path, but will definately help in fleshing out more details. Also I extended the unit-test framework to test generated C files easily.

One detail that came up was the name 'mangling'. The generated names of module.decl used to be __module_decl. But the linker couldn't find these in the static library. So the mangling now just consists of module_decl, also a bit easier on the eyes.

The next step will be playing with the options to control object visibility.

175

Ideas / Re: other data type extensions

« on: January 31, 2015, 05:35:27 PM »

My goal with C2 is to stay compatible with the C language. Adding underflow/overflow traps
would definately break that I think. Just as garbage collection, classes etc..
I wonder if there are any programming languages targetting DSP's..

176

Ideas / Array types

« on: January 20, 2015, 09:29:42 AM »

I recently read
http://www.drdobbs.com/architecture-and-design/cs-biggest-mistake/228701625
where the author states that the (one of) the biggest mistakes made in C was
converting an array to a pointer when calling a function, so (C-code)

Code: [Select]

int array[4];
int* ip = &array[0];
myfunction(array);
myfunction(ip);
the two calls are equal. One idea would be to make this distinction. One limit would be
that the array would be a known size (in function prototype), eg (C2 code)

Code: [Select]

func void setMacnr(char[4] macnr) { .. }
A function that would take a variable sized array (like string functions) would still require a pointer and a size
argument.

177

Ideas / Re: control endian-ness of data and bit structs

« on: January 14, 2015, 08:23:40 AM »

There is a subtle issue here,
In C/C2 you can use bitfields to pack multiple small fields into a word or so. this rougly looks like this in C:

Code: [Select]

struct Foo {
  int a : 3;
  int b : 10;
  unsigned int c : 6;
}
The position where the compiles decides to store the values is left to the compiler, it is unspecified.
So you can (should  ) never use this to overlay a hardware register to extract a field.

The other thing is C2's bitoffsets, which is designed to address bit-fields in for example a hardware register.
C2 still has bitfields as well, since they have a valid use.

The second thing is that endianness has nothing to do with bitoffsets, bit 5-7 is just bit 5-7, nothing more,
nothing less. Shifting a word 5 positions to the right for example is done in hardware, for software you can just do

Code: [Select]

value2 = (value >> 5);

In my opinion, bitfields and bitoffsets covers the bit stuff. Bit features that span multiple words has no
valid use case.

I do like the idea of adding endianness features to the languages, since many C projects create their own
htonl()  htons()   ntohl() (host-to-network-long, etc) macros. Maybe we could use some intrinsics here that
allow for better code-generation on some platforms...

178

Implementation Details / BitOffsets

« on: December 04, 2014, 08:11:44 PM »

Hi,

I've just pushed a new feature called BitOffsets. This allows easy copying of certain bit-ranges, like often
done in drivers. So if your chip's reference guide says:   Counter Bit 14-10, you used to do (in Plain-Old-C)

Code: [Select]

int counter = ((value >> 10) & 0x1F);
Which is not too readable. Off course you could use a fancy macro like REG_BITS(value, 10, 0x1F),
but that's not really nice either.

Because C2 targets kernels, bootloaders and other low-level programs, accessing register values should
be easy. Enters BitOffsets:

Code: [Select]

int counter = value[14:10];
Which does the same as the example above. Additionally it can check possible overflows (like assigned a 8+ width
value to a char etc)

Currently BitOffsets can only be used in RHS (Right-hand side) expressions. I'm still debating whether
to also allow this on LHS expressions.

179

General Discussion / Re: friendly C

« on: September 03, 2014, 09:08:33 AM »

Hi Kyle,

yet another nice article!
What are you looking for yourself when you find these articles?
Do you have a particular interest?

Cheers,
Bas

180

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

« on: July 23, 2014, 08:07:10 AM »

it would not be very difficult to implement and this is even used in some Vi plugins that
I use. But since the actual parse/analysis time is so short (I think it should be less then
a second for large projects like the Linux kernel), there's no real gain other then integration
with an editor (like clang does).