[Libre-soc-bugs] [Bug 979] Implement C-based Power ISA decoder compiler

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Sun Sep 3 07:51:38 BST 2023


https://bugs.libre-soc.org/show_bug.cgi?id=979

--- Comment #24 from Dmitry Selyutin <ghostmansd at gmail.com> ---
(In reply to Jacob Lifshay from comment #23)
> (In reply to Luke Kenneth Casson Leighton from comment #19)
> > each function call blows a whopping *ten percent* of that available budget.
> 
> with tail-call optimization, you can get even better performance than a
> giant switch if you do it right...
> 
> also modern cpus usually correctly predict exactly where call and return
> insns go leaving them as very low cost (maybe 1 cycle each, or less if they
> overlap other computation), so, no, calls aren't always expensive.

I wouldn't rely too much on optimizations in the generated code. When it's
short and manually-written, it's already difficult enough to perform such
optimizations.

> (In reply to Dmitry Selyutin from comment #21)
> > OK, here's a better idea. No functions at all other than one huge function
> > which performs the jumps.
> 
> i think having separate functions is easier to understand, and with
> __attribute__((always_inline)) produces essentially identical code.

On the generation _product_ -- yes. I'd argue it's easier when we're talking
about the generator _itself_. :-) Also, I'd like to avoid non-portable
extensions whenever possible.

We do the same thing as binutils except that we don't have the distinction
between "usual" and "special" operands (those with and without callbacks). The
function with the switch is static and is a simple (C99) inline. Sufficient for
me, I'm moving on.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


More information about the libre-soc-bugs mailing list