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

[bugzilla-daemon at libre-soc.org]

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

--- Comment #20 from Dmitry Selyutin <ghostmansd at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #18)
> (In reply to Dmitry Selyutin from comment #15)
> > I think you remember how binutils did these tricks, eh?
> > 
> > #define TO TBR + 1
> > #define DUI TO
> > #define SVme TO
> > #define SVG TO
> 
> oh dear...

I knew you'd like it! They even had to drop parentheses in constructs like (TBR
+ 1), since some compilers bark at those.


> > We don't care about names, at all, other than for documentation purposes.
> 
> internally, no. externally, yes.  i.e. "as an API user", it should
> be bloody obvious, when someone looks at the spec, that "operand N
> is under Form M which oh look it's really obvious that that links
> this header file line Y to section A.B.C of the spec" 
> 
> therefore can you please make sure that the header-file and/or structs
> contain
> the Form as part of the "unique identification"?  something like:

Sure thing! Since it's not needed for either assembly or dissasembly yet, I'll
handle it later, OK? I'm planning to add even more stuff. I eventually want the
library to cover everything which we have in insndb. I think that, regardless
of cavatools, this will be useful per se. So, short answer: yes, there will be
many enums eventually, not that many in scope of this task though.

>    X_FORM_L0
>    X_FORM_L1
>    ...
> 
> i have very specifically ensured that "L" (which is a nightmare
> candidate that i have been warning IBM about for 3 years) as an
> example is unique... *only* if you prefix it with the Form, by
> renaming conflicting occurrences of "L" to "L0 L1 L2 L3".
> 
> i really want this to work with c, and not to critically depend
> on c++ namespaces.

This all will be C-based. The only use case for C++ I'm thinking of is register
remapping. That said, even there I'll likely avoid C++. First (and yes, this is
a damn good reason!), I don't like it. Second, it will complicate things.
Third... do we even need third here? Wrapping C API is trivial, especially for
C++; if some weirdo needs classes and templates (no idea why), they can do it
themselves.


(In reply to Luke Kenneth Casson Leighton from comment #19)
> you have to be very careful with higher-order-functions because they are
> very expensive (unless static-inlined, and even then)
> 
> this has to be a *high performance* API, with a budget of only 50 CPU cycles
> per emulated instruction.
> 
> each function call blows a whopping *ten percent* of that available budget.

Yes, binutils optimize the case when callback is empty, and deal with it
internally. I'm thinking of another way to handle it AND at the same time still
generate it. Stay tuned.

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