Tomasz Borowik <timo...@lavabit.com> writes: > The most beneficial task (for me) would be to just bring the front-end > I've already written up to mainline quality (though not necessarily > inclusion), and in the process update some of the documentation or > maybe even cleanup some gcc code.
I have nothing against new languages, but adding a new frontend doesn't help GCC very much, at least not directly. We are always interested in cleaning up code if you want to propose a project in that area. > A more middle-back-end task is that I see a need for a certain fairly simple > kind of self-modifying code. > Basically a lot of applications have lots of configuration of their behavior > that doesn't get changed through most of run-time, yet there are lots of > branches, variable references and pointer dereferences associated with it. > It should be possible to create something like a global variable that can be > read like one (from the programmers perspective) but it gets inlined > everywhere like a constant, and a function for changing it's value is > generated that changes that value at every point in the output binary. > Now unfortunately that would still leave a lot of branches in the code so > something a bit more complex would be nice, like leaving enough space for > either the then or else block, but putting only one in and padding with nops > or a jump. > This isn't really smc very much imo, something more like templating binary > code... or template based jit compilation, or let's call it something like > "constant path swapping";p > Either way the benefit is getting a lot of branches, de/references, etc. out > of the hot-path, at the cost of significantly slowing down the cold path > (assuming people use it for what it's meant for). > If a given backend does not support the feature it just outputs normal code. > There is probably a few more aspects/possibilities to this I'm just loosely > throwing it up for comment atm. > I probably haven't given enough thought to this since I don't have a good > idea of the issues associated. Definitely lto would break this but if you ask > me lto is a bit misguided as the previously mentioned idea coupled with the > way sc and its editor is designed makes it obsolete (unless I'm > misunderstanding something). That is a little vague but it seems that something promising might come out of it. Ian
