@DRMacIver alerted me about this thread, and I thought I should post an update on the status of the project.
It’s kind of funny to see it being referred to as “Clay2011”, as 2011 was the year I actually stopped working on the project! (It was started a few years earlier).
Luckily, I’ve been able to allocate quality time to language development again in the last year. A new version of Clay is under very active development with a much better and simpler design. The compiler has been bootstrapped as of about a couple of months back. We’ve also started using Clay for our internal projects at Clay Labs.
Some notable improvements over the previous Clay are: Optional compiler enforced memory safety, and much faster compile times.
The compiler can parse all of itself, do whole program type-inference/checking, type specialization, and IR generation in a total of less than 2 seconds.
The backend code generation is still slow though. Producing an unoptimized binary of the compiler takes an additional 6 seconds. Producing an optimized binary takes quite a bit longer.
I would like to release this new version of Clay at some point in time when the advantages offered are meaningful enough for people to use it for real jobs. I’m not sure when that will be.
I post some obscure, interesting work then one of the inventors shows up. What a treat!
“It’s kind of funny to see it being referred to as “Clay2011”, as 2011 was the year I actually stopped working on the project! ”
The year came from other Clay site saying it wasn’t the 2011 one. Ok, now it’s ClayFromSomeTimeBefore2011. Or maybe I’ll call it Sreeram’s Clay. That’s fitting. :)
“Luckily, I’ve been able to allocate quality time”
See DRMacIver: I knew they had the resources to be developing it and prototyping internal apps. Glad to see it’s happening. Modern, system languages just don’t get enough attention these days versus Yet Another Scripting/Managed Language.
“The compiler can parse all of itself… 2 seconds.” Great work.
“The backend code generation is still slow though”
Is your backend custom or are you leveraging an already-optimized compiler for this? Sounds like the easy route would be the latter. Especially on a Wirth-style compiler given they’re so fast. Another route is to let the compiler be a bit slow but include a REPL/interpreter for development iterations. There are even C interpreters for that. Once it’s solid, they run the optimizing compiler. It also usually has a feature catching the intermediate stuff and only compiling what’s necessary during a recompile.
Is your backend custom or are you leveraging an already-optimized compiler for this? Sounds like the easy route would be the latter. Especially on a Wirth-style compiler given they’re so fast.
Yep. I’m using Clang as the backend. The older Clay used LLVM but I switched to Clang so I don’t have to worry about the C ABI when interoperating with existing libs.
Another route is to let the compiler be a bit slow but include a REPL/interpreter for development iterations. There are even C interpreters for that. Once it’s solid, they run the optimizing compiler. It also usually has a feature catching the intermediate stuff and only compiling what’s necessary during a recompile.
I’m hoping to make the compilation itself faster. Since the front-end takes so little time, I can perhaps do some of the optimizations before delegating to the backend.
Sounds good. Btw, look up QBE compiler backend. It’s designed to be simpler IR than LLVM, totals around 10Kloc, and is selective about optimizations it includes to get 70% there in performance without much complexity. Might be nice interim solution.
Hi folks
I’m the author of Clay.
@DRMacIver alerted me about this thread, and I thought I should post an update on the status of the project.
It’s kind of funny to see it being referred to as “Clay2011”, as 2011 was the year I actually stopped working on the project! (It was started a few years earlier).
Luckily, I’ve been able to allocate quality time to language development again in the last year. A new version of Clay is under very active development with a much better and simpler design. The compiler has been bootstrapped as of about a couple of months back. We’ve also started using Clay for our internal projects at Clay Labs.
Some notable improvements over the previous Clay are: Optional compiler enforced memory safety, and much faster compile times.
The compiler can parse all of itself, do whole program type-inference/checking, type specialization, and IR generation in a total of less than 2 seconds.
The backend code generation is still slow though. Producing an unoptimized binary of the compiler takes an additional 6 seconds. Producing an optimized binary takes quite a bit longer.
I would like to release this new version of Clay at some point in time when the advantages offered are meaningful enough for people to use it for real jobs. I’m not sure when that will be.
“I’m the author of Clay.”
I post some obscure, interesting work then one of the inventors shows up. What a treat!
“It’s kind of funny to see it being referred to as “Clay2011”, as 2011 was the year I actually stopped working on the project! ”
The year came from other Clay site saying it wasn’t the 2011 one. Ok, now it’s ClayFromSomeTimeBefore2011. Or maybe I’ll call it Sreeram’s Clay. That’s fitting. :)
“Luckily, I’ve been able to allocate quality time”
See DRMacIver: I knew they had the resources to be developing it and prototyping internal apps. Glad to see it’s happening. Modern, system languages just don’t get enough attention these days versus Yet Another Scripting/Managed Language.
“Optional compiler enforced memory safety” Ok, good.
“The compiler can parse all of itself… 2 seconds.” Great work.
“The backend code generation is still slow though”
Is your backend custom or are you leveraging an already-optimized compiler for this? Sounds like the easy route would be the latter. Especially on a Wirth-style compiler given they’re so fast. Another route is to let the compiler be a bit slow but include a REPL/interpreter for development iterations. There are even C interpreters for that. Once it’s solid, they run the optimizing compiler. It also usually has a feature catching the intermediate stuff and only compiling what’s necessary during a recompile.
Yep. I’m using Clang as the backend. The older Clay used LLVM but I switched to Clang so I don’t have to worry about the C ABI when interoperating with existing libs.
I’m hoping to make the compilation itself faster. Since the front-end takes so little time, I can perhaps do some of the optimizations before delegating to the backend.
Sounds good. Btw, look up QBE compiler backend. It’s designed to be simpler IR than LLVM, totals around 10Kloc, and is selective about optimizations it includes to get 70% there in performance without much complexity. Might be nice interim solution.
http://c9x.me/compile/
QBE looks great. Thanks for the link.