braid
braid copied to clipboard
a multi-stage heterogeneous programming language applied to real-time 3D graphics
Now that we have tuple indexing expressions (e.g., `t.1` to get the second element), we can get rid of the very nasty hack that is the `swizzle` intrinsic. For example,...
We should factor out the `glrt` library, unify it with the remaining runtime code currently embedded in the WebGL backend, pair it with the dingus preamble file and the “header.ss”...
We should consider making the backends use human-readable names in generated code, based on variable names in the source code, for the variables they emit instead of opaque numbers. An...
Currently, we compile references to extern functions as closures with empty environments. This makes it hard to see what the generated code is doing. We should instead special-case calls that...
OpenGL ======= Regarding OpenGL, I created and finished most of opengl.ts. It hasn't really been tested yet since I don't think it is possible to "run" it yet. I think...
Currently, we are using `getTargetMachineData( )` to get the data layout. This function is deprecated, so we eventually need to switch over to using `createTargetDataLayout( )`
It looks like LLVM doesn't like using void* for opaque pointers. Trying to compile some LLVM IR actually gave me a useful hint: ``` $ /usr/local/Cellar/llvm/4.0.0_1/bin/opt add.ll /usr/local/Cellar/llvm/4.0.0_1/bin/opt: add.ll:6:22: error:...
Currently, the `main` function in generated LLVM programs takes no "normal" arguments and an environment structure pointer. However, the main function for executable programs should instead take the traditional C...
Here's the list of GLSL intrinsics we currently support: https://github.com/sampsyo/braid/blob/19f57db2ddcd93f1d07af3f49b9cc2b375a1c1f4/src/backends/gl.ts#L128-L193 It would be awesome to have a list of what we're missing from the GLSL standard supported by WebGL 1.0.
Currently, the `Emitter` interface assumes that you're producing strings. This works for generating JavaScript and GLSL, but it won't work for LLVM, where we'll need the functions to produce `llvm.Value`...