16
Implementation Details / Re: Milestone reached!
« on: March 09, 2015, 05:58:53 PM »
Congratulations!
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.
17
Ideas / Re: Array types
« on: February 18, 2015, 06:23:32 PM »
Oooh! Thanks for the link!
Interesting proposal.
Interesting proposal.
18
Ideas / Re: other data type extensions
« on: February 11, 2015, 06:22:53 PM »
Re: underflow/overflow
Yes, I agree. Those are problematic because they start forcing traps. That was my point that they are more than just a type modifier.
The only language I know of that is targeted at DSPs are dialects of C. However, you get a lot of new keywords and #pragmas :-)
Here http://danluu.com/integer-overflow/ is an interesting blog post on the real cost of overflow checking. Interesting results. They are much lower than I thought. I still do not think they belong in a C-like language, but that is because the logic behind overflow/underflow handling is not obvious in such a language. At that point you start to need exceptions or some other means to handle overflow/underflow.
Yes, I agree. Those are problematic because they start forcing traps. That was my point that they are more than just a type modifier.
The only language I know of that is targeted at DSPs are dialects of C. However, you get a lot of new keywords and #pragmas :-)
Here http://danluu.com/integer-overflow/ is an interesting blog post on the real cost of overflow checking. Interesting results. They are much lower than I thought. I still do not think they belong in a C-like language, but that is because the logic behind overflow/underflow handling is not obvious in such a language. At that point you start to need exceptions or some other means to handle overflow/underflow.
19
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
I thought about underflow/overflow traps too, but that is more than just a small extra type modifier.
Other thoughts?
Best,
Kyle
20
Ideas / Re: Array types
« on: January 23, 2015, 10:00:49 PM »
Thanks for the link. Walter Bright makes a good case for this.
Passing "fat pointers," as Walter mentions, is one way to solve this. Go uses them to pass values and vtables.
Not only are arrays and pointers conflated, but now you have "magic" happening in that arrays are treated as pass-by-reference whereas other values must have "*/&" to show that they are passed by reference. I actually find this aspect of the automatic conversion to be more problematic. If I pass something by value, I expect that there is nothing that will alter the values in the caller. If I pass something by reference, I accept that the callee could modify data in the caller.
Pass by value:
Pass by reference:
Pass by value:
Pass by reference:
Huh? This really violates the principle of least surprise.
If I pass a struct without explicitly getting its address, the struct is copied. Arrays should be too. Are there other things that are treated specially too?
I have programmed in C for so long that I never really thought too much about this. Java does the same thing with primitive types vs. objects.
Good find!
Best,
Kyle
Passing "fat pointers," as Walter mentions, is one way to solve this. Go uses them to pass values and vtables.
Not only are arrays and pointers conflated, but now you have "magic" happening in that arrays are treated as pass-by-reference whereas other values must have "*/&" to show that they are passed by reference. I actually find this aspect of the automatic conversion to be more problematic. If I pass something by value, I expect that there is nothing that will alter the values in the caller. If I pass something by reference, I accept that the callee could modify data in the caller.
Pass by value:
Code: [Select]
int foo(int p);
int x;
foo(x);
Pass by reference:
Code: [Select]
int foo(int *p);
int x;
foo(&x);
Pass by value:
Code: [Select]
int foo(struct bar p);
struct bar x;
foo(x);
Pass by reference:
Code: [Select]
int foo(int p[]);
int x[2];
foo(x);
Huh? This really violates the principle of least surprise.
If I pass a struct without explicitly getting its address, the struct is copied. Arrays should be too. Are there other things that are treated specially too?
I have programmed in C for so long that I never really thought too much about this. Java does the same thing with primitive types vs. objects.
Good find!
Best,
Kyle
21
Ideas / Re: control endian-ness of data and bit structs
« on: January 15, 2015, 01:31:31 AM »
Hi Bas,
Yes, with bit-fields the standard does not specify where they go. In fact, it specifies that it is platform (and implementation, I think) dependent.
That is what I want to avoid. Right now, in C, you have to play games with the specific compiler you have for the specific platform you target. The idea of the bitstruct (I'm sure someone can come up with a better name) is to allow the programmer to specify exactly how bits are laid out in memory.
The endian extra keywords are very handy, but only for specific integral types (I am not sure if there is a consistent definition for floating point). I was just getting confused with putting both of them together.
There are three things that make it difficult to easily express hardware interfaces in C:
I think it is harder to look at code that pulls out bit-fields in code and determine that it is right. You always have to think about the platform. If you could avoid that, then code would be simpler and easier for you to determine correctness. C2's bit ranges/bitoffsets get very close to this, but it is still code, not data.
Many CPUs have specific instructions to get bit ranges out of machine words. Some even have instructions to save data with different endian-ness.
It is not just hardware interfaces that could use this. There are machine languages (hello, x86-64) where the register bits are split across the instruction. For instance the REX byte contains a few (2? 3?) bits that are the most significant bits of the registers to allow accessing 16 registers instead of 8. But the lower bits are in the MOD/RM byte which is later in the instruction.
Many languages use tagged pointers/values such as Lua (LuaJIT uses doubles and does some odd things with the mantissa bits IIRC), Smalltalk etc. It would be easier to write VMs for those languages if you had data types that expressed exactly what you were doing. There there is JavaScript... Ugh. The main VMs do use some tagged pointers or values.
I will go see if there are any languages which allow specification down to the bit level. Probably BitC did.
Best,
Kyle
Yes, with bit-fields the standard does not specify where they go. In fact, it specifies that it is platform (and implementation, I think) dependent.
That is what I want to avoid. Right now, in C, you have to play games with the specific compiler you have for the specific platform you target. The idea of the bitstruct (I'm sure someone can come up with a better name) is to allow the programmer to specify exactly how bits are laid out in memory.
The endian extra keywords are very handy, but only for specific integral types (I am not sure if there is a consistent definition for floating point). I was just getting confused with putting both of them together.
There are three things that make it difficult to easily express hardware interfaces in C:
- No standard way in C to declare a packed struct.
- No standard way in C to declare endian-ness of data.
- No standard way in C to declare integral values smaller than one character.
I think it is harder to look at code that pulls out bit-fields in code and determine that it is right. You always have to think about the platform. If you could avoid that, then code would be simpler and easier for you to determine correctness. C2's bit ranges/bitoffsets get very close to this, but it is still code, not data.
Many CPUs have specific instructions to get bit ranges out of machine words. Some even have instructions to save data with different endian-ness.
It is not just hardware interfaces that could use this. There are machine languages (hello, x86-64) where the register bits are split across the instruction. For instance the REX byte contains a few (2? 3?) bits that are the most significant bits of the registers to allow accessing 16 registers instead of 8. But the lower bits are in the MOD/RM byte which is later in the instruction.
Many languages use tagged pointers/values such as Lua (LuaJIT uses doubles and does some odd things with the mantissa bits IIRC), Smalltalk etc. It would be easier to write VMs for those languages if you had data types that expressed exactly what you were doing. There there is JavaScript... Ugh. The main VMs do use some tagged pointers or values.
I will go see if there are any languages which allow specification down to the bit level. Probably BitC did.
Best,
Kyle
22
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.
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
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
23
Implementation Details / Re: BitOffsets
« on: December 10, 2014, 05:32:02 PM »
I like that!
In C, I use bit fields for the same purpose, but that requires making a struct.
I end up with a lot of:
struct {
uint32_t cntrl_field:6;
uint32_t data_field:4;
...
} my_mapped_control;
Then you have to cast or create a union etc. It is a pain. I think having supported bit fields inline like you did is very nice!
Best,
Kyle
In C, I use bit fields for the same purpose, but that requires making a struct.
I end up with a lot of:
struct {
uint32_t cntrl_field:6;
uint32_t data_field:4;
...
} my_mapped_control;
Then you have to cast or create a union etc. It is a pain. I think having supported bit fields inline like you did is very nice!
Best,
Kyle
24
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
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
25
General Discussion / Re: friendly C
« on: September 05, 2014, 03:43:19 AM »
I read John Regehr's blog from time to time. He write very clearly and covers interesting topics. His articles on undefined behavior were so horrifying (as were Chris Lattner's) that I wanted to start writing in assembly because I did not trust what any compiler did. I actually started looking at Java again too because it does specify some of the corner cases that have become problems in C.
C11 could be worse than usual because of the consume memory order sematics that are required (but nothing stronger!). I am still reading up on that.
I am interested in compilers in general and C in particular :-)
Here are a few more to understand some of the threading issues I've run into myself when the semantics of barriers and locks are not clear:
http://preshing.com/
Preshing is another one who writes very informative articles. The latest article is about C++11's consume memory ordering. You can read about that to see why C's adoption of the same thing is going to be problematic. Linus Torvolds wrote (i.e. flamed) about it somewhere... Hmm, can't find the post. Perhaps it was on Real World Technologies? No search there...
The articles over time from Regehr and Lattner show that C is slowly becoming a language that is difficult to understand. Even the concept of NULL can be abused by optimizers to the point where you cannot easily figure out what is happening with simple code. Read some of Lattner's examples. They are a bit scary. I see code like them all the time :-(
So, I would love to see a language that can supplant C in utility, but the semantics turn out to be really tricky! C went from a high level assembler to a language that you cannot fully trust without knowing a huge amount about your specific compiler. Not what I want.
I have three jobs and a small child (mortgages are expensive!), so I don't think I am going to write the next C replacement. All I can do right now is cheer from the audience :-/
Best,
Kyle
C11 could be worse than usual because of the consume memory order sematics that are required (but nothing stronger!). I am still reading up on that.
I am interested in compilers in general and C in particular :-)
Here are a few more to understand some of the threading issues I've run into myself when the semantics of barriers and locks are not clear:
http://preshing.com/
Preshing is another one who writes very informative articles. The latest article is about C++11's consume memory ordering. You can read about that to see why C's adoption of the same thing is going to be problematic. Linus Torvolds wrote (i.e. flamed) about it somewhere... Hmm, can't find the post. Perhaps it was on Real World Technologies? No search there...
The articles over time from Regehr and Lattner show that C is slowly becoming a language that is difficult to understand. Even the concept of NULL can be abused by optimizers to the point where you cannot easily figure out what is happening with simple code. Read some of Lattner's examples. They are a bit scary. I see code like them all the time :-(
So, I would love to see a language that can supplant C in utility, but the semantics turn out to be really tricky! C went from a high level assembler to a language that you cannot fully trust without knowing a huge amount about your specific compiler. Not what I want.
I have three jobs and a small child (mortgages are expensive!), so I don't think I am going to write the next C replacement. All I can do right now is cheer from the audience :-/
Best,
Kyle
26
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
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
27
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
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
28
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
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
29
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
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
30
Ideas / Re: Built-in recipe handler/make replacement
« on: July 01, 2014, 11:42:50 PM »
Typescript is a dialect of Javascript by Microsoft. Before you think "Ah, embrace and extend!", it is not that. Microsoft wrote the compiler (transpiler) in Javascript. It runs in Node. They did put a lot of tooling into VisualStudio. Apart from the VS extensions, the whole thing is open source. It is a nice approach of adding just a little bit to Javascript (Javascript is valid Typescript) while maintaining full backward compatibility. Since they don't own the browser market anymore, they'd better play nice with the browsers :-)
I am looking forward to hearing more about c2reto! Sounds very interesting!
Before I make any more comments, I want to make sure that it is clear: I think the work you are doing on C2 is amazing and great! It is easy to sit on the side lines and make comments, but you are actually writing code.
Best,
Kyle
I am looking forward to hearing more about c2reto! Sounds very interesting!
Before I make any more comments, I want to make sure that it is clear: I think the work you are doing on C2 is amazing and great! It is easy to sit on the side lines and make comments, but you are actually writing code.
Best,
Kyle