Re: [omr-dev] Starting work on C front-end to OMR JIT

[Dibyendu Majumdar <mobile@xxxxxxxxxxxxxxx>]

Hi Mark,

On 15 June 2018 at 16:00, Mark Stoodley <mstoodle@xxxxxxxxxx> wrote:
> One thing that struck me immediately was the opcode enum you've defined locally. I wonder if you have a notion of how you'll keep up with new opcodes in OMR going forward? Is there a reason you didn't way to reuse the compiler/il/ILOpCodesEnum.hppfile to create that enum, and then have asserts to catch if someone starts using a new opcode that your code isn't yet designed to handle?
>

At this moment I just wanted a quick solution that would allow me to
start integrating a front-end. I agree the way I have done it is not
ideal - at the very least there needs to be some checks to ensure that
the enum values are aligned with the back-end. I could generate the
enums automatically from the  ILOpCodesEnum.hpp file. My goal  here is
to only expose two files to the client - a C header file, and a
library - so that is why I cannot expose/include any internal C++
headers.

I think if the opcodes were defined in a text file using some macro - e.g.:

OPCODE(dload)  // load double

I might have been able to copy this file during installation - and
just include/redefine the macros.

Regards
Dibyendu