<div dir="ltr">Thanks all, for all the pointers. I'd read some of them, but others are new.<div>Jim, I'd certainly appreciate the chance to get together at the dev conference.</div><div>I think y'all's ideas of a stub back end sound good, though I can appreciate the maintenance difficulties.</div>
<div>Karen's idea for a new design guide is also good, though I think the idea of looking at other back ends for examples of good design is perhaps wrong.</div><div><br></div><div> A lot of my difficulty in reading other examples is that it's not clear what matters and what doesn't. It's what I hope to get by sitting next to someone and asking questions. Some of this could be addressed in a guide. I'd start with a chapter on planning. When writing a new back end, we wonder:</div>
<div><div><ul><li>what sort of architecture are we dealing with? 3-address, 2-address, 1-address, 0-address (stack machine)?</li><li>what do we want to build? Do we need an assembler?, a disassembler?, a JIT?, an instruction scheduler?, a register allocator?</li>
<li>Can we talk about all these things in an orthogonal fashion? With examples, or perhaps pointer to specific targets that illustrate different things?</li><li><div></div></li></ul>I don't really find it in the documentation so far, but I think the instruction selection stuff is based on a BURG-like pattern matcher. It seems like this is the key intellectual challenge for the not-completely RISC machines. Lots of discussion seems warranted, but I find none at all. Somewhere inside the x86 target must be a lot of stuff on how to handle a 2-address machine. I've done an x86 CG once before, and all of the fun was in getting the right set of patterns to handle the fancy addressing modes, the condition codes, and the 2-address instructions. I'm working on a 1-address machine now (an accumulator machine, with a set of register and an accumulator, and instructions of the form ACC += Register) and the pattern matcher to do everything optimally is delightful.</div>
<div><br></div><div>I have an assembler, don't care about scheduling (except to reduce register pressure, so a variant of SU-numbering will do), don't need a JIT, don't have any subtargets, so many things can be ignored. I expect others will have similar problems, in that they only need a subset of the capabilities.</div>
<br></div><div>Thanks,</div><div>Preston</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Sep 25, 2013 at 11:20 AM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 25 September 2013 12:28, Sean Silva <<a href="mailto:chisophugis@gmail.com">chisophugis@gmail.com</a>> wrote:<br>

><br>
><br>
><br>
> On Wed, Sep 25, 2013 at 7:02 AM, Renato Golin <<a href="mailto:renato.golin@linaro.org">renato.golin@linaro.org</a>><br>
> wrote:<br>
>><br>
</div><div class="im">> (Devil's advocate, but half serious):<br>
><br>
> It may be a good idea to require that the dummy backend is kept up to date,<br>
> as a way to keep a pulse on changes to the interfaces between the<br>
> target-independent and target-dependent parts of LLVM. A slightly idealized<br>
> way to put it is that the dummy backend would be a "living definition" of<br>
> the boundary between the target-dependent and target-independent parts of<br>
> LLVM. By virtue of being just a stub, complexity related to being a "real<br>
> backend" could be removed, so that when you look at a file inside the stub<br>
> backend, you know that there isn't extraneous junk that some other target<br>
> wouldn't have: everything there is essentially an example of something that<br>
> every target has in common.<br>
><br>
<br>
</div>These things have a tendency to bitrot. When I started looking at gcc<br>
it had an example frontend (treelang). The problem was that it was<br>
updated just enough to keep it building. It didn't follow the best<br>
practices that the other frontends had been moved too. In the end it<br>
was easier to read the fortran FE code than treelang's.<br>
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div>