[Libre-soc-bugs] [Bug 980] Implement C-based Power ISA pseudocode compiler

[bugzilla-daemon at libre-soc.org]

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

--- Comment #95 from Dmitry Selyutin <ghostmansd at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #94)
> (In reply to Jacob Lifshay from comment #93)
> 
> > all assignments need to set ok too,
> 
> yes.
> 
> > in the simulator copy_assign_rhs does
> > that by calling SelectableInt's constructor:
> > https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/
> > decoder/helpers.py;h=918a409eaf8e57762d7c67f692e6bd16d75dccba;
> > hb=97f603213814159f6da349735f7a2a07d72c42cf#l78
> 
> thanks for finding that.
> 
> > so, for now, you likely only need to ensure anything that writes to an
> > oppc_int is a function call, where ok = true can be put.
> 
> basically.

Folks, could you, please, elaborate, why it's done on a generic integer class?
I've been thinking rather of this approach:

struct oppc_reg {
    struct oppc_int value;
    uint64_t flags;
};

...where assignments to registers (and similar stuff) have the flags updated.
What's the point of having ok or flags in each and every integer? We have full
control over what entities we work on, and can detect whether pseudocode writes
into GPR or FPR or whatever.


> > later, not as part of this bug, we will need to support more than just
> > oppc_int, e.g. the bfp_* code uses a rational number as the mantissa
> > (SelectableMSB0Fraction, which likely needs more than 64 bits in both
> > numerator and denominator), and a BFPState struct.
> 
> typecast and operator overloads provide globals and other state.
> 
> c++ wrapper #includes *the c code*,
> (#include "autogenerated_compiler_output.c" - this is a trick from spike)
> and the end result is total redirection even of ctx.
> 
> dmitry note from the above that global variables in the c code
> (such as XLEN) are *perfectly fine* because when "wrapped" in
> a "using namespace" c++ context on the exact same autogenerated
> c code gets redirected.
> 
> trying that with ctx->XLEN is much harder to do in a c++ template/wrapper
> whereas just XLEN (in the autogenerated output) can be
> "#defined to ctx->THE_REAL_XLEN" for plain c, and made a
> member of the #including wrapper/template class in c++

Even omitting issues related to global context in general, this is a detail of
a particular implementation, the low-level architecture should be kept out of
these details. I don't want the implementation to be tied to a particular
language; at some point we might opt to reuse this generated code not only from
C++. We might have wrappers which fetch/store parts of the state though in
order to keep the context opaque.

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