If thé IL is text, and your goal is short understandable code, why not use a language like Python?
(Compiling it with Cython would allow you to provide a C api and library with only lib python as a dep)
Show HN: QBE – a new compiler back end
61–70 of 72 posts
Re: Show HN: QBE – a new compiler back end
#62Earlier quoted context omitted.
just to be clear, I'm not the author of qbe, but I have followed it since it started. The author uses the handle mpu.
I was briefly confused but gathered that. The only other confusing thing was that mpu works with major players in high-assurance per a comment but didn't respond to only comment (mine) about applying assurance tech. Wasn't bothered but didn't expect it either. Unusual.
I actually decided to take more time to answer your comment more throughly than others. Also, I TA'd twice the class from where you linked the article below, so I know about it :).
Re: Show HN: QBE – a new compiler back end
#63Earlier quoted context omitted.
In llvm you cannot just pass or return structs, every frontend needs to explicitly handle the details of when and how to registerize structs to handle the system V abi for example. That code is not so trivial to do yourself actually.
LLVM supports passing/returning structs (I'm using 3.8.1): https://ghostbin.com/paste/ozsh3 Furthermore, the output does match the System V ABI: https://ghostbin.com/paste/4a5ms Notice how the struct is placed on the stack and the pointer to it is placed in %rdi for call/return. If you reduce the number of i32's in the struct to 3, the struct's fields are passed via registers since the type fewer than four eightbytes…
Hi, thanks for the information, but LLVM still does not provide ABI compatibility. If you reduce the struct to 3 i32, it is passed in edi, esi, and edx on my machine. However according to the ABI it should be packed in rdi and rsi.
Checkout the QBE transcription and what it will compile to http://c9x.me/paste/mGOO (there is a bit of register shuffling because hinting in regalloc is not very mature yet, but note that SSA form for the input is not required!).
Re: Show HN: QBE – a new compiler back end
#64If thé IL is text, and your goal is short understandable code, why not use a language like Python? (Compiling it with Cython would allow you to provide a C api and library with only lib python as a dep)
that would be painfully slow, as it stands now, qbe is actually quite a lot faster than gcc and clang.
Re: Show HN: QBE – a new compiler back end
#65Earlier quoted context omitted.
LLVM supports passing/returning structs (I'm using 3.8.1): https://ghostbin.com/paste/ozsh3 Furthermore, the output does match the System V ABI: https://ghostbin.com/paste/4a5ms Notice how the struct is placed on the stack and the pointer to it is placed in %rdi for call/return. If you reduce the number of i32's in the struct to 3, the struct's fields are passed via registers since the type fewer than four eightbytes…
Hi, thanks for the information, but LLVM still does not provide ABI compatibility. If you reduce the struct to 3 i32, it is passed in edi, esi, and edx on my machine. However according to the ABI it should be packed in rdi and rsi. Checkout the QBE transcription and what it will compile to http://c9x.me/paste/mGOO (there is a bit of register shuffling because hinting in regalloc is not very mature yet, but note that…
Ahh, good catch! Luckily, I don't use SysV struct passing. :)
Re: Show HN: QBE – a new compiler back end
#66This is a wonderful idea! As a compiler person, I'm excited to see how well this works and wish you all the success in the world. > QBE aims to be a pure C embeddable backend that provides 70% of the performance of advanced compilers in 10% of the code. This philosophy is very similar to that of vis [1], a vim-like editor that aims to have 80% of vim's functionality in 1% of the code. I hope that more such project se…
Yeah, and 70% of features of React in 5% of the code!
Re: Show HN: QBE – a new compiler back end
#67Earlier quoted context omitted.
I was briefly confused but gathered that. The only other confusing thing was that mpu works with major players in high-assurance per a comment but didn't respond to only comment (mine) about applying assurance tech. Wasn't bothered but didn't expect it either. Unusual.
I actually decided to take more time to answer your comment more throughly than others. Also, I TA'd twice the class from where you linked the article below, so I know about it :).
Great! One of my main reasons posting here is getting next generation of high assurance developers info they need plus learning from them in what's not my specialty (esp formal verification). Just hate missed opportunities given I rarely run into people that even know what the phrase means or why it matters. ;)
Re: Show HN: QBE – a new compiler back end
#68> Its small size serves both its aspirations of correctness ... No, a compiler (hell, a software) written in C is not correct, period. If you want a C compiler that has slight chances to be correct, you use compcert. The small size is an awesome property for education (both for the writer and the reader). For this purpose, it's absolutely great, so kudos for that. :)
At least, I can try! And also, we are seeing more and more certified C programs: see the DeepSpec NSF expedition grant, the Verified Software Toolchain, and the CertiKOS project for examples. I work with these guys.
You are soooo lucky. DeepSpec has a near dream team of people working on this issue. Appel and Chlipala alone could probably knock out most of the problem given enough time. Add the others and great stuff on publication list is entirely unsurprising. Except in its cleverness. :) Glad you brought it up as I haven't read the info flow for c & asm paper yet.
Btw, hows progress coming on those projects? Specifically, are any of the tools (a) useful for non-experts with a little bit of training by tutorials, etc and (b) available for download in open-source or binary form yet? Thanks ahead of time.
Re: Show HN: QBE – a new compiler back end
#69Earlier quoted context omitted.
I think the extra load/stores clutter the IL. Also, QBE does not really "alternate" SSA/non-SSA, SSA form is built once at the beginning of the compilation pipeline and preserved later. I don't understand what you mean by "fully pruned programs". Maybe you want to refer to pruned SSA form. And then, here is my point: with LLVM, either you build SSA yourself or you use allocas. QBE offers a convenient third option.
Some CFG transforms are actually much easier if you get out of an SSA first, reshuffle CFG without caring about maintaining your phis, and then simply rebuild an SSA form.
Expected to see you here. Hey, send me an email or something so I can send you interesting stuff without hunting your profile or random comments on HN. Address in my profile. Here's the one I was saving for you to complement the ML and Haskell CPU's I linked.
https://www.info.ucl.ac.be/~pvr/bam_jlp.ps
Cool stuff, eh? That they keep it close to a regular, RISC processor means optimizations of that should carry over. Unlike stuff like Fifth Generation that tried to go way, way the hell to far with Prolog hardware. ;) Should fit nicely into my concept of general-purpose CPU's with purpose-built coprocessors. Also speculate techniques might be helpful on ASIC's meant for today's big-data apps that use things like Datalog for queries. Ya think?
Re: Show HN: QBE – a new compiler back end
#70If thé IL is text, and your goal is short understandable code, why not use a language like Python? (Compiling it with Cython would allow you to provide a C api and library with only lib python as a dep)
that would be painfully slow, as it stands now, qbe is actually quite a lot faster than gcc and clang.
So the 70% performance was about compiler performance, not compiled code performance?