Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - bas

Pages: 1 ... 5 6 [7] 8 9 ... 15
91
Ideas / Re: Basic list of improvement points
« on: October 26, 2018, 09:51:39 AM »
The list so far: (unordered)


92
Ideas / Basic list of improvement points
« on: October 26, 2018, 09:44:15 AM »
There have been some really good ideas and improvement points on this forum. The problem is that there are so many.
I would hate to miss or lose some ideas simply because there is no way to implement them all at once. So I'm looking at
some way to organize this.

More matured languages (Python for example) seem to have formalized this process by using PIPs (Python Improvement Proposals).
That is very nice for gradual improvements, but not handy when the base is not complete yet. Maybe we can have a list of items here,
that point to various other posts on the forum, along with their status. I'll update the list (and maybe prioritize a bit).

93
Ideas / Re: Restricted pointers (and the analogue with threads)
« on: October 26, 2018, 09:34:58 AM »
Godbolt.org is very nice!

For developing an LLVM-based compiler, there are (roughly) 2 steps involved:
- the frontend (like Clang or C2c) generate LLVM IR (pseudo assembly)
- LLVM generates architecture specific instructions

Godbolt shows only the final end result. So generating 'better' IR might not necessarily result
in better Asm. Also using a new version of LLVM might generate better Asm based on the same
IR. So we need to look at both the IR that C2C generates And the Asm result (for a few common
architectures (eg. x86_64, Arm)

94
Ideas / Re: Preprocessor and Macros
« on: October 26, 2018, 09:27:27 AM »
You're completely right, I missed the generics one. Thanks.
I hadn't noticed Go2 yet, nice! The Go developers also seem to be in an improvement loop, self-inspecting and such. Good for them!

I think generics can be very powerful for container data structures. So a list of X uses the same code whether X is an u32 or a pointer.
So roughly the original STL template library (vector, array, list, etc).
In C++ I think they went too far, making code horribly complex to read and even worse than horrible to understand.

Generics are hard syntax-wise (you might want to avoid the C++ notation), but also put quite a strain on the rest of the language.
Maybe the Go2 team comes up with something genius..

95
Ideas / Re: A group of function pointers & a struct
« on: October 26, 2018, 09:14:48 AM »
I think I understand what you mean. Basically this is Interfaces.
C and C2 currently don't have those. The construct that comes closest is indeed a struct with function pointers.
The issue there is that it is easy to miss operators. So if a new interface function gets added, the derived implementations
will not complain. I've been thinking about this for a while, but so far have not found a nice solution.

96
Ideas / Re: char / int / i8 / i32 and so on
« on: October 26, 2018, 09:12:04 AM »
In C2 there are already longer names for the C libs. So c_short, c_long, etc. These can be used if you want longer names..
Additionally I'm convinced that there should also be a pointer-size dependent variable. For this I'll add isize and usize.
Also many new languages (Rust, Zig) seem to be on this exact track as well.

97
Ideas / Re: Fix C operator precedence rules
« on: October 26, 2018, 09:09:48 AM »
I didn't catch this as one of C's improvement points yet (too used to some things ;) ). But looking at the examples it indeed seems a better way.
What i'm missing in the table is the [ ] (index operator), but in other languages it seems to be at number 1.

I'm putting this on the list of improvement points, so what has to be done is:
- modify parser
- add tests
- modify documentation to show differences between C and C2
- enjoy()

98
General Discussion / Re: Mail of posts / this BBS
« on: October 25, 2018, 09:47:36 PM »
I get mails whenever a new topic is started. Not when there is a new post in an existing one..

99
General Discussion / Re: How should I set up the project for dev?
« on: October 25, 2018, 09:46:52 PM »
The link between C2C and LLVM/Clang is pretty thin. Most of the work involves the AST and that is C2 specific

100
General Discussion / Re: State of progress?
« on: October 25, 2018, 09:46:19 PM »
Of course we could write that ourselves and maybe we will in the end. But as a start, this was a faster path.
Especially the DiagnosticsEngine does quite a lot..

101
General Discussion / Re: Contribute / get into the code
« on: October 25, 2018, 09:45:20 PM »
Always good to hear. Let me think about a good start topic..

102
Ideas / Re: Preprocessor and Macros
« on: October 24, 2018, 02:59:33 PM »
If you look at the Linux kernel code it seems that every 2 lines of code that look similar are macro-ed.
In the end this becomes a big mess.

From a language point of view, C macros are used for 3 different purposes:
1. defining constants.
Code: [Select]
#define BUFFER_SIZE 10in C2 this is replaced by just using
Code: [Select]
const u32 buffer_size = 10;
2. feature enabling/disabling
Code: [Select]
#ifdef HAVE_OPENGLC2 does not have an alternative to this (but you can define all the features in the recipe.txt)

3. code re-use
Code: [Select]
#define max(x, y) ((x > y) ? x : y)Also sometimes larger macros that include if-statements etc
This code would be replaced by semantic macros in C2 that do AST replacement.

The use of nr 3 is quite common, but I think that has also because it's become a
habit for C developers. Other languages don't seem to need this at all and are doing
fine.


103
Ideas / Re: Restricted pointers (and the analogue with threads)
« on: October 24, 2018, 02:51:37 PM »
I have been programming in C for around 20 years, but I've never used the 'restricted' thing. The only time I actually ran into it
was when looking at libC's memcpy(). I can understand that it can be useful there.  Ideally we could just test the generated LLVM
IR code and then see how much (performance) difference it really makes.

There are some presentations by Andrew Kelly, the Zig language creator that describe how he checked the IR code that resulted
from different concepts. That's really cool to do.
 

104
Implementation Details / Re: Why do we need Clang and LLVM?
« on: October 24, 2018, 02:38:38 PM »
(see other post about LLVM/Clang).

In the beginning I was hoping on being able to reuse Clang's AST. That was not the case. Still
just using the Tokenizer and Diagnostics engine already saved a lot of time. Additionally most of
C2's parsing is heavily based on/inspired by Clang's parser.

105
General Discussion / Re: How should I set up the project for dev?
« on: October 24, 2018, 02:36:48 PM »
I'm mostly developing in Linux, so I'm using Vim as main editor. That (and Emacs) in the only editor I know that really handles big codebases well.
I'm sure many Clang/LLVM developers are using Xcode on a Mac, so that should be fine as well.

For C2 development, you don't really need to go into LLVM/Clang code that well. Just following the INSTALL.md in the project root does the trick.
Only when changing the Tokenizer or adding/changing diagnostic messages are changes to Clang needed. No changes were needed in LLVM at all.
I've discussed merging the C2 changes upstream, some Clang developers were (quite surprisingly) open to it. Clang and LLVM have a great
development ecosystem with a good vibe.

Pages: 1 ... 5 6 [7] 8 9 ... 15