LLVM Backend for the VideoCore4, Raspberry Pi 2 VPU • Hacker News Board

Re: LLVM Backend for the VideoCore4, Raspberry Pi 2 VPU

#51

Post by puppeh » Tue, May 03, 2016, 8:04 AM UTC

christina_b wrote: post #50

puppeh wrote: post #49

I did GCC too, https://github.com/puppeh/vc4-toolchain .

Yeah, I saw, I haven't looked at it in detail but I think yours probably works better than mine since you did comprehensive testing. My only tests involved compiling my own firmware code, but from what I can tell, it works well, I haven't ran into any bugs yet aside from what I outlined in the README. The assembler/linker I'm using is not ideal, I want to get MC code emission working eventually. I saw that you mentio…

No reason I guess, except it means an extra instruction. I thought about adding a flag for "large model" compilation, but it's not been a priority so far.

Re: LLVM Backend for the VideoCore4, Raspberry Pi 2 VPU

#52

Post by sklogic » Tue, May 03, 2016, 8:39 AM UTC

krasin wrote: post #9

willvarfar wrote: post #2

It bugs me that LLVM targets are not properly 'plug in'. LLVM backends can be in a plugin, but you have to tell the frontend which target to use (so it can use the correct data-layout etc). Its the frontends that don't support plug-in targets. Clang, for example, hardcodes the supported targets. A combination of using enums as a 'target triple' and lack of dynamic target registration conspire against easy-to-use out-…

Out-of-tree targets for LLVM are generally a bad idea given how fast LLVM is changed. Every change could break the out-of-tree target, and being out-of-tree, there's no way the upstream developers could notice that.

The other side of this approach is that when the mainline developers do not have much love to a particular platform, it is dropped altogether with little to no remorse - see the fate of Microblaze support, or even the good ol' C backend.

I wish we had a more stable API (maybe with a transformation layer) for the backends that may not probably need much of the new features. If LLVM had a maintained transformation layer from the "current" SelectionDAG to a stable one, it would have helped a lot.

Re: LLVM Backend for the VideoCore4, Raspberry Pi 2 VPU

#53

Post by sklogic » Tue, May 03, 2016, 8:45 AM UTC

sanxiyn wrote: post #31

duaneb wrote: post #29

Earlier quoted context omitted.

Why is this beneficial? It means you need to change several repositories to add one target triple. This may be a win in terms of in-tree stability, but it reduces accessibility to everyone else.

It is beneficial in that it discourages proprietary backends to LLVM which are not contributed back to LLVM. It is the same benefit GCC enjoys by using GPL.

There is a reason proprietary backends would always be necessary.

Hardware companies are very touchy about the patents, and not publishing an ISA-related work may often be the only way to protect from the trolls.

Such companies would often encourage (privately or publicly) clean room 3rd party backends, and I'm pretty sure that the one we're discussing here is exactly of this kind. But they would be scared to death to allow any of their employees to even send a tiny patch to a compiler backend, if it could expose some microarchitecture knowledge that was not published.

Re: LLVM Backend for the VideoCore4, Raspberry Pi 2 VPU

#54

Post by david-given » Tue, May 03, 2016, 3:16 PM UTC

christina_b wrote: post #40

david-given wrote: post #24

Earlier quoted context omitted.

Thanks for making this work! I'd given up on the LLVM backend completely due to showstopping issues I couldn't resolve, and had assumed it had vanished into the aether. Glad to know you found it useful! Regarding the boot loader, have you seen my piface boot loader? http://cowlark.com/piface/ It sounds like what you have is way more sophisticated, as I never got SDRAM init working properly, but you never know --- the…

Yeah I looked at it, my firmware mostly just aims at bringing up enough stuff to be able to boot ARM, which is essentially just: - Setting up exception vectors and enabling exceptions - Reclocking VPU from PLLC - UART initialization - SDRAM initialization - Copying an ARM blinker stub to 0x0 - ARM power domain initialization - PLLB initialization - Enabling passthrough mapping for ARM - ARM AXI interface initilaizati…

It's been too long and I've forgotten too much about how LLVM works. The gcc port I linked to, BTW, claims to have VC4 binutils.

Random question: how did you do 64 bit arithmetic? I couldn't find any kind of add-with-carry or subtract-with-carry instruction. I was semi-resigning myself to have to do a compare-and-test as well as the add, which would have more than doubled the amount of work.

Also, nice work reverse engineering the ARM controller --- how did you get the info?