My new project on AMD CAL

[codedivine]

Writing CAL IL is not for the faint hearted. To make the process a little easier, I am writing a tiny compiler from a C like frontend to produce CAL IL. Its a very thin layer over the IL and comiles to CAL IL code. Example:

int i;
float sum = 0.0f;
for(i=0;i<16;i++) sum = 1.0 + sum;
o0 = sum;

This will produce the equivalent IL code. Note that its NOT C and is much lower level than lets say CUDA. Its only as a replacement for CAL IL and you will still be writing all the other API calls manually. The only thing it adds over IL is :

a) generating boilerplate declarations
b) does register allocation
c) dont need to write assembler and can use normal C operators like +,- etc. control flow provided is : for, while and if/else. no function calls. no case/switch for now.
d) you still have to read/write from arrays like i0,o0 and g.
e) all named variables are compiled to registers. similarly
f) if it runs out of registers, an error is generated since it cannot allocate memory.
g) unlike the assembler, its typed though i am providing support for typecasts.
h) not all IL instructions are exposed but they will be soon. for example trigonometric functions are not exposed.
i) compute shader support is planned. currently only "ps" or pixel shaders are supported (if thats what they are called).

i am currently testing it privately and will release a preliminary alpha of it by friday as BSD licensed library on google code. its written in C++, provides a funtion which takes as input a string of this C-like language and returns a string containing compiled IL.

i am using linux64. i dont have time to do development or testing on windows.

(I am looking for testers certainly and any help is appreciated. h/w donations are also nice :P)

[Tim Murray]

Interesting. What compiler framework are you using?

[codedivine]

Actually I did not use a pre-existing compiler framework. I initially thought it will be small enough that I dont need to use a framework .. that turned out to be somewhat of a mistake but well its done now :)

The parser is written in ANTLR. Rest of the code (type checking to code generation) was all implemented by me.

The language is an any case small : no structs, no functions, no user declared arrays, no pointers. Its just one level above assembler. Its not C and its certainly not comparable with CUDA. Its only for making (my) job of writing CAL IL easier.

[willardjuice]

When I reinstall Ubuntu I might be able to help with some basic things. The key word there being "basic" since I have only used brook+ on my R770. I'm assuming you're probably looking for a more "advanced cal developer" than myself, but I'm always up for trying new things if you don't mind (although trying to develop with cal might change that philosophy :lol:). Besides I've got nothing to do till OpenCL. :sad:

[codedivine]

Great. I will post here as soon as I release the library (which should be in 1-2 days).

[rpg.314]

Have you looked at this (http://www.gpuware.com/main.html)? They have a pseudo compiler which apparently is higher level than yours. :smile:

Though I say, if you are writing a compiler, or even a micro compiler, target opencl language using llvm. Just make a small piece which works and release it as an opensource project. It's much better as your efforts would be useful to larger no. of people. That's what I'd do. :wink:

And yes, have a look at the llvm tutorials, You should be able to have a small thing up and running (in a matter of days I guess) even if you are an ultra noob in compilers like me.:cry: I haven't done it, but the stufff shown there makes me feel that it would be pretty easy to do.

Any ways, good luck and do keep us posted.

[codedivine]

rpg.314 : Thanks for the link to the gpuware stuff. Unfortunately it does not appear to be opensource and is not even free-as-beer for noncommercial applications so its not useful for me. Secondly, I wanted an embeddable library for my purposes while theirs appears to be a command line driven system (though I guess you can just do a system call to run a subprocess).

LLVM I already know about .. its just that I did not think that I would require it in this case so I did not use it. Well .. now I think maybe I should have :(

The reason for not doing a higher level interface was that this library is actually being used in another project as a backend. I am just releasing this component for now. The objective was to have a simple-to-use backend that still maps almost 1-to-1 to CAL IL. This compiler doesnt even do any optimizations since the higher level controller (not yet released) actually is passing optimized code to it. Its used as a dumb backend.

[codedivine]

And to reemphasize .. its only a replacement for CAL IL not for the API itself. The CAL API calls still need to be written manually .. just think of it as an easier IL. That was its purpose. The purpose was not to replace the API since I needed full control of the API for my application.

Its low level because I wanted it to be that way :)

Its only for people who want to use CAL but dont want to write CAL IL. OpenCL is not only an alternate language but also a whole alternate API. To write an opencl compiler, you also need to write a whole supporting runtime. Which is not the intention here. Writing an OpenCL compiler for AMD GPUs should be an interesting exercise though :)

Hope things are more clear?

[rpg.314]

Can you tell us something about your higher level controller? Sounds interesting. Generation of optimized C code. :)

[codedivine]

Well wait and see :)
I will release the higher level layer in a few weeks .. its my masters thesis.

[codedivine]

Setup initial repo at calseum.googlecode.com but its not complete yet. Its a half-working preview basically.
license is apache v2.

[mhouston]

Another option is to look at the Brook+ compiler that translates to IL. A lot of work has been done there to handle C like code, so it may save you some time to pick up that stack and take a look.

[codedivine]

I am looking there. One primary requirement is for it to be embeddable as a library (which is slightly hard given that Brook+ frontend is under GPL).

OTOH, does anyone how Brook+ does register allocation? I have been thinking and experimenting with register allocation algorithms a bit.

[mhouston]

The compiler does naive allocation and relies on the IL->ASM compiler.

Yes, the Brook+ frontend is GPL because it uses ctool.

[randomhack]

edit : removed

[codedivine]

Fixed some major bugs and now its somewhat usable.
You can play around with it .. checkout from SVN from http://calseum.googlecode.com
Now its using compute shaders as backends (unlike Brook+) though the LDS is not yet exposed.

This will be my last major update here about the project for some time to come since I dont want to spam the forum.