Hi Brian,

I didn't thought about this before, but it's really a good idea to let the "old OC" do the parser stuff as it is the best free COBOL parser I know of (and likely that exists). To only change the code emitting sounds good AND doable.

But don't forget one thing: we still have (and need) the runtime libcob. So everything that is emitted still needs to call that.
- as C++ modules can call C modules - no problem (I'd drop the C emitter, once the C++ one is working - everyone that needs the C one can use OC 1.1)
- LLVM should be fine too (let the LLVM people do this)
- Java, especially byte-code would be interesting, but needs at least a Java wrapper for libcob
- .NET, especially ILE-code would be interesting, too (same stuff needed as with Java) - we may could use some stuff from the WildCat COBOL project

As Roger did: I'd like to accept patches for that. The only emitter I think that is *necessary* for the medium-range is C++ - I'd PM'd ska about that already.
I can offer a branch at CE for developing new code emmiters.

Simon 'human' Sobisch

This was prompted by the Simple cobol benchmark thread. An entry from ska.

Quote:

Sergey, when I found out how easy it was to plop OpenCOBOL on LLVM and clang, I posted to the LLVM IRC channel. A listener seemed quite intrigued with LLVM COBOL, and planned on looking over the sources to see if the C code generator couldn't be changed to an LLVM emitter.

So, sans Roger While (I'm worried and have no clue) would it be possible to modify OpenCOBOL to support multiple code emmitters? C, LLVM, C++ and perhaps Java (source or byte-code)?

By possible, I'm meaning is there the skill sets matched with motivations to take on such a task? Umm, that question is to everyone.

If not multiple emitters, same question of "possible" for a C++ codebase conversion? If and when OC adds Object COBOL that'd make things easier to start. I'm pretty sure it would ease addition of XML support as well.

Cheers,
Brian