*Warning*

This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.

I have developed two new plugin opcodes for Csound. They embed the Clang/LLVM just-in-time C++ compiler into Csound, and allow Csound to compile C++ code in the Csound orchestra at run time, and to call code thus compiled, for example as opcodes.

These new opcodes, naturally, require both Csound and the full monty of Clang/LLVM, version 13, to be installed.

Currently there is a binary build of the opcodes only for Linux.  However, there is only one source code file, and adapting the build script for other operating systems should be straightforward.

The opcodes are available at https://github.com/gogins/clang-opcodes. For more information, see the README.md there.

I will demonstrate and discuss these opcodes in the upcoming International Csound Users Group virtual meeting on Zoom this coming Wednesday:

Topic: International Csound Users Group
Time: Oct 6, 2021 01:30 PM Eastern Time (US and Canada)

Join Zoom Meeting
https://us02web.zoom.us/j/84354088766?pwd=ektPSkpXeFQrUlZYUFM4cVNPMU01QT09

Meeting ID: 843 5408 8766
Passcode: 630670

Regards,

Mike

 

-----------------------------------------------------

Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com

el Fri, 1 Oct 2021 21:12:43 -0400
Michael Gogins  escribió:

> I have developed two new plugin opcodes for Csound. They embed the
> Clang/LLVM just-in-time C++ compiler into Csound, and allow Csound to
> compile C++ code in the Csound orchestra at run time, and to call
> code thus compiled, for example as opcodes.

Sounds terrific! Congratulations, Mike.


-- 
ljc 

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

I’ve managed to build the opcodes and run a simple C code on MacOS by adapting your scripts and CSD. 

I have not tried yet your factory example because I have to find where the C++ libs etc are to pass to the linker.
First attempt led to segfault but that was probably because of these missing libs.

Some system header files are giving me lots of spurious warnings but -w will not suppress them not sure why.

Next thing I’ll try is to add a simple C opcode and then call it in the Csound code. I think that may be a simpler
way to use the compilation opcode (rather than using the factory).

Anyway, it’s great that you have started this. It leads to interesting experiments.

========================
Prof. Victor Lazzarini
Maynooth University
Ireland

> On 2 Oct 2021, at 02:12, Michael Gogins  wrote:
> 
> WARNINGThis email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
> I have developed two new plugin opcodes for Csound. They embed the Clang/LLVM just-in-time C++ compiler into Csound, and allow Csound to compile C++ code in the Csound orchestra at run time, and to call code thus compiled, for example as opcodes.
> 
> These new opcodes, naturally, require both Csound and the full monty of Clang/LLVM, version 13, to be installed.
> 
> Currently there is a binary build of the opcodes only for Linux.  However, there is only one source code file, and adapting the build script for other operating systems should be straightforward.
> 
> The opcodes are available at https://github.com/gogins/clang-opcodes. For more information, see the README.md there.
> 
> I will demonstrate and discuss these opcodes in the upcoming International Csound Users Group virtual meeting on Zoom this coming Wednesday:
> 
> Topic: International Csound Users Group
> Time: Oct 6, 2021 01:30 PM Eastern Time (US and Canada)
> 
> Join Zoom Meeting
> https://us02web.zoom.us/j/84354088766?pwd=ektPSkpXeFQrUlZYUFM4cVNPMU01QT09
> 
> Meeting ID: 843 5408 8766
> Passcode: 630670
> 
> Regards,
> Mike
>  
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com

Do you think that this might mean that a lot of the code from The Audio Programming Book could be run in Csound?

Dr. Richard Boulanger
Professor
Electronic Production and Design
Berklee College of Music

> On Oct 8, 2021, at 5:40 PM, Victor Lazzarini  wrote:
> 
> I’ve managed to build the opcodes and run a simple C code on MacOS by adapting your scripts and CSD. 
> 
> I have not tried yet your factory example because I have to find where the C++ libs etc are to pass to the linker.
> First attempt led to segfault but that was probably because of these missing libs.
> 
> Some system header files are giving me lots of spurious warnings but -w will not suppress them not sure why.
> 
> Next thing I’ll try is to add a simple C opcode and then call it in the Csound code. I think that may be a simpler
> way to use the compilation opcode (rather than using the factory).
> 
> Anyway, it’s great that you have started this. It leads to interesting experiments.
> 
> ========================
> Prof. Victor Lazzarini
> Maynooth University
> Ireland
> 
>> On 2 Oct 2021, at 02:12, Michael Gogins  wrote:
>> 
>> WARNINGThis email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
>> I have developed two new plugin opcodes for Csound. They embed the Clang/LLVM just-in-time C++ compiler into Csound, and allow Csound to compile C++ code in the Csound orchestra at run time, and to call code thus compiled, for example as opcodes.
>> 
>> These new opcodes, naturally, require both Csound and the full monty of Clang/LLVM, version 13, to be installed.
>> 
>> Currently there is a binary build of the opcodes only for Linux.  However, there is only one source code file, and adapting the build script for other operating systems should be straightforward.
>> 
>> The opcodes are available at https://github.com/gogins/clang-opcodes. For more information, see the README.md there.
>> 
>> I will demonstrate and discuss these opcodes in the upcoming International Csound Users Group virtual meeting on Zoom this coming Wednesday:
>> 
>> Topic: International Csound Users Group
>> Time: Oct 6, 2021 01:30 PM Eastern Time (US and Canada)
>> 
>> Join Zoom Meeting
>> https://us02web.zoom.us/j/84354088766?pwd=ektPSkpXeFQrUlZYUFM4cVNPMU01QT09
>> 
>> Meeting ID: 843 5408 8766
>> Passcode: 630670
>> 
>> Regards,
>> Mike
>> 
>> -----------------------------------------------------
>> Michael Gogins
>> Irreducible Productions
>> http://michaelgogins.tumblr.com
>> Michael dot Gogins at gmail dot com
> 

Ok, giving it the libc++ and C++ header location, I get

####### clang_compile: invoking "csound_main" at 0x104837000:
>>>>>>> Hello, world! This proves csound_main has been called with csound: 0x7fdc5ef00000.
>>>>>>> This proves a lot of libstdc++ stuff works: strings.size(): 1 strings[0]: A test string...
>>>>>>> Now that we have manually defined our own __dso_handle, this proves std::cerr works as well!
####### clang_compile: "csound_main" returned: 0
******* Trying to invoke Hello...
####### clang_invoke::init: factory name: "hello_factory"
####### clang_invoke::init: factory function: 0x1048373e0
>>>>>>> hello_factory created: 0x7fdc5ecfb850
####### clang_invoke::init: instance: 0x7fdc5ecfb850 thread: 0
>>>>>>> This proves clang_invoke has called into this module.
####### clang_invoke::init: invokable::init: result: 0
******* clang_invoke returned: ">>>>>>> This proves clang_invoke can be used as an opcode that returns a string and multiplies a number by 2." and 4

csound command: Segmentation fault
####### clang_compile: deleting JITCompiler 0x7fdc6049a400 and ending execution session.
deativate: ip, nxt = 0x7fdc5fbab020 , 0x0
####### clang_invoke::noteoff

So it runs but then it crashes. The debugger says

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x380)
frame #0: 0x0000000102bde3b1 clang_opcodes.dylib`llvm::orc::JITCompiler::getSymbolAddress(llvm::StringRef const&) [inlined] llvm::orc::JITCompiler::findSymbol(this=0x0000000000000000, name=0x00007ffeefbff2a8) at clang_opcodes.cpp:178:43 [opt]
   175 	    Expected findSymbol(const StringRef &name)
   176 	    {
   177 	        return execution_session.lookup({&main_jit_dylib}, Mangle(name));
-> 178 	    }
   179 	    Expected getSymbolAddress(const StringRef &name)
   180 	    {
   181 	        auto symbol = findSymbol(name);


========================
Prof. Victor Lazzarini
Maynooth University
Ireland

> On 8 Oct 2021, at 23:32, Michael Gogins  wrote:
> 
> If you mean the clang libs use find. If some are missing install the missing features of clang. 
> 
> On Fri, Oct 8, 2021, 18:29 Michael Gogins  wrote:
> Run ldd on existing opcodes to find the libs.
> 
> On Fri, Oct 8, 2021, 17:40 Victor Lazzarini  wrote:
> I’ve managed to build the opcodes and run a simple C code on MacOS by adapting your scripts and CSD. 
> 
> I have not tried yet your factory example because I have to find where the C++ libs etc are to pass to the linker.
> First attempt led to segfault but that was probably because of these missing libs.
> 
> Some system header files are giving me lots of spurious warnings but -w will not suppress them not sure why.
> 
> Next thing I’ll try is to add a simple C opcode and then call it in the Csound code. I think that may be a simpler
> way to use the compilation opcode (rather than using the factory).
> 
> Anyway, it’s great that you have started this. It leads to interesting experiments.
> 
> ========================
> Prof. Victor Lazzarini
> Maynooth University
> Ireland
> 
> > On 2 Oct 2021, at 02:12, Michael Gogins  wrote:
> > 
> > WARNINGThis email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
> > I have developed two new plugin opcodes for Csound. They embed the Clang/LLVM just-in-time C++ compiler into Csound, and allow Csound to compile C++ code in the Csound orchestra at run time, and to call code thus compiled, for example as opcodes.
> > 
> > These new opcodes, naturally, require both Csound and the full monty of Clang/LLVM, version 13, to be installed.
> > 
> > Currently there is a binary build of the opcodes only for Linux.  However, there is only one source code file, and adapting the build script for other operating systems should be straightforward.
> > 
> > The opcodes are available at https://github.com/gogins/clang-opcodes. For more information, see the README.md there.
> > 
> > I will demonstrate and discuss these opcodes in the upcoming International Csound Users Group virtual meeting on Zoom this coming Wednesday:
> > 
> > Topic: International Csound Users Group
> > Time: Oct 6, 2021 01:30 PM Eastern Time (US and Canada)
> > 
> > Join Zoom Meeting
> > https://us02web.zoom.us/j/84354088766?pwd=ektPSkpXeFQrUlZYUFM4cVNPMU01QT09
> > 
> > Meeting ID: 843 5408 8766
> > Passcode: 630670
> > 
> > Regards,
> > Mike
> >  
> > -----------------------------------------------------
> > Michael Gogins
> > Irreducible Productions
> > http://michaelgogins.tumblr.com
> > Michael dot Gogins at gmail dot com
> 



Some of my pieces get a similar crash at the end on Ubuntu. Others do not crash. 

Everything is working until Csound is finished performing and begins to exit. 

In other words it is working the same for you as for me and seems quite usable. 

I will debug this. Your error messages are helpful. 

Regards, 

Mike

On Sat, Oct 9, 2021, 10:24 Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:

Ok, giving it the libc++ and C++ header location, I get

####### clang_compile: invoking "csound_main" at 0x104837000:
>>>>>>> Hello, world! This proves csound_main has been called with csound: 0x7fdc5ef00000.
>>>>>>> This proves a lot of libstdc++ stuff works: strings.size(): 1 strings[0]: A test string...
>>>>>>> Now that we have manually defined our own __dso_handle, this proves std::cerr works as well!
####### clang_compile: "csound_main" returned: 0
******* Trying to invoke Hello...
####### clang_invoke::init: factory name: "hello_factory"
####### clang_invoke::init: factory function: 0x1048373e0
>>>>>>> hello_factory created: 0x7fdc5ecfb850
####### clang_invoke::init: instance: 0x7fdc5ecfb850 thread: 0
>>>>>>> This proves clang_invoke has called into this module.
####### clang_invoke::init: invokable::init: result: 0
******* clang_invoke returned: ">>>>>>> This proves clang_invoke can be used as an opcode that returns a string and multiplies a number by 2." and 4

csound command: Segmentation fault
####### clang_compile: deleting JITCompiler 0x7fdc6049a400 and ending execution session.
deativate: ip, nxt = 0x7fdc5fbab020 , 0x0
####### clang_invoke::noteoff

So it runs but then it crashes. The debugger says

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x380)
frame #0: 0x0000000102bde3b1 clang_opcodes.dylib`llvm::orc::JITCompiler::getSymbolAddress(llvm::StringRef const&) [inlined] llvm::orc::JITCompiler::findSymbol(this=0x0000000000000000, name=0x00007ffeefbff2a8) at clang_opcodes.cpp:178:43 [opt]
   175      Expected<JITEvaluatedSymbol> findSymbol(const StringRef &name)
   176      {
   177          return execution_session.lookup({&main_jit_dylib}, Mangle(name));
-> 178      }
   179      Expected<JITTargetAddress> getSymbolAddress(const StringRef &name)
   180      {
   181          auto symbol = findSymbol(name);


========================
Prof. Victor Lazzarini
Maynooth University
Ireland

> On 8 Oct 2021, at 23:32, Michael Gogins <michael.gogins@gmail.com> wrote:
>
> If you mean the clang libs use find. If some are missing install the missing features of clang.
>
> On Fri, Oct 8, 2021, 18:29 Michael Gogins <michael.gogins@gmail.com> wrote:
> Run ldd on existing opcodes to find the libs.
>
> On Fri, Oct 8, 2021, 17:40 Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:
> I’ve managed to build the opcodes and run a simple C code on MacOS by adapting your scripts and CSD.
>
> I have not tried yet your factory example because I have to find where the C++ libs etc are to pass to the linker.
> First attempt led to segfault but that was probably because of these missing libs.
>
> Some system header files are giving me lots of spurious warnings but -w will not suppress them not sure why.
>
> Next thing I’ll try is to add a simple C opcode and then call it in the Csound code. I think that may be a simpler
> way to use the compilation opcode (rather than using the factory).
>
> Anyway, it’s great that you have started this. It leads to interesting experiments.
>
> ========================
> Prof. Victor Lazzarini
> Maynooth University
> Ireland
>
> > On 2 Oct 2021, at 02:12, Michael Gogins <michael.gogins@gmail.com> wrote:
> >
> > WARNINGThis email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
> > I have developed two new plugin opcodes for Csound. They embed the Clang/LLVM just-in-time C++ compiler into Csound, and allow Csound to compile C++ code in the Csound orchestra at run time, and to call code thus compiled, for example as opcodes.
> >
> > These new opcodes, naturally, require both Csound and the full monty of Clang/LLVM, version 13, to be installed.
> >
> > Currently there is a binary build of the opcodes only for Linux.  However, there is only one source code file, and adapting the build script for other operating systems should be straightforward.
> >
> > The opcodes are available at https://github.com/gogins/clang-opcodes. For more information, see the README.md there.
> >
> > I will demonstrate and discuss these opcodes in the upcoming International Csound Users Group virtual meeting on Zoom this coming Wednesday:
> >
> > Topic: International Csound Users Group
> > Time: Oct 6, 2021 01:30 PM Eastern Time (US and Canada)
> >
> > Join Zoom Meeting
> > https://us02web.zoom.us/j/84354088766?pwd=ektPSkpXeFQrUlZYUFM4cVNPMU01QT09
> >
> > Meeting ID: 843 5408 8766
> > Passcode: 630670
> >
> > Regards,
> > Mike
> > 
> > -----------------------------------------------------
> > Michael Gogins
> > Irreducible Productions
> > http://michaelgogins.tumblr.com
> > Michael dot Gogins at gmail dot com
>

After fixing a bug in Csound, I am now able to use your JIT compiler opcode to add a new opcode and run it.
The main difference with the factory/clang_invokable method is that since the opcode is added by the Csound
orchestra code, you can only use it in a subsequent compilation. 

Here’s the CSD example (with MacOS compile flags)



-odac --opcode-lib="./clang_opcodes.dylib" 


0dbfs = 1

SCode = {{
 #include 
 struct DATASPACE {
    OPDS h;
    MYFLT *out, *in, *gain;
 };

 static int init(CSOUND *csound, DATASPACE *p) {
       return OK;
 }

 static int perf(CSOUND *csound, DATASPACE *p) {
    MYFLT *out = p->out, *in = p->in, g = *p->gain;
    uint32_t offset = p->h.insdshead->ksmps_offset;
    uint32_t early  = p->h.insdshead->ksmps_no_end;
    uint32_t n, nsmps = CS_KSMPS;

    if (UNLIKELY(offset)) memset(out,0, offset*sizeof(MYFLT));
    if (UNLIKELY(early)) {
      nsmps -= early;
      memset(&out[nsmps],0, early*sizeof(MYFLT));
    }

    for(n=offset; n < nsmps; n++) out[n] = in[n]*g;
    return OK;
 }

 void* __dso_handle = (void *)&__dso_handle;
 extern "C" int csound_main(CSOUND *csound) {
    csound->AppendOpcode(csound, "amp",sizeof(DATASPACE),0,3,"a","ak",
                         (SUBR) init, (SUBR) perf, NULL);
    return 0;
 };
}}

SCscode = {{
    instr 1
     a1 oscili 1,440
     a2 amp a1, 0.5
     out a2
    endin
}}

SCflags =  "-DTARGET_OS_OSX -DTARGET_OS_IPHONE -I/Users/victor/Library/Frameworks/CsoundLib64.framework/Headers -I/usr/local/lib/clang/13.0.0/include/ -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/"
SLflags = ""

ires clang_compile "csound_main", SCode, SCflags, SLflags
ires compilestr SCscode



i1 0 2

 


========================
Prof. Victor Lazzarini
Maynooth University
Ireland

> On 9 Oct 2021, at 17:50, Victor Lazzarini  wrote:
> 
> Ok, I'll carry on experimenting and report back.
> 
> Prof. Victor Lazzarini
> Maynooth University
> Ireland
> 
>> On 9 Oct 2021, at 15:37, Michael Gogins  wrote:
>> 
>> 
>> Some of my pieces get a similar crash at the end on Ubuntu. Others do not crash. 
>> 
>> Everything is working until Csound is finished performing and begins to exit. 
>> 
>> In other words it is working the same for you as for me and seems quite usable. 
>> 
>> I will debug this. Your error messages are helpful. 
>> 
>> Regards, 
>> Mike
>> 
>> On Sat, Oct 9, 2021, 10:24 Victor Lazzarini  wrote:
>> Ok, giving it the libc++ and C++ header location, I get
>> 
>> ####### clang_compile: invoking "csound_main" at 0x104837000:
>> >>>>>>> Hello, world! This proves csound_main has been called with csound: 0x7fdc5ef00000.
>> >>>>>>> This proves a lot of libstdc++ stuff works: strings.size(): 1 strings[0]: A test string...
>> >>>>>>> Now that we have manually defined our own __dso_handle, this proves std::cerr works as well!
>> ####### clang_compile: "csound_main" returned: 0
>> ******* Trying to invoke Hello...
>> ####### clang_invoke::init: factory name: "hello_factory"
>> ####### clang_invoke::init: factory function: 0x1048373e0
>> >>>>>>> hello_factory created: 0x7fdc5ecfb850
>> ####### clang_invoke::init: instance: 0x7fdc5ecfb850 thread: 0
>> >>>>>>> This proves clang_invoke has called into this module.
>> ####### clang_invoke::init: invokable::init: result: 0
>> ******* clang_invoke returned: ">>>>>>> This proves clang_invoke can be used as an opcode that returns a string and multiplies a number by 2." and 4
>> 
>> csound command: Segmentation fault
>> ####### clang_compile: deleting JITCompiler 0x7fdc6049a400 and ending execution session.
>> deativate: ip, nxt = 0x7fdc5fbab020 , 0x0
>> ####### clang_invoke::noteoff
>> 
>> So it runs but then it crashes. The debugger says
>> 
>> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x380)
>> frame #0: 0x0000000102bde3b1 clang_opcodes.dylib`llvm::orc::JITCompiler::getSymbolAddress(llvm::StringRef const&) [inlined] llvm::orc::JITCompiler::findSymbol(this=0x0000000000000000, name=0x00007ffeefbff2a8) at clang_opcodes.cpp:178:43 [opt]
>>    175      Expected findSymbol(const StringRef &name)
>>    176      {
>>    177          return execution_session.lookup({&main_jit_dylib}, Mangle(name));
>> -> 178      }
>>    179      Expected getSymbolAddress(const StringRef &name)
>>    180      {
>>    181          auto symbol = findSymbol(name);
>> 
>> 
>> ========================
>> Prof. Victor Lazzarini
>> Maynooth University
>> Ireland
>> 
>> > On 8 Oct 2021, at 23:32, Michael Gogins  wrote:
>> > 
>> > If you mean the clang libs use find. If some are missing install the missing features of clang. 
>> > 
>> > On Fri, Oct 8, 2021, 18:29 Michael Gogins  wrote:
>> > Run ldd on existing opcodes to find the libs.
>> > 
>> > On Fri, Oct 8, 2021, 17:40 Victor Lazzarini  wrote:
>> > I’ve managed to build the opcodes and run a simple C code on MacOS by adapting your scripts and CSD. 
>> > 
>> > I have not tried yet your factory example because I have to find where the C++ libs etc are to pass to the linker.
>> > First attempt led to segfault but that was probably because of these missing libs.
>> > 
>> > Some system header files are giving me lots of spurious warnings but -w will not suppress them not sure why.
>> > 
>> > Next thing I’ll try is to add a simple C opcode and then call it in the Csound code. I think that may be a simpler
>> > way to use the compilation opcode (rather than using the factory).
>> > 
>> > Anyway, it’s great that you have started this. It leads to interesting experiments.
>> > 
>> > ========================
>> > Prof. Victor Lazzarini
>> > Maynooth University
>> > Ireland
>> > 
>> > > On 2 Oct 2021, at 02:12, Michael Gogins  wrote:
>> > > 
>> > > WARNINGThis email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
>> > > I have developed two new plugin opcodes for Csound. They embed the Clang/LLVM just-in-time C++ compiler into Csound, and allow Csound to compile C++ code in the Csound orchestra at run time, and to call code thus compiled, for example as opcodes.
>> > > 
>> > > These new opcodes, naturally, require both Csound and the full monty of Clang/LLVM, version 13, to be installed.
>> > > 
>> > > Currently there is a binary build of the opcodes only for Linux.  However, there is only one source code file, and adapting the build script for other operating systems should be straightforward.
>> > > 
>> > > The opcodes are available at https://github.com/gogins/clang-opcodes. For more information, see the README.md there.
>> > > 
>> > > I will demonstrate and discuss these opcodes in the upcoming International Csound Users Group virtual meeting on Zoom this coming Wednesday:
>> > > 
>> > > Topic: International Csound Users Group
>> > > Time: Oct 6, 2021 01:30 PM Eastern Time (US and Canada)
>> > > 
>> > > Join Zoom Meeting
>> > > https://us02web.zoom.us/j/84354088766?pwd=ektPSkpXeFQrUlZYUFM4cVNPMU01QT09
>> > > 
>> > > Meeting ID: 843 5408 8766
>> > > Passcode: 630670
>> > > 
>> > > Regards,
>> > > Mike
>> > >  
>> > > -----------------------------------------------------
>> > > Michael Gogins
>> > > Irreducible Productions
>> > > http://michaelgogins.tumblr.com
>> > > Michael dot Gogins at gmail dot com
>> > 
>> 

Thanks, I’ll have a go as soon as I can get round to.
In the meanwhile, I have been studying your code and the clang llvm interpreter example and I put together a simplified version of the opcode just designed to compile new opcodes (without dependencies). This currently supports C opcodes only, but I’ll look at adding C++ support later.

https://github.com/vlazzarini/opcode_compiler

The idea is to use this as a platform for exploring how to compile UDOs down to fast LLVM code. UDOs (without any opcode
calls to start with) would be parsed to a csound C opcode and then given to the JIT compiler.
========================
Prof. Victor Lazzarini
Maynooth University
Ireland
> On 10 Oct 2021, at 03:00, Michael Gogins  wrote:
> 
> I think I have fixed the crash on exit. In git now. 
> 
> On Sat, Oct 9, 2021, 18:15 Michael Gogins  wrote:
> Thanks for the fix. I tried this approach myself and it didn't work, which is why I created the ClangInvokable thing, and I suspect it's also why the Faust team used a similar approach. 
> 
> If your fix has been committed, I'll try this myself, in most cases this would be a better way.
> 
> I think I have a fix for the crash on exit, I'll let you know soon.
> 
> Regards, 
> Mike
> 
> 
> 
> On Sat, Oct 9, 2021, 17:11 Victor Lazzarini  wrote:
> After fixing a bug in Csound, I am now able to use your JIT compiler opcode to add a new opcode and run it.
> The main difference with the factory/clang_invokable method is that since the opcode is added by the Csound
> orchestra code, you can only use it in a subsequent compilation. 
> 
> Here’s the CSD example (with MacOS compile flags)
> 
> 
> 
> -odac --opcode-lib="./clang_opcodes.dylib" 
> 
> 
> 0dbfs = 1
> 
> SCode = {{
>  #include 
>  struct DATASPACE {
>     OPDS h;
>     MYFLT *out, *in, *gain;
>  };
> 
>  static int init(CSOUND *csound, DATASPACE *p) {
>        return OK;
>  }
> 
>  static int perf(CSOUND *csound, DATASPACE *p) {
>     MYFLT *out = p->out, *in = p->in, g = *p->gain;
>     uint32_t offset = p->h.insdshead->ksmps_offset;
>     uint32_t early  = p->h.insdshead->ksmps_no_end;
>     uint32_t n, nsmps = CS_KSMPS;
> 
>     if (UNLIKELY(offset)) memset(out,0, offset*sizeof(MYFLT));
>     if (UNLIKELY(early)) {
>       nsmps -= early;
>       memset(&out[nsmps],0, early*sizeof(MYFLT));
>     }
> 
>     for(n=offset; n < nsmps; n++) out[n] = in[n]*g;
>     return OK;
>  }
> 
>  void* __dso_handle = (void *)&__dso_handle;
>  extern "C" int csound_main(CSOUND *csound) {
>     csound->AppendOpcode(csound, "amp",sizeof(DATASPACE),0,3,"a","ak",
>                          (SUBR) init, (SUBR) perf, NULL);
>     return 0;
>  };
> }}
> 
> SCscode = {{
>     instr 1
>      a1 oscili 1,440
>      a2 amp a1, 0.5
>      out a2
>     endin
> }}
> 
> SCflags =  "-DTARGET_OS_OSX -DTARGET_OS_IPHONE -I/Users/victor/Library/Frameworks/CsoundLib64.framework/Headers -I/usr/local/lib/clang/13.0.0/include/ -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/"
> SLflags = ""
> 
> ires clang_compile "csound_main", SCode, SCflags, SLflags
> ires compilestr SCscode
> 
> 
> 
> i1 0 2
> 
>  
> 
> 
> ========================
> Prof. Victor Lazzarini
> Maynooth University
> Ireland
> 
> > On 9 Oct 2021, at 17:50, Victor Lazzarini  wrote:
> > 
> > Ok, I'll carry on experimenting and report back.
> > 
> > Prof. Victor Lazzarini
> > Maynooth University
> > Ireland
> > 
> >> On 9 Oct 2021, at 15:37, Michael Gogins  wrote:
> >> 
> >> 
> >> Some of my pieces get a similar crash at the end on Ubuntu. Others do not crash. 
> >> 
> >> Everything is working until Csound is finished performing and begins to exit. 
> >> 
> >> In other words it is working the same for you as for me and seems quite usable. 
> >> 
> >> I will debug this. Your error messages are helpful. 
> >> 
> >> Regards, 
> >> Mike
> >> 
> >> On Sat, Oct 9, 2021, 10:24 Victor Lazzarini  wrote:
> >> Ok, giving it the libc++ and C++ header location, I get
> >> 
> >> ####### clang_compile: invoking "csound_main" at 0x104837000:
> >> >>>>>>> Hello, world! This proves csound_main has been called with csound: 0x7fdc5ef00000.
> >> >>>>>>> This proves a lot of libstdc++ stuff works: strings.size(): 1 strings[0]: A test string...
> >> >>>>>>> Now that we have manually defined our own __dso_handle, this proves std::cerr works as well!
> >> ####### clang_compile: "csound_main" returned: 0
> >> ******* Trying to invoke Hello...
> >> ####### clang_invoke::init: factory name: "hello_factory"
> >> ####### clang_invoke::init: factory function: 0x1048373e0
> >> >>>>>>> hello_factory created: 0x7fdc5ecfb850
> >> ####### clang_invoke::init: instance: 0x7fdc5ecfb850 thread: 0
> >> >>>>>>> This proves clang_invoke has called into this module.
> >> ####### clang_invoke::init: invokable::init: result: 0
> >> ******* clang_invoke returned: ">>>>>>> This proves clang_invoke can be used as an opcode that returns a string and multiplies a number by 2." and 4
> >> 
> >> csound command: Segmentation fault
> >> ####### clang_compile: deleting JITCompiler 0x7fdc6049a400 and ending execution session.
> >> deativate: ip, nxt = 0x7fdc5fbab020 , 0x0
> >> ####### clang_invoke::noteoff
> >> 
> >> So it runs but then it crashes. The debugger says
> >> 
> >> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x380)
> >> frame #0: 0x0000000102bde3b1 clang_opcodes.dylib`llvm::orc::JITCompiler::getSymbolAddress(llvm::StringRef const&) [inlined] llvm::orc::JITCompiler::findSymbol(this=0x0000000000000000, name=0x00007ffeefbff2a8) at clang_opcodes.cpp:178:43 [opt]
> >>    175      Expected findSymbol(const StringRef &name)
> >>    176      {
> >>    177          return execution_session.lookup({&main_jit_dylib}, Mangle(name));
> >> -> 178      }
> >>    179      Expected getSymbolAddress(const StringRef &name)
> >>    180      {
> >>    181          auto symbol = findSymbol(name);
> >> 
> >> 
> >> ========================
> >> Prof. Victor Lazzarini
> >> Maynooth University
> >> Ireland
> >> 
> >> > On 8 Oct 2021, at 23:32, Michael Gogins  wrote:
> >> > 
> >> > If you mean the clang libs use find. If some are missing install the missing features of clang. 
> >> > 
> >> > On Fri, Oct 8, 2021, 18:29 Michael Gogins  wrote:
> >> > Run ldd on existing opcodes to find the libs.
> >> > 
> >> > On Fri, Oct 8, 2021, 17:40 Victor Lazzarini  wrote:
> >> > I’ve managed to build the opcodes and run a simple C code on MacOS by adapting your scripts and CSD. 
> >> > 
> >> > I have not tried yet your factory example because I have to find where the C++ libs etc are to pass to the linker.
> >> > First attempt led to segfault but that was probably because of these missing libs.
> >> > 
> >> > Some system header files are giving me lots of spurious warnings but -w will not suppress them not sure why.
> >> > 
> >> > Next thing I’ll try is to add a simple C opcode and then call it in the Csound code. I think that may be a simpler
> >> > way to use the compilation opcode (rather than using the factory).
> >> > 
> >> > Anyway, it’s great that you have started this. It leads to interesting experiments.
> >> > 
> >> > ========================
> >> > Prof. Victor Lazzarini
> >> > Maynooth University
> >> > Ireland
> >> > 
> >> > > On 2 Oct 2021, at 02:12, Michael Gogins  wrote:
> >> > > 
> >> > > WARNINGThis email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
> >> > > I have developed two new plugin opcodes for Csound. They embed the Clang/LLVM just-in-time C++ compiler into Csound, and allow Csound to compile C++ code in the Csound orchestra at run time, and to call code thus compiled, for example as opcodes.
> >> > > 
> >> > > These new opcodes, naturally, require both Csound and the full monty of Clang/LLVM, version 13, to be installed.
> >> > > 
> >> > > Currently there is a binary build of the opcodes only for Linux.  However, there is only one source code file, and adapting the build script for other operating systems should be straightforward.
> >> > > 
> >> > > The opcodes are available at https://github.com/gogins/clang-opcodes. For more information, see the README.md there.
> >> > > 
> >> > > I will demonstrate and discuss these opcodes in the upcoming International Csound Users Group virtual meeting on Zoom this coming Wednesday:
> >> > > 
> >> > > Topic: International Csound Users Group
> >> > > Time: Oct 6, 2021 01:30 PM Eastern Time (US and Canada)
> >> > > 
> >> > > Join Zoom Meeting
> >> > > https://us02web.zoom.us/j/84354088766?pwd=ektPSkpXeFQrUlZYUFM4cVNPMU01QT09
> >> > > 
> >> > > Meeting ID: 843 5408 8766
> >> > > Passcode: 630670
> >> > > 
> >> > > Regards,
> >> > > Mike
> >> > >  
> >> > > -----------------------------------------------------
> >> > > Michael Gogins
> >> > > Irreducible Productions
> >> > > http://michaelgogins.tumblr.com
> >> > > Michael dot Gogins at gmail dot com
> >> > 
> >> 
> 

I like the look of this a lot guys. Thanks for spending time on it.
Victor, in your example you create an orchestra and pass it to
compilestr(). I understand you need to recompile to have the opcode
available. This seems a little clunky. Don't get me wrong, this is
awesome, but is there any way the opcode_compile() call could also
recompile, or rerun the orc without the user having to do so? Or could
these opcodes be placed in a unique  section where the
opcodes parsed could be appended to the list of copcodes before Csound
runs?


On Mon, 11 Oct 2021 at 13:57, Victor Lazzarini  wrote:
>
> Thanks, I’ll have a go as soon as I can get round to.
> In the meanwhile, I have been studying your code and the clang llvm interpreter example and I put together a simplified version of the opcode just designed to compile new opcodes (without dependencies). This currently supports C opcodes only, but I’ll look at adding C++ support later.
>
> https://github.com/vlazzarini/opcode_compiler
>
> The idea is to use this as a platform for exploring how to compile UDOs down to fast LLVM code. UDOs (without any opcode
> calls to start with) would be parsed to a csound C opcode and then given to the JIT compiler.
> ========================
> Prof. Victor Lazzarini
> Maynooth University
> Ireland
> > On 10 Oct 2021, at 03:00, Michael Gogins  wrote:
> >
> > I think I have fixed the crash on exit. In git now.
> >
> > On Sat, Oct 9, 2021, 18:15 Michael Gogins  wrote:
> > Thanks for the fix. I tried this approach myself and it didn't work, which is why I created the ClangInvokable thing, and I suspect it's also why the Faust team used a similar approach.
> >
> > If your fix has been committed, I'll try this myself, in most cases this would be a better way.
> >
> > I think I have a fix for the crash on exit, I'll let you know soon.
> >
> > Regards,
> > Mike
> >
> >
> >
> > On Sat, Oct 9, 2021, 17:11 Victor Lazzarini  wrote:
> > After fixing a bug in Csound, I am now able to use your JIT compiler opcode to add a new opcode and run it.
> > The main difference with the factory/clang_invokable method is that since the opcode is added by the Csound
> > orchestra code, you can only use it in a subsequent compilation.
> >
> > Here’s the CSD example (with MacOS compile flags)
> >
> > 
> > 
> > -odac --opcode-lib="./clang_opcodes.dylib"
> > 
> > 
> > 0dbfs = 1
> >
> > SCode = {{
> >  #include 
> >  struct DATASPACE {
> >     OPDS h;
> >     MYFLT *out, *in, *gain;
> >  };
> >
> >  static int init(CSOUND *csound, DATASPACE *p) {
> >        return OK;
> >  }
> >
> >  static int perf(CSOUND *csound, DATASPACE *p) {
> >     MYFLT *out = p->out, *in = p->in, g = *p->gain;
> >     uint32_t offset = p->h.insdshead->ksmps_offset;
> >     uint32_t early  = p->h.insdshead->ksmps_no_end;
> >     uint32_t n, nsmps = CS_KSMPS;
> >
> >     if (UNLIKELY(offset)) memset(out,0, offset*sizeof(MYFLT));
> >     if (UNLIKELY(early)) {
> >       nsmps -= early;
> >       memset(&out[nsmps],0, early*sizeof(MYFLT));
> >     }
> >
> >     for(n=offset; n < nsmps; n++) out[n] = in[n]*g;
> >     return OK;
> >  }
> >
> >  void* __dso_handle = (void *)&__dso_handle;
> >  extern "C" int csound_main(CSOUND *csound) {
> >     csound->AppendOpcode(csound, "amp",sizeof(DATASPACE),0,3,"a","ak",
> >                          (SUBR) init, (SUBR) perf, NULL);
> >     return 0;
> >  };
> > }}
> >
> > SCscode = {{
> >     instr 1
> >      a1 oscili 1,440
> >      a2 amp a1, 0.5
> >      out a2
> >     endin
> > }}
> >
> > SCflags =  "-DTARGET_OS_OSX -DTARGET_OS_IPHONE -I/Users/victor/Library/Frameworks/CsoundLib64.framework/Headers -I/usr/local/lib/clang/13.0.0/include/ -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/"
> > SLflags = ""
> >
> > ires clang_compile "csound_main", SCode, SCflags, SLflags
> > ires compilestr SCscode
> >
> > 
> > 
> > i1 0 2
> > 
> > 
> >
> >
> > ========================
> > Prof. Victor Lazzarini
> > Maynooth University
> > Ireland
> >
> > > On 9 Oct 2021, at 17:50, Victor Lazzarini  wrote:
> > >
> > > Ok, I'll carry on experimenting and report back.
> > >
> > > Prof. Victor Lazzarini
> > > Maynooth University
> > > Ireland
> > >
> > >> On 9 Oct 2021, at 15:37, Michael Gogins  wrote:
> > >>
> > >> 
> > >> Some of my pieces get a similar crash at the end on Ubuntu. Others do not crash.
> > >>
> > >> Everything is working until Csound is finished performing and begins to exit.
> > >>
> > >> In other words it is working the same for you as for me and seems quite usable.
> > >>
> > >> I will debug this. Your error messages are helpful.
> > >>
> > >> Regards,
> > >> Mike
> > >>
> > >> On Sat, Oct 9, 2021, 10:24 Victor Lazzarini  wrote:
> > >> Ok, giving it the libc++ and C++ header location, I get
> > >>
> > >> ####### clang_compile: invoking "csound_main" at 0x104837000:
> > >> >>>>>>> Hello, world! This proves csound_main has been called with csound: 0x7fdc5ef00000.
> > >> >>>>>>> This proves a lot of libstdc++ stuff works: strings.size(): 1 strings[0]: A test string...
> > >> >>>>>>> Now that we have manually defined our own __dso_handle, this proves std::cerr works as well!
> > >> ####### clang_compile: "csound_main" returned: 0
> > >> ******* Trying to invoke Hello...
> > >> ####### clang_invoke::init: factory name: "hello_factory"
> > >> ####### clang_invoke::init: factory function: 0x1048373e0
> > >> >>>>>>> hello_factory created: 0x7fdc5ecfb850
> > >> ####### clang_invoke::init: instance: 0x7fdc5ecfb850 thread: 0
> > >> >>>>>>> This proves clang_invoke has called into this module.
> > >> ####### clang_invoke::init: invokable::init: result: 0
> > >> ******* clang_invoke returned: ">>>>>>> This proves clang_invoke can be used as an opcode that returns a string and multiplies a number by 2." and 4
> > >>
> > >> csound command: Segmentation fault
> > >> ####### clang_compile: deleting JITCompiler 0x7fdc6049a400 and ending execution session.
> > >> deativate: ip, nxt = 0x7fdc5fbab020 , 0x0
> > >> ####### clang_invoke::noteoff
> > >>
> > >> So it runs but then it crashes. The debugger says
> > >>
> > >> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x380)
> > >> frame #0: 0x0000000102bde3b1 clang_opcodes.dylib`llvm::orc::JITCompiler::getSymbolAddress(llvm::StringRef const&) [inlined] llvm::orc::JITCompiler::findSymbol(this=0x0000000000000000, name=0x00007ffeefbff2a8) at clang_opcodes.cpp:178:43 [opt]
> > >>    175      Expected findSymbol(const StringRef &name)
> > >>    176      {
> > >>    177          return execution_session.lookup({&main_jit_dylib}, Mangle(name));
> > >> -> 178      }
> > >>    179      Expected getSymbolAddress(const StringRef &name)
> > >>    180      {
> > >>    181          auto symbol = findSymbol(name);
> > >>
> > >>
> > >> ========================
> > >> Prof. Victor Lazzarini
> > >> Maynooth University
> > >> Ireland
> > >>
> > >> > On 8 Oct 2021, at 23:32, Michael Gogins  wrote:
> > >> >
> > >> > If you mean the clang libs use find. If some are missing install the missing features of clang.
> > >> >
> > >> > On Fri, Oct 8, 2021, 18:29 Michael Gogins  wrote:
> > >> > Run ldd on existing opcodes to find the libs.
> > >> >
> > >> > On Fri, Oct 8, 2021, 17:40 Victor Lazzarini  wrote:
> > >> > I’ve managed to build the opcodes and run a simple C code on MacOS by adapting your scripts and CSD.
> > >> >
> > >> > I have not tried yet your factory example because I have to find where the C++ libs etc are to pass to the linker.
> > >> > First attempt led to segfault but that was probably because of these missing libs.
> > >> >
> > >> > Some system header files are giving me lots of spurious warnings but -w will not suppress them not sure why.
> > >> >
> > >> > Next thing I’ll try is to add a simple C opcode and then call it in the Csound code. I think that may be a simpler
> > >> > way to use the compilation opcode (rather than using the factory).
> > >> >
> > >> > Anyway, it’s great that you have started this. It leads to interesting experiments.
> > >> >
> > >> > ========================
> > >> > Prof. Victor Lazzarini
> > >> > Maynooth University
> > >> > Ireland
> > >> >
> > >> > > On 2 Oct 2021, at 02:12, Michael Gogins  wrote:
> > >> > >
> > >> > > WARNINGThis email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
> > >> > > I have developed two new plugin opcodes for Csound. They embed the Clang/LLVM just-in-time C++ compiler into Csound, and allow Csound to compile C++ code in the Csound orchestra at run time, and to call code thus compiled, for example as opcodes.
> > >> > >
> > >> > > These new opcodes, naturally, require both Csound and the full monty of Clang/LLVM, version 13, to be installed.
> > >> > >
> > >> > > Currently there is a binary build of the opcodes only for Linux.  However, there is only one source code file, and adapting the build script for other operating systems should be straightforward.
> > >> > >
> > >> > > The opcodes are available at https://github.com/gogins/clang-opcodes. For more information, see the README.md there.
> > >> > >
> > >> > > I will demonstrate and discuss these opcodes in the upcoming International Csound Users Group virtual meeting on Zoom this coming Wednesday:
> > >> > >
> > >> > > Topic: International Csound Users Group
> > >> > > Time: Oct 6, 2021 01:30 PM Eastern Time (US and Canada)
> > >> > >
> > >> > > Join Zoom Meeting
> > >> > > https://us02web.zoom.us/j/84354088766?pwd=ektPSkpXeFQrUlZYUFM4cVNPMU01QT09
> > >> > >
> > >> > > Meeting ID: 843 5408 8766
> > >> > > Passcode: 630670
> > >> > >
> > >> > > Regards,
> > >> > > Mike
> > >> > >
> > >> > > -----------------------------------------------------
> > >> > > Michael Gogins
> > >> > > Irreducible Productions
> > >> > > http://michaelgogins.tumblr.com
> > >> > > Michael dot Gogins at gmail dot com
> > >> >
> > >>
> >
>

yes, it’s not ideal. The issue is that when the JIT is run, Csound is already running and the Csound code has already
been compiled. 

If we use a plugin to deploy the JIT as we are doing now, then there is no way round this. An alternative is to build the
JIT inside Csound and use a CSD section for plugins. However that means a big dependency being brought into Csound,
which is not ideal. However, we can make it an optional feature. In any case, that would be a CS7 thing.

One snag with this is that at the moment, the JIT needs a set of system headers that get include when we add
csdl.h. That’s not ideal, we should be able to just require Csound-provided headers. I think it is possible to fix this,
but we will need to be careful where we place headers in the Csound code. At the moment, since we never needed to
watch out for this, they are all over the place. I managed to move stdio.h so it’s only included where it is needed, but there
are a number of other headers.

So there’s a lot of experimentation ahead.
========================
Prof. Victor Lazzarini
Maynooth University
Ireland

> On 11 Oct 2021, at 14:15, Rory Walsh  wrote:
> 
> I like the look of this a lot guys. Thanks for spending time on it.
> Victor, in your example you create an orchestra and pass it to
> compilestr(). I understand you need to recompile to have the opcode
> available. This seems a little clunky. Don't get me wrong, this is
> awesome, but is there any way the opcode_compile() call could also
> recompile, or rerun the orc without the user having to do so? Or could
> these opcodes be placed in a unique  section where the
> opcodes parsed could be appended to the list of copcodes before Csound
> runs?
> 
> 
> On Mon, 11 Oct 2021 at 13:57, Victor Lazzarini  wrote:
>> 
>> Thanks, I’ll have a go as soon as I can get round to.
>> In the meanwhile, I have been studying your code and the clang llvm interpreter example and I put together a simplified version of the opcode just designed to compile new opcodes (without dependencies). This currently supports C opcodes only, but I’ll look at adding C++ support later.
>> 
>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fvlazzarini%2Fopcode_compiler&data=04%7C01%7CVictor.Lazzarini%40mu.ie%7C8e8993e7d25e492c336808d98cc196a8%7C1454f5ccbb354685bbd98621fd8055c9%7C1%7C0%7C637695585360530633%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=bnZUY5zb5v%2B%2BoQkEdErNWqdKXcXj06COgcKto3eRFQI%3D&reserved=0
>> 
>> The idea is to use this as a platform for exploring how to compile UDOs down to fast LLVM code. UDOs (without any opcode
>> calls to start with) would be parsed to a csound C opcode and then given to the JIT compiler.
>> ========================
>> Prof. Victor Lazzarini
>> Maynooth University
>> Ireland
>>> On 10 Oct 2021, at 03:00, Michael Gogins  wrote:
>>> 
>>> I think I have fixed the crash on exit. In git now.
>>> 
>>> On Sat, Oct 9, 2021, 18:15 Michael Gogins  wrote:
>>> Thanks for the fix. I tried this approach myself and it didn't work, which is why I created the ClangInvokable thing, and I suspect it's also why the Faust team used a similar approach.
>>> 
>>> If your fix has been committed, I'll try this myself, in most cases this would be a better way.
>>> 
>>> I think I have a fix for the crash on exit, I'll let you know soon.
>>> 
>>> Regards,
>>> Mike
>>> 
>>> 
>>> 
>>> On Sat, Oct 9, 2021, 17:11 Victor Lazzarini  wrote:
>>> After fixing a bug in Csound, I am now able to use your JIT compiler opcode to add a new opcode and run it.
>>> The main difference with the factory/clang_invokable method is that since the opcode is added by the Csound
>>> orchestra code, you can only use it in a subsequent compilation.
>>> 
>>> Here’s the CSD example (with MacOS compile flags)
>>> 
>>> 
>>> 
>>> -odac --opcode-lib="./clang_opcodes.dylib"
>>> 
>>> 
>>> 0dbfs = 1
>>> 
>>> SCode = {{
>>> #include 
>>> struct DATASPACE {
>>>    OPDS h;
>>>    MYFLT *out, *in, *gain;
>>> };
>>> 
>>> static int init(CSOUND *csound, DATASPACE *p) {
>>>       return OK;
>>> }
>>> 
>>> static int perf(CSOUND *csound, DATASPACE *p) {
>>>    MYFLT *out = p->out, *in = p->in, g = *p->gain;
>>>    uint32_t offset = p->h.insdshead->ksmps_offset;
>>>    uint32_t early  = p->h.insdshead->ksmps_no_end;
>>>    uint32_t n, nsmps = CS_KSMPS;
>>> 
>>>    if (UNLIKELY(offset)) memset(out,0, offset*sizeof(MYFLT));
>>>    if (UNLIKELY(early)) {
>>>      nsmps -= early;
>>>      memset(&out[nsmps],0, early*sizeof(MYFLT));
>>>    }
>>> 
>>>    for(n=offset; n < nsmps; n++) out[n] = in[n]*g;
>>>    return OK;
>>> }
>>> 
>>> void* __dso_handle = (void *)&__dso_handle;
>>> extern "C" int csound_main(CSOUND *csound) {
>>>    csound->AppendOpcode(csound, "amp",sizeof(DATASPACE),0,3,"a","ak",
>>>                         (SUBR) init, (SUBR) perf, NULL);
>>>    return 0;
>>> };
>>> }}
>>> 
>>> SCscode = {{
>>>    instr 1
>>>     a1 oscili 1,440
>>>     a2 amp a1, 0.5
>>>     out a2
>>>    endin
>>> }}
>>> 
>>> SCflags =  "-DTARGET_OS_OSX -DTARGET_OS_IPHONE -I/Users/victor/Library/Frameworks/CsoundLib64.framework/Headers -I/usr/local/lib/clang/13.0.0/include/ -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/"
>>> SLflags = ""
>>> 
>>> ires clang_compile "csound_main", SCode, SCflags, SLflags
>>> ires compilestr SCscode
>>> 
>>> 
>>> 
>>> i1 0 2
>>> 
>>> 
>>> 
>>> 
>>> ========================
>>> Prof. Victor Lazzarini
>>> Maynooth University
>>> Ireland
>>> 
>>>> On 9 Oct 2021, at 17:50, Victor Lazzarini  wrote:
>>>> 
>>>> Ok, I'll carry on experimenting and report back.
>>>> 
>>>> Prof. Victor Lazzarini
>>>> Maynooth University
>>>> Ireland
>>>> 
>>>>> On 9 Oct 2021, at 15:37, Michael Gogins  wrote:
>>>>> 
>>>>> 
>>>>> Some of my pieces get a similar crash at the end on Ubuntu. Others do not crash.
>>>>> 
>>>>> Everything is working until Csound is finished performing and begins to exit.
>>>>> 
>>>>> In other words it is working the same for you as for me and seems quite usable.
>>>>> 
>>>>> I will debug this. Your error messages are helpful.
>>>>> 
>>>>> Regards,
>>>>> Mike
>>>>> 
>>>>> On Sat, Oct 9, 2021, 10:24 Victor Lazzarini  wrote:
>>>>> Ok, giving it the libc++ and C++ header location, I get
>>>>> 
>>>>> ####### clang_compile: invoking "csound_main" at 0x104837000:
>>>>>>>>>>>> Hello, world! This proves csound_main has been called with csound: 0x7fdc5ef00000.
>>>>>>>>>>>> This proves a lot of libstdc++ stuff works: strings.size(): 1 strings[0]: A test string...
>>>>>>>>>>>> Now that we have manually defined our own __dso_handle, this proves std::cerr works as well!
>>>>> ####### clang_compile: "csound_main" returned: 0
>>>>> ******* Trying to invoke Hello...
>>>>> ####### clang_invoke::init: factory name: "hello_factory"
>>>>> ####### clang_invoke::init: factory function: 0x1048373e0
>>>>>>>>>>>> hello_factory created: 0x7fdc5ecfb850
>>>>> ####### clang_invoke::init: instance: 0x7fdc5ecfb850 thread: 0
>>>>>>>>>>>> This proves clang_invoke has called into this module.
>>>>> ####### clang_invoke::init: invokable::init: result: 0
>>>>> ******* clang_invoke returned: ">>>>>>> This proves clang_invoke can be used as an opcode that returns a string and multiplies a number by 2." and 4
>>>>> 
>>>>> csound command: Segmentation fault
>>>>> ####### clang_compile: deleting JITCompiler 0x7fdc6049a400 and ending execution session.
>>>>> deativate: ip, nxt = 0x7fdc5fbab020 , 0x0
>>>>> ####### clang_invoke::noteoff
>>>>> 
>>>>> So it runs but then it crashes. The debugger says
>>>>> 
>>>>> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x380)
>>>>> frame #0: 0x0000000102bde3b1 clang_opcodes.dylib`llvm::orc::JITCompiler::getSymbolAddress(llvm::StringRef const&) [inlined] llvm::orc::JITCompiler::findSymbol(this=0x0000000000000000, name=0x00007ffeefbff2a8) at clang_opcodes.cpp:178:43 [opt]
>>>>>   175      Expected findSymbol(const StringRef &name)
>>>>>   176      {
>>>>>   177          return execution_session.lookup({&main_jit_dylib}, Mangle(name));
>>>>> -> 178      }
>>>>>   179      Expected getSymbolAddress(const StringRef &name)
>>>>>   180      {
>>>>>   181          auto symbol = findSymbol(name);
>>>>> 
>>>>> 
>>>>> ========================
>>>>> Prof. Victor Lazzarini
>>>>> Maynooth University
>>>>> Ireland
>>>>> 
>>>>>> On 8 Oct 2021, at 23:32, Michael Gogins  wrote:
>>>>>> 
>>>>>> If you mean the clang libs use find. If some are missing install the missing features of clang.
>>>>>> 
>>>>>> On Fri, Oct 8, 2021, 18:29 Michael Gogins  wrote:
>>>>>> Run ldd on existing opcodes to find the libs.
>>>>>> 
>>>>>> On Fri, Oct 8, 2021, 17:40 Victor Lazzarini  wrote:
>>>>>> I’ve managed to build the opcodes and run a simple C code on MacOS by adapting your scripts and CSD.
>>>>>> 
>>>>>> I have not tried yet your factory example because I have to find where the C++ libs etc are to pass to the linker.
>>>>>> First attempt led to segfault but that was probably because of these missing libs.
>>>>>> 
>>>>>> Some system header files are giving me lots of spurious warnings but -w will not suppress them not sure why.
>>>>>> 
>>>>>> Next thing I’ll try is to add a simple C opcode and then call it in the Csound code. I think that may be a simpler
>>>>>> way to use the compilation opcode (rather than using the factory).
>>>>>> 
>>>>>> Anyway, it’s great that you have started this. It leads to interesting experiments.
>>>>>> 
>>>>>> ========================
>>>>>> Prof. Victor Lazzarini
>>>>>> Maynooth University
>>>>>> Ireland
>>>>>> 
>>>>>>> On 2 Oct 2021, at 02:12, Michael Gogins  wrote:
>>>>>>> 
>>>>>>> WARNINGThis email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
>>>>>>> I have developed two new plugin opcodes for Csound. They embed the Clang/LLVM just-in-time C++ compiler into Csound, and allow Csound to compile C++ code in the Csound orchestra at run time, and to call code thus compiled, for example as opcodes.
>>>>>>> 
>>>>>>> These new opcodes, naturally, require both Csound and the full monty of Clang/LLVM, version 13, to be installed.
>>>>>>> 
>>>>>>> Currently there is a binary build of the opcodes only for Linux.  However, there is only one source code file, and adapting the build script for other operating systems should be straightforward.
>>>>>>> 
>>>>>>> The opcodes are available at https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgogins%2Fclang-opcodes&data=04%7C01%7CVictor.Lazzarini%40mu.ie%7C8e8993e7d25e492c336808d98cc196a8%7C1454f5ccbb354685bbd98621fd8055c9%7C1%7C0%7C637695585360530633%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=jgjY1qWEWevC978CtP5NJO4VB1bSunWMoj64eiPL0qA%3D&reserved=0. For more information, see the README.md there.
>>>>>>> 
>>>>>>> I will demonstrate and discuss these opcodes in the upcoming International Csound Users Group virtual meeting on Zoom this coming Wednesday:
>>>>>>> 
>>>>>>> Topic: International Csound Users Group
>>>>>>> Time: Oct 6, 2021 01:30 PM Eastern Time (US and Canada)
>>>>>>> 
>>>>>>> Join Zoom Meeting
>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fus02web.zoom.us%2Fj%2F84354088766%3Fpwd%3DektPSkpXeFQrUlZYUFM4cVNPMU01QT09&data=04%7C01%7CVictor.Lazzarini%40mu.ie%7C8e8993e7d25e492c336808d98cc196a8%7C1454f5ccbb354685bbd98621fd8055c9%7C1%7C0%7C637695585360540627%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=lF1LDaxBITk%2FLfb%2Bv2vRfhwgQ8vpCtXZHqsED4gAaJQ%3D&reserved=0
>>>>>>> 
>>>>>>> Meeting ID: 843 5408 8766
>>>>>>> Passcode: 630670
>>>>>>> 
>>>>>>> Regards,
>>>>>>> Mike
>>>>>>> 
>>>>>>> -----------------------------------------------------
>>>>>>> Michael Gogins
>>>>>>> Irreducible Productions
>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmichaelgogins.tumblr.com%2F&data=04%7C01%7CVictor.Lazzarini%40mu.ie%7C8e8993e7d25e492c336808d98cc196a8%7C1454f5ccbb354685bbd98621fd8055c9%7C1%7C0%7C637695585360540627%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=du2vVHosmAmTH12d0ie6dpOPFJsUcLAZueKZEsOx4ko%3D&reserved=0
>>>>>>> Michael dot Gogins at gmail dot com
>>>>>> 
>>>>> 
>>> 
>> 

Ah yes, the less dependencies the better. I couldn't agree more with
this statement! So once you call compile_opcode(), any subsequent orc
compiles will have access to the new custom opcode. Could this be
out-sourced to the frontend? For example, could the opcode_compile()
opcode trigger a callback that can be set via the API. When it is
triggered the frontend could recompile the same orc, only this time
ignoring the opcode_compile() call? Also, does this handle multiple
opcodes with a single call? If not, I think it should. And if so, now
might be a good time to name it compile_opcodes()..? This seems more
consistent with other opcodes, i.e, compileorc, compilecsd, etc.

On Mon, 11 Oct 2021 at 15:34, Victor Lazzarini  wrote:
>
> yes, it’s not ideal. The issue is that when the JIT is run, Csound is already running and the Csound code has already
> been compiled.
>
> If we use a plugin to deploy the JIT as we are doing now, then there is no way round this. An alternative is to build the
> JIT inside Csound and use a CSD section for plugins. However that means a big dependency being brought into Csound,
> which is not ideal. However, we can make it an optional feature. In any case, that would be a CS7 thing.
>
> One snag with this is that at the moment, the JIT needs a set of system headers that get include when we add
> csdl.h. That’s not ideal, we should be able to just require Csound-provided headers. I think it is possible to fix this,
> but we will need to be careful where we place headers in the Csound code. At the moment, since we never needed to
> watch out for this, they are all over the place. I managed to move stdio.h so it’s only included where it is needed, but there
> are a number of other headers.
>
> So there’s a lot of experimentation ahead.
> ========================
> Prof. Victor Lazzarini
> Maynooth University
> Ireland
>
> > On 11 Oct 2021, at 14:15, Rory Walsh  wrote:
> >
> > I like the look of this a lot guys. Thanks for spending time on it.
> > Victor, in your example you create an orchestra and pass it to
> > compilestr(). I understand you need to recompile to have the opcode
> > available. This seems a little clunky. Don't get me wrong, this is
> > awesome, but is there any way the opcode_compile() call could also
> > recompile, or rerun the orc without the user having to do so? Or could
> > these opcodes be placed in a unique  section where the
> > opcodes parsed could be appended to the list of copcodes before Csound
> > runs?
> >
> >
> > On Mon, 11 Oct 2021 at 13:57, Victor Lazzarini  wrote:
> >>
> >> Thanks, I’ll have a go as soon as I can get round to.
> >> In the meanwhile, I have been studying your code and the clang llvm interpreter example and I put together a simplified version of the opcode just designed to compile new opcodes (without dependencies). This currently supports C opcodes only, but I’ll look at adding C++ support later.
> >>
> >> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fvlazzarini%2Fopcode_compiler&data=04%7C01%7CVictor.Lazzarini%40mu.ie%7C8e8993e7d25e492c336808d98cc196a8%7C1454f5ccbb354685bbd98621fd8055c9%7C1%7C0%7C637695585360530633%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=bnZUY5zb5v%2B%2BoQkEdErNWqdKXcXj06COgcKto3eRFQI%3D&reserved=0
> >>
> >> The idea is to use this as a platform for exploring how to compile UDOs down to fast LLVM code. UDOs (without any opcode
> >> calls to start with) would be parsed to a csound C opcode and then given to the JIT compiler.
> >> ========================
> >> Prof. Victor Lazzarini
> >> Maynooth University
> >> Ireland
> >>> On 10 Oct 2021, at 03:00, Michael Gogins  wrote:
> >>>
> >>> I think I have fixed the crash on exit. In git now.
> >>>
> >>> On Sat, Oct 9, 2021, 18:15 Michael Gogins  wrote:
> >>> Thanks for the fix. I tried this approach myself and it didn't work, which is why I created the ClangInvokable thing, and I suspect it's also why the Faust team used a similar approach.
> >>>
> >>> If your fix has been committed, I'll try this myself, in most cases this would be a better way.
> >>>
> >>> I think I have a fix for the crash on exit, I'll let you know soon.
> >>>
> >>> Regards,
> >>> Mike
> >>>
> >>>
> >>>
> >>> On Sat, Oct 9, 2021, 17:11 Victor Lazzarini  wrote:
> >>> After fixing a bug in Csound, I am now able to use your JIT compiler opcode to add a new opcode and run it.
> >>> The main difference with the factory/clang_invokable method is that since the opcode is added by the Csound
> >>> orchestra code, you can only use it in a subsequent compilation.
> >>>
> >>> Here’s the CSD example (with MacOS compile flags)
> >>>
> >>> 
> >>> 
> >>> -odac --opcode-lib="./clang_opcodes.dylib"
> >>> 
> >>> 
> >>> 0dbfs = 1
> >>>
> >>> SCode = {{
> >>> #include 
> >>> struct DATASPACE {
> >>>    OPDS h;
> >>>    MYFLT *out, *in, *gain;
> >>> };
> >>>
> >>> static int init(CSOUND *csound, DATASPACE *p) {
> >>>       return OK;
> >>> }
> >>>
> >>> static int perf(CSOUND *csound, DATASPACE *p) {
> >>>    MYFLT *out = p->out, *in = p->in, g = *p->gain;
> >>>    uint32_t offset = p->h.insdshead->ksmps_offset;
> >>>    uint32_t early  = p->h.insdshead->ksmps_no_end;
> >>>    uint32_t n, nsmps = CS_KSMPS;
> >>>
> >>>    if (UNLIKELY(offset)) memset(out,0, offset*sizeof(MYFLT));
> >>>    if (UNLIKELY(early)) {
> >>>      nsmps -= early;
> >>>      memset(&out[nsmps],0, early*sizeof(MYFLT));
> >>>    }
> >>>
> >>>    for(n=offset; n < nsmps; n++) out[n] = in[n]*g;
> >>>    return OK;
> >>> }
> >>>
> >>> void* __dso_handle = (void *)&__dso_handle;
> >>> extern "C" int csound_main(CSOUND *csound) {
> >>>    csound->AppendOpcode(csound, "amp",sizeof(DATASPACE),0,3,"a","ak",
> >>>                         (SUBR) init, (SUBR) perf, NULL);
> >>>    return 0;
> >>> };
> >>> }}
> >>>
> >>> SCscode = {{
> >>>    instr 1
> >>>     a1 oscili 1,440
> >>>     a2 amp a1, 0.5
> >>>     out a2
> >>>    endin
> >>> }}
> >>>
> >>> SCflags =  "-DTARGET_OS_OSX -DTARGET_OS_IPHONE -I/Users/victor/Library/Frameworks/CsoundLib64.framework/Headers -I/usr/local/lib/clang/13.0.0/include/ -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/"
> >>> SLflags = ""
> >>>
> >>> ires clang_compile "csound_main", SCode, SCflags, SLflags
> >>> ires compilestr SCscode
> >>>
> >>> 
> >>> 
> >>> i1 0 2
> >>> 
> >>> 
> >>>
> >>>
> >>> ========================
> >>> Prof. Victor Lazzarini
> >>> Maynooth University
> >>> Ireland
> >>>
> >>>> On 9 Oct 2021, at 17:50, Victor Lazzarini  wrote:
> >>>>
> >>>> Ok, I'll carry on experimenting and report back.
> >>>>
> >>>> Prof. Victor Lazzarini
> >>>> Maynooth University
> >>>> Ireland
> >>>>
> >>>>> On 9 Oct 2021, at 15:37, Michael Gogins  wrote:
> >>>>>
> >>>>> 
> >>>>> Some of my pieces get a similar crash at the end on Ubuntu. Others do not crash.
> >>>>>
> >>>>> Everything is working until Csound is finished performing and begins to exit.
> >>>>>
> >>>>> In other words it is working the same for you as for me and seems quite usable.
> >>>>>
> >>>>> I will debug this. Your error messages are helpful.
> >>>>>
> >>>>> Regards,
> >>>>> Mike
> >>>>>
> >>>>> On Sat, Oct 9, 2021, 10:24 Victor Lazzarini  wrote:
> >>>>> Ok, giving it the libc++ and C++ header location, I get
> >>>>>
> >>>>> ####### clang_compile: invoking "csound_main" at 0x104837000:
> >>>>>>>>>>>> Hello, world! This proves csound_main has been called with csound: 0x7fdc5ef00000.
> >>>>>>>>>>>> This proves a lot of libstdc++ stuff works: strings.size(): 1 strings[0]: A test string...
> >>>>>>>>>>>> Now that we have manually defined our own __dso_handle, this proves std::cerr works as well!
> >>>>> ####### clang_compile: "csound_main" returned: 0
> >>>>> ******* Trying to invoke Hello...
> >>>>> ####### clang_invoke::init: factory name: "hello_factory"
> >>>>> ####### clang_invoke::init: factory function: 0x1048373e0
> >>>>>>>>>>>> hello_factory created: 0x7fdc5ecfb850
> >>>>> ####### clang_invoke::init: instance: 0x7fdc5ecfb850 thread: 0
> >>>>>>>>>>>> This proves clang_invoke has called into this module.
> >>>>> ####### clang_invoke::init: invokable::init: result: 0
> >>>>> ******* clang_invoke returned: ">>>>>>> This proves clang_invoke can be used as an opcode that returns a string and multiplies a number by 2." and 4
> >>>>>
> >>>>> csound command: Segmentation fault
> >>>>> ####### clang_compile: deleting JITCompiler 0x7fdc6049a400 and ending execution session.
> >>>>> deativate: ip, nxt = 0x7fdc5fbab020 , 0x0
> >>>>> ####### clang_invoke::noteoff
> >>>>>
> >>>>> So it runs but then it crashes. The debugger says
> >>>>>
> >>>>> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x380)
> >>>>> frame #0: 0x0000000102bde3b1 clang_opcodes.dylib`llvm::orc::JITCompiler::getSymbolAddress(llvm::StringRef const&) [inlined] llvm::orc::JITCompiler::findSymbol(this=0x0000000000000000, name=0x00007ffeefbff2a8) at clang_opcodes.cpp:178:43 [opt]
> >>>>>   175      Expected findSymbol(const StringRef &name)
> >>>>>   176      {
> >>>>>   177          return execution_session.lookup({&main_jit_dylib}, Mangle(name));
> >>>>> -> 178      }
> >>>>>   179      Expected getSymbolAddress(const StringRef &name)
> >>>>>   180      {
> >>>>>   181          auto symbol = findSymbol(name);
> >>>>>
> >>>>>
> >>>>> ========================
> >>>>> Prof. Victor Lazzarini
> >>>>> Maynooth University
> >>>>> Ireland
> >>>>>
> >>>>>> On 8 Oct 2021, at 23:32, Michael Gogins  wrote:
> >>>>>>
> >>>>>> If you mean the clang libs use find. If some are missing install the missing features of clang.
> >>>>>>
> >>>>>> On Fri, Oct 8, 2021, 18:29 Michael Gogins  wrote:
> >>>>>> Run ldd on existing opcodes to find the libs.
> >>>>>>
> >>>>>> On Fri, Oct 8, 2021, 17:40 Victor Lazzarini  wrote:
> >>>>>> I’ve managed to build the opcodes and run a simple C code on MacOS by adapting your scripts and CSD.
> >>>>>>
> >>>>>> I have not tried yet your factory example because I have to find where the C++ libs etc are to pass to the linker.
> >>>>>> First attempt led to segfault but that was probably because of these missing libs.
> >>>>>>
> >>>>>> Some system header files are giving me lots of spurious warnings but -w will not suppress them not sure why.
> >>>>>>
> >>>>>> Next thing I’ll try is to add a simple C opcode and then call it in the Csound code. I think that may be a simpler
> >>>>>> way to use the compilation opcode (rather than using the factory).
> >>>>>>
> >>>>>> Anyway, it’s great that you have started this. It leads to interesting experiments.
> >>>>>>
> >>>>>> ========================
> >>>>>> Prof. Victor Lazzarini
> >>>>>> Maynooth University
> >>>>>> Ireland
> >>>>>>
> >>>>>>> On 2 Oct 2021, at 02:12, Michael Gogins  wrote:
> >>>>>>>
> >>>>>>> WARNINGThis email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
> >>>>>>> I have developed two new plugin opcodes for Csound. They embed the Clang/LLVM just-in-time C++ compiler into Csound, and allow Csound to compile C++ code in the Csound orchestra at run time, and to call code thus compiled, for example as opcodes.
> >>>>>>>
> >>>>>>> These new opcodes, naturally, require both Csound and the full monty of Clang/LLVM, version 13, to be installed.
> >>>>>>>
> >>>>>>> Currently there is a binary build of the opcodes only for Linux.  However, there is only one source code file, and adapting the build script for other operating systems should be straightforward.
> >>>>>>>
> >>>>>>> The opcodes are available at https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgogins%2Fclang-opcodes&data=04%7C01%7CVictor.Lazzarini%40mu.ie%7C8e8993e7d25e492c336808d98cc196a8%7C1454f5ccbb354685bbd98621fd8055c9%7C1%7C0%7C637695585360530633%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=jgjY1qWEWevC978CtP5NJO4VB1bSunWMoj64eiPL0qA%3D&reserved=0. For more information, see the README.md there.
> >>>>>>>
> >>>>>>> I will demonstrate and discuss these opcodes in the upcoming International Csound Users Group virtual meeting on Zoom this coming Wednesday:
> >>>>>>>
> >>>>>>> Topic: International Csound Users Group
> >>>>>>> Time: Oct 6, 2021 01:30 PM Eastern Time (US and Canada)
> >>>>>>>
> >>>>>>> Join Zoom Meeting
> >>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fus02web.zoom.us%2Fj%2F84354088766%3Fpwd%3DektPSkpXeFQrUlZYUFM4cVNPMU01QT09&data=04%7C01%7CVictor.Lazzarini%40mu.ie%7C8e8993e7d25e492c336808d98cc196a8%7C1454f5ccbb354685bbd98621fd8055c9%7C1%7C0%7C637695585360540627%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=lF1LDaxBITk%2FLfb%2Bv2vRfhwgQ8vpCtXZHqsED4gAaJQ%3D&reserved=0
> >>>>>>>
> >>>>>>> Meeting ID: 843 5408 8766
> >>>>>>> Passcode: 630670
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>> Mike
> >>>>>>>
> >>>>>>> -----------------------------------------------------
> >>>>>>> Michael Gogins
> >>>>>>> Irreducible Productions
> >>>>>>> https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmichaelgogins.tumblr.com%2F&data=04%7C01%7CVictor.Lazzarini%40mu.ie%7C8e8993e7d25e492c336808d98cc196a8%7C1454f5ccbb354685bbd98621fd8055c9%7C1%7C0%7C637695585360540627%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=du2vVHosmAmTH12d0ie6dpOPFJsUcLAZueKZEsOx4ko%3D&reserved=0
> >>>>>>> Michael dot Gogins at gmail dot com
> >>>>>>
> >>>>>
> >>>
> >>
>

You see you can’t add the new opcode in your initial csound code because that’s not there and
it will fail. Once it’s compiled then you can send in an instrument that will use it, so I think callbacks
are just complicating the issue.

If you add a call to compilestr following the addition of the opcode, then it will work (as in the example).
The JIT will take any amount of C code you want to throw at it. So as many opcodes as you’d like.

Compile opcodes sounds better alright. I’ll see about changing it.
========================
Prof. Victor Lazzarini
Maynooth University
Ireland

> On 11 Oct 2021, at 16:03, Rory Walsh  wrote:
> 
> Ah yes, the less dependencies the better. I couldn't agree more with
> this statement! So once you call compile_opcode(), any subsequent orc
> compiles will have access to the new custom opcode. Could this be
> out-sourced to the frontend? For example, could the opcode_compile()
> opcode trigger a callback that can be set via the API. When it is
> triggered the frontend could recompile the same orc, only this time
> ignoring the opcode_compile() call? Also, does this handle multiple
> opcodes with a single call? If not, I think it should. And if so, now
> might be a good time to name it compile_opcodes()..? This seems more
> consistent with other opcodes, i.e, compileorc, compilecsd, etc.
> 
> On Mon, 11 Oct 2021 at 15:34, Victor Lazzarini  wrote:
>> 
>> yes, it’s not ideal. The issue is that when the JIT is run, Csound is already running and the Csound code has already
>> been compiled.
>> 
>> If we use a plugin to deploy the JIT as we are doing now, then there is no way round this. An alternative is to build the
>> JIT inside Csound and use a CSD section for plugins. However that means a big dependency being brought into Csound,
>> which is not ideal. However, we can make it an optional feature. In any case, that would be a CS7 thing.
>> 
>> One snag with this is that at the moment, the JIT needs a set of system headers that get include when we add
>> csdl.h. That’s not ideal, we should be able to just require Csound-provided headers. I think it is possible to fix this,
>> but we will need to be careful where we place headers in the Csound code. At the moment, since we never needed to
>> watch out for this, they are all over the place. I managed to move stdio.h so it’s only included where it is needed, but there
>> are a number of other headers.
>> 
>> So there’s a lot of experimentation ahead.
>> ========================
>> Prof. Victor Lazzarini
>> Maynooth University
>> Ireland
>> 
>>> On 11 Oct 2021, at 14:15, Rory Walsh  wrote:
>>> 
>>> I like the look of this a lot guys. Thanks for spending time on it.
>>> Victor, in your example you create an orchestra and pass it to
>>> compilestr(). I understand you need to recompile to have the opcode
>>> available. This seems a little clunky. Don't get me wrong, this is
>>> awesome, but is there any way the opcode_compile() call could also
>>> recompile, or rerun the orc without the user having to do so? Or could
>>> these opcodes be placed in a unique  section where the
>>> opcodes parsed could be appended to the list of copcodes before Csound
>>> runs?
>>> 
>>> 
>>> On Mon, 11 Oct 2021 at 13:57, Victor Lazzarini  wrote:
>>>> 
>>>> Thanks, I’ll have a go as soon as I can get round to.
>>>> In the meanwhile, I have been studying your code and the clang llvm interpreter example and I put together a simplified version of the opcode just designed to compile new opcodes (without dependencies). This currently supports C opcodes only, but I’ll look at adding C++ support later.
>>>> 
>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fvlazzarini%2Fopcode_compiler&data=04%7C01%7CVictor.Lazzarini%40mu.ie%7Cdf47ca974a42467937b608d98cc85abe%7C1454f5ccbb354685bbd98621fd8055c9%7C1%7C0%7C637695614413511441%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=et35m%2BpLSwONi%2BXjvCn7rBBh4yl7SzTfQj5H9CmCFbo%3D&reserved=0
>>>> 
>>>> The idea is to use this as a platform for exploring how to compile UDOs down to fast LLVM code. UDOs (without any opcode
>>>> calls to start with) would be parsed to a csound C opcode and then given to the JIT compiler.
>>>> ========================
>>>> Prof. Victor Lazzarini
>>>> Maynooth University
>>>> Ireland
>>>>> On 10 Oct 2021, at 03:00, Michael Gogins  wrote:
>>>>> 
>>>>> I think I have fixed the crash on exit. In git now.
>>>>> 
>>>>> On Sat, Oct 9, 2021, 18:15 Michael Gogins  wrote:
>>>>> Thanks for the fix. I tried this approach myself and it didn't work, which is why I created the ClangInvokable thing, and I suspect it's also why the Faust team used a similar approach.
>>>>> 
>>>>> If your fix has been committed, I'll try this myself, in most cases this would be a better way.
>>>>> 
>>>>> I think I have a fix for the crash on exit, I'll let you know soon.
>>>>> 
>>>>> Regards,
>>>>> Mike
>>>>> 
>>>>> 
>>>>> 
>>>>> On Sat, Oct 9, 2021, 17:11 Victor Lazzarini  wrote:
>>>>> After fixing a bug in Csound, I am now able to use your JIT compiler opcode to add a new opcode and run it.
>>>>> The main difference with the factory/clang_invokable method is that since the opcode is added by the Csound
>>>>> orchestra code, you can only use it in a subsequent compilation.
>>>>> 
>>>>> Here’s the CSD example (with MacOS compile flags)
>>>>> 
>>>>> 
>>>>> 
>>>>> -odac --opcode-lib="./clang_opcodes.dylib"
>>>>> 
>>>>> 
>>>>> 0dbfs = 1
>>>>> 
>>>>> SCode = {{
>>>>> #include 
>>>>> struct DATASPACE {
>>>>>   OPDS h;
>>>>>   MYFLT *out, *in, *gain;
>>>>> };
>>>>> 
>>>>> static int init(CSOUND *csound, DATASPACE *p) {
>>>>>      return OK;
>>>>> }
>>>>> 
>>>>> static int perf(CSOUND *csound, DATASPACE *p) {
>>>>>   MYFLT *out = p->out, *in = p->in, g = *p->gain;
>>>>>   uint32_t offset = p->h.insdshead->ksmps_offset;
>>>>>   uint32_t early  = p->h.insdshead->ksmps_no_end;
>>>>>   uint32_t n, nsmps = CS_KSMPS;
>>>>> 
>>>>>   if (UNLIKELY(offset)) memset(out,0, offset*sizeof(MYFLT));
>>>>>   if (UNLIKELY(early)) {
>>>>>     nsmps -= early;
>>>>>     memset(&out[nsmps],0, early*sizeof(MYFLT));
>>>>>   }
>>>>> 
>>>>>   for(n=offset; n < nsmps; n++) out[n] = in[n]*g;
>>>>>   return OK;
>>>>> }
>>>>> 
>>>>> void* __dso_handle = (void *)&__dso_handle;
>>>>> extern "C" int csound_main(CSOUND *csound) {
>>>>>   csound->AppendOpcode(csound, "amp",sizeof(DATASPACE),0,3,"a","ak",
>>>>>                        (SUBR) init, (SUBR) perf, NULL);
>>>>>   return 0;
>>>>> };
>>>>> }}
>>>>> 
>>>>> SCscode = {{
>>>>>   instr 1
>>>>>    a1 oscili 1,440
>>>>>    a2 amp a1, 0.5
>>>>>    out a2
>>>>>   endin
>>>>> }}
>>>>> 
>>>>> SCflags =  "-DTARGET_OS_OSX -DTARGET_OS_IPHONE -I/Users/victor/Library/Frameworks/CsoundLib64.framework/Headers -I/usr/local/lib/clang/13.0.0/include/ -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/"
>>>>> SLflags = ""
>>>>> 
>>>>> ires clang_compile "csound_main", SCode, SCflags, SLflags
>>>>> ires compilestr SCscode
>>>>> 
>>>>> 
>>>>> 
>>>>> i1 0 2
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> ========================
>>>>> Prof. Victor Lazzarini
>>>>> Maynooth University
>>>>> Ireland
>>>>> 
>>>>>> On 9 Oct 2021, at 17:50, Victor Lazzarini  wrote:
>>>>>> 
>>>>>> Ok, I'll carry on experimenting and report back.
>>>>>> 
>>>>>> Prof. Victor Lazzarini
>>>>>> Maynooth University
>>>>>> Ireland
>>>>>> 
>>>>>>> On 9 Oct 2021, at 15:37, Michael Gogins  wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> Some of my pieces get a similar crash at the end on Ubuntu. Others do not crash.
>>>>>>> 
>>>>>>> Everything is working until Csound is finished performing and begins to exit.
>>>>>>> 
>>>>>>> In other words it is working the same for you as for me and seems quite usable.
>>>>>>> 
>>>>>>> I will debug this. Your error messages are helpful.
>>>>>>> 
>>>>>>> Regards,
>>>>>>> Mike
>>>>>>> 
>>>>>>> On Sat, Oct 9, 2021, 10:24 Victor Lazzarini  wrote:
>>>>>>> Ok, giving it the libc++ and C++ header location, I get
>>>>>>> 
>>>>>>> ####### clang_compile: invoking "csound_main" at 0x104837000:
>>>>>>>>>>>>>> Hello, world! This proves csound_main has been called with csound: 0x7fdc5ef00000.
>>>>>>>>>>>>>> This proves a lot of libstdc++ stuff works: strings.size(): 1 strings[0]: A test string...
>>>>>>>>>>>>>> Now that we have manually defined our own __dso_handle, this proves std::cerr works as well!
>>>>>>> ####### clang_compile: "csound_main" returned: 0
>>>>>>> ******* Trying to invoke Hello...
>>>>>>> ####### clang_invoke::init: factory name: "hello_factory"
>>>>>>> ####### clang_invoke::init: factory function: 0x1048373e0
>>>>>>>>>>>>>> hello_factory created: 0x7fdc5ecfb850
>>>>>>> ####### clang_invoke::init: instance: 0x7fdc5ecfb850 thread: 0
>>>>>>>>>>>>>> This proves clang_invoke has called into this module.
>>>>>>> ####### clang_invoke::init: invokable::init: result: 0
>>>>>>> ******* clang_invoke returned: ">>>>>>> This proves clang_invoke can be used as an opcode that returns a string and multiplies a number by 2." and 4
>>>>>>> 
>>>>>>> csound command: Segmentation fault
>>>>>>> ####### clang_compile: deleting JITCompiler 0x7fdc6049a400 and ending execution session.
>>>>>>> deativate: ip, nxt = 0x7fdc5fbab020 , 0x0
>>>>>>> ####### clang_invoke::noteoff
>>>>>>> 
>>>>>>> So it runs but then it crashes. The debugger says
>>>>>>> 
>>>>>>> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x380)
>>>>>>> frame #0: 0x0000000102bde3b1 clang_opcodes.dylib`llvm::orc::JITCompiler::getSymbolAddress(llvm::StringRef const&) [inlined] llvm::orc::JITCompiler::findSymbol(this=0x0000000000000000, name=0x00007ffeefbff2a8) at clang_opcodes.cpp:178:43 [opt]
>>>>>>>  175      Expected findSymbol(const StringRef &name)
>>>>>>>  176      {
>>>>>>>  177          return execution_session.lookup({&main_jit_dylib}, Mangle(name));
>>>>>>> -> 178      }
>>>>>>>  179      Expected getSymbolAddress(const StringRef &name)
>>>>>>>  180      {
>>>>>>>  181          auto symbol = findSymbol(name);
>>>>>>> 
>>>>>>> 
>>>>>>> ========================
>>>>>>> Prof. Victor Lazzarini
>>>>>>> Maynooth University
>>>>>>> Ireland
>>>>>>> 
>>>>>>>> On 8 Oct 2021, at 23:32, Michael Gogins  wrote:
>>>>>>>> 
>>>>>>>> If you mean the clang libs use find. If some are missing install the missing features of clang.
>>>>>>>> 
>>>>>>>> On Fri, Oct 8, 2021, 18:29 Michael Gogins  wrote:
>>>>>>>> Run ldd on existing opcodes to find the libs.
>>>>>>>> 
>>>>>>>> On Fri, Oct 8, 2021, 17:40 Victor Lazzarini  wrote:
>>>>>>>> I’ve managed to build the opcodes and run a simple C code on MacOS by adapting your scripts and CSD.
>>>>>>>> 
>>>>>>>> I have not tried yet your factory example because I have to find where the C++ libs etc are to pass to the linker.
>>>>>>>> First attempt led to segfault but that was probably because of these missing libs.
>>>>>>>> 
>>>>>>>> Some system header files are giving me lots of spurious warnings but -w will not suppress them not sure why.
>>>>>>>> 
>>>>>>>> Next thing I’ll try is to add a simple C opcode and then call it in the Csound code. I think that may be a simpler
>>>>>>>> way to use the compilation opcode (rather than using the factory).
>>>>>>>> 
>>>>>>>> Anyway, it’s great that you have started this. It leads to interesting experiments.
>>>>>>>> 
>>>>>>>> ========================
>>>>>>>> Prof. Victor Lazzarini
>>>>>>>> Maynooth University
>>>>>>>> Ireland
>>>>>>>> 
>>>>>>>>> On 2 Oct 2021, at 02:12, Michael Gogins  wrote:
>>>>>>>>> 
>>>>>>>>> WARNINGThis email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
>>>>>>>>> I have developed two new plugin opcodes for Csound. They embed the Clang/LLVM just-in-time C++ compiler into Csound, and allow Csound to compile C++ code in the Csound orchestra at run time, and to call code thus compiled, for example as opcodes.
>>>>>>>>> 
>>>>>>>>> These new opcodes, naturally, require both Csound and the full monty of Clang/LLVM, version 13, to be installed.
>>>>>>>>> 
>>>>>>>>> Currently there is a binary build of the opcodes only for Linux.  However, there is only one source code file, and adapting the build script for other operating systems should be straightforward.
>>>>>>>>> 
>>>>>>>>> The opcodes are available at https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgogins%2Fclang-opcodes&data=04%7C01%7CVictor.Lazzarini%40mu.ie%7Cdf47ca974a42467937b608d98cc85abe%7C1454f5ccbb354685bbd98621fd8055c9%7C1%7C0%7C637695614413511441%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9tex3Nt4BH7xKwYsXaMZ1lspxv00WnPxzTSOuuKxhMg%3D&reserved=0. For more information, see the README.md there.
>>>>>>>>> 
>>>>>>>>> I will demonstrate and discuss these opcodes in the upcoming International Csound Users Group virtual meeting on Zoom this coming Wednesday:
>>>>>>>>> 
>>>>>>>>> Topic: International Csound Users Group
>>>>>>>>> Time: Oct 6, 2021 01:30 PM Eastern Time (US and Canada)
>>>>>>>>> 
>>>>>>>>> Join Zoom Meeting
>>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fus02web.zoom.us%2Fj%2F84354088766%3Fpwd%3DektPSkpXeFQrUlZYUFM4cVNPMU01QT09&data=04%7C01%7CVictor.Lazzarini%40mu.ie%7Cdf47ca974a42467937b608d98cc85abe%7C1454f5ccbb354685bbd98621fd8055c9%7C1%7C0%7C637695614413511441%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=H1nfoy06uovBaeyNi%2BzqxwLkXxS4Yra8XL7jmSwLMkY%3D&reserved=0
>>>>>>>>> 
>>>>>>>>> Meeting ID: 843 5408 8766
>>>>>>>>> Passcode: 630670
>>>>>>>>> 
>>>>>>>>> Regards,
>>>>>>>>> Mike
>>>>>>>>> 
>>>>>>>>> -----------------------------------------------------
>>>>>>>>> Michael Gogins
>>>>>>>>> Irreducible Productions
>>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmichaelgogins.tumblr.com%2F&data=04%7C01%7CVictor.Lazzarini%40mu.ie%7Cdf47ca974a42467937b608d98cc85abe%7C1454f5ccbb354685bbd98621fd8055c9%7C1%7C0%7C637695614413511441%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=jghKzaoFVgTRw2%2FhYFCsQaonpdxp8vWnoY%2B6ncR71Jw%3D&reserved=0
>>>>>>>>> Michael dot Gogins at gmail dot com
>>>>>>>> 
>>>>>>> 
>>>>> 
>>>> 
>> 

I’ve settled on “module compiler” as it may be used to add other things including callbacks and
function tables.
========================
Prof. Victor Lazzarini
Maynooth University
Ireland

> On 11 Oct 2021, at 16:23, Victor Lazzarini  wrote:
> 
> You see you can’t add the new opcode in your initial csound code because that’s not there and
> it will fail. Once it’s compiled then you can send in an instrument that will use it, so I think callbacks
> are just complicating the issue.
> 
> If you add a call to compilestr following the addition of the opcode, then it will work (as in the example).
> The JIT will take any amount of C code you want to throw at it. So as many opcodes as you’d like.
> 
> Compile opcodes sounds better alright. I’ll see about changing it.
> ========================
> Prof. Victor Lazzarini
> Maynooth University
> Ireland
> 
>> On 11 Oct 2021, at 16:03, Rory Walsh  wrote:
>> 
>> Ah yes, the less dependencies the better. I couldn't agree more with
>> this statement! So once you call compile_opcode(), any subsequent orc
>> compiles will have access to the new custom opcode. Could this be
>> out-sourced to the frontend? For example, could the opcode_compile()
>> opcode trigger a callback that can be set via the API. When it is
>> triggered the frontend could recompile the same orc, only this time
>> ignoring the opcode_compile() call? Also, does this handle multiple
>> opcodes with a single call? If not, I think it should. And if so, now
>> might be a good time to name it compile_opcodes()..? This seems more
>> consistent with other opcodes, i.e, compileorc, compilecsd, etc.
>> 
>> On Mon, 11 Oct 2021 at 15:34, Victor Lazzarini  wrote:
>>> 
>>> yes, it’s not ideal. The issue is that when the JIT is run, Csound is already running and the Csound code has already
>>> been compiled.
>>> 
>>> If we use a plugin to deploy the JIT as we are doing now, then there is no way round this. An alternative is to build the
>>> JIT inside Csound and use a CSD section for plugins. However that means a big dependency being brought into Csound,
>>> which is not ideal. However, we can make it an optional feature. In any case, that would be a CS7 thing.
>>> 
>>> One snag with this is that at the moment, the JIT needs a set of system headers that get include when we add
>>> csdl.h. That’s not ideal, we should be able to just require Csound-provided headers. I think it is possible to fix this,
>>> but we will need to be careful where we place headers in the Csound code. At the moment, since we never needed to
>>> watch out for this, they are all over the place. I managed to move stdio.h so it’s only included where it is needed, but there
>>> are a number of other headers.
>>> 
>>> So there’s a lot of experimentation ahead.
>>> ========================
>>> Prof. Victor Lazzarini
>>> Maynooth University
>>> Ireland
>>> 
>>>> On 11 Oct 2021, at 14:15, Rory Walsh  wrote:
>>>> 
>>>> I like the look of this a lot guys. Thanks for spending time on it.
>>>> Victor, in your example you create an orchestra and pass it to
>>>> compilestr(). I understand you need to recompile to have the opcode
>>>> available. This seems a little clunky. Don't get me wrong, this is
>>>> awesome, but is there any way the opcode_compile() call could also
>>>> recompile, or rerun the orc without the user having to do so? Or could
>>>> these opcodes be placed in a unique  section where the
>>>> opcodes parsed could be appended to the list of copcodes before Csound
>>>> runs?
>>>> 
>>>> 
>>>> On Mon, 11 Oct 2021 at 13:57, Victor Lazzarini  wrote:
>>>>> 
>>>>> Thanks, I’ll have a go as soon as I can get round to.
>>>>> In the meanwhile, I have been studying your code and the clang llvm interpreter example and I put together a simplified version of the opcode just designed to compile new opcodes (without dependencies). This currently supports C opcodes only, but I’ll look at adding C++ support later.
>>>>> 
>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fvlazzarini%2Fopcode_compiler&data=04%7C01%7CVictor.Lazzarini%40mu.ie%7Ce90057231104491909da08d98ccb14b1%7C1454f5ccbb354685bbd98621fd8055c9%7C1%7C0%7C637695626126269396%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5LwVSbVubhWzMNHr%2FD8ZLk2xFKEB1RhfeHknrRWQwXA%3D&reserved=0
>>>>> 
>>>>> The idea is to use this as a platform for exploring how to compile UDOs down to fast LLVM code. UDOs (without any opcode
>>>>> calls to start with) would be parsed to a csound C opcode and then given to the JIT compiler.
>>>>> ========================
>>>>> Prof. Victor Lazzarini
>>>>> Maynooth University
>>>>> Ireland
>>>>>> On 10 Oct 2021, at 03:00, Michael Gogins  wrote:
>>>>>> 
>>>>>> I think I have fixed the crash on exit. In git now.
>>>>>> 
>>>>>> On Sat, Oct 9, 2021, 18:15 Michael Gogins  wrote:
>>>>>> Thanks for the fix. I tried this approach myself and it didn't work, which is why I created the ClangInvokable thing, and I suspect it's also why the Faust team used a similar approach.
>>>>>> 
>>>>>> If your fix has been committed, I'll try this myself, in most cases this would be a better way.
>>>>>> 
>>>>>> I think I have a fix for the crash on exit, I'll let you know soon.
>>>>>> 
>>>>>> Regards,
>>>>>> Mike
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On Sat, Oct 9, 2021, 17:11 Victor Lazzarini  wrote:
>>>>>> After fixing a bug in Csound, I am now able to use your JIT compiler opcode to add a new opcode and run it.
>>>>>> The main difference with the factory/clang_invokable method is that since the opcode is added by the Csound
>>>>>> orchestra code, you can only use it in a subsequent compilation.
>>>>>> 
>>>>>> Here’s the CSD example (with MacOS compile flags)
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> -odac --opcode-lib="./clang_opcodes.dylib"
>>>>>> 
>>>>>> 
>>>>>> 0dbfs = 1
>>>>>> 
>>>>>> SCode = {{
>>>>>> #include 
>>>>>> struct DATASPACE {
>>>>>>  OPDS h;
>>>>>>  MYFLT *out, *in, *gain;
>>>>>> };
>>>>>> 
>>>>>> static int init(CSOUND *csound, DATASPACE *p) {
>>>>>>     return OK;
>>>>>> }
>>>>>> 
>>>>>> static int perf(CSOUND *csound, DATASPACE *p) {
>>>>>>  MYFLT *out = p->out, *in = p->in, g = *p->gain;
>>>>>>  uint32_t offset = p->h.insdshead->ksmps_offset;
>>>>>>  uint32_t early  = p->h.insdshead->ksmps_no_end;
>>>>>>  uint32_t n, nsmps = CS_KSMPS;
>>>>>> 
>>>>>>  if (UNLIKELY(offset)) memset(out,0, offset*sizeof(MYFLT));
>>>>>>  if (UNLIKELY(early)) {
>>>>>>    nsmps -= early;
>>>>>>    memset(&out[nsmps],0, early*sizeof(MYFLT));
>>>>>>  }
>>>>>> 
>>>>>>  for(n=offset; n < nsmps; n++) out[n] = in[n]*g;
>>>>>>  return OK;
>>>>>> }
>>>>>> 
>>>>>> void* __dso_handle = (void *)&__dso_handle;
>>>>>> extern "C" int csound_main(CSOUND *csound) {
>>>>>>  csound->AppendOpcode(csound, "amp",sizeof(DATASPACE),0,3,"a","ak",
>>>>>>                       (SUBR) init, (SUBR) perf, NULL);
>>>>>>  return 0;
>>>>>> };
>>>>>> }}
>>>>>> 
>>>>>> SCscode = {{
>>>>>>  instr 1
>>>>>>   a1 oscili 1,440
>>>>>>   a2 amp a1, 0.5
>>>>>>   out a2
>>>>>>  endin
>>>>>> }}
>>>>>> 
>>>>>> SCflags =  "-DTARGET_OS_OSX -DTARGET_OS_IPHONE -I/Users/victor/Library/Frameworks/CsoundLib64.framework/Headers -I/usr/local/lib/clang/13.0.0/include/ -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/"
>>>>>> SLflags = ""
>>>>>> 
>>>>>> ires clang_compile "csound_main", SCode, SCflags, SLflags
>>>>>> ires compilestr SCscode
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> i1 0 2
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> ========================
>>>>>> Prof. Victor Lazzarini
>>>>>> Maynooth University
>>>>>> Ireland
>>>>>> 
>>>>>>> On 9 Oct 2021, at 17:50, Victor Lazzarini  wrote:
>>>>>>> 
>>>>>>> Ok, I'll carry on experimenting and report back.
>>>>>>> 
>>>>>>> Prof. Victor Lazzarini
>>>>>>> Maynooth University
>>>>>>> Ireland
>>>>>>> 
>>>>>>>> On 9 Oct 2021, at 15:37, Michael Gogins  wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Some of my pieces get a similar crash at the end on Ubuntu. Others do not crash.
>>>>>>>> 
>>>>>>>> Everything is working until Csound is finished performing and begins to exit.
>>>>>>>> 
>>>>>>>> In other words it is working the same for you as for me and seems quite usable.
>>>>>>>> 
>>>>>>>> I will debug this. Your error messages are helpful.
>>>>>>>> 
>>>>>>>> Regards,
>>>>>>>> Mike
>>>>>>>> 
>>>>>>>> On Sat, Oct 9, 2021, 10:24 Victor Lazzarini  wrote:
>>>>>>>> Ok, giving it the libc++ and C++ header location, I get
>>>>>>>> 
>>>>>>>> ####### clang_compile: invoking "csound_main" at 0x104837000:
>>>>>>>>>>>>>>> Hello, world! This proves csound_main has been called with csound: 0x7fdc5ef00000.
>>>>>>>>>>>>>>> This proves a lot of libstdc++ stuff works: strings.size(): 1 strings[0]: A test string...
>>>>>>>>>>>>>>> Now that we have manually defined our own __dso_handle, this proves std::cerr works as well!
>>>>>>>> ####### clang_compile: "csound_main" returned: 0
>>>>>>>> ******* Trying to invoke Hello...
>>>>>>>> ####### clang_invoke::init: factory name: "hello_factory"
>>>>>>>> ####### clang_invoke::init: factory function: 0x1048373e0
>>>>>>>>>>>>>>> hello_factory created: 0x7fdc5ecfb850
>>>>>>>> ####### clang_invoke::init: instance: 0x7fdc5ecfb850 thread: 0
>>>>>>>>>>>>>>> This proves clang_invoke has called into this module.
>>>>>>>> ####### clang_invoke::init: invokable::init: result: 0
>>>>>>>> ******* clang_invoke returned: ">>>>>>> This proves clang_invoke can be used as an opcode that returns a string and multiplies a number by 2." and 4
>>>>>>>> 
>>>>>>>> csound command: Segmentation fault
>>>>>>>> ####### clang_compile: deleting JITCompiler 0x7fdc6049a400 and ending execution session.
>>>>>>>> deativate: ip, nxt = 0x7fdc5fbab020 , 0x0
>>>>>>>> ####### clang_invoke::noteoff
>>>>>>>> 
>>>>>>>> So it runs but then it crashes. The debugger says
>>>>>>>> 
>>>>>>>> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x380)
>>>>>>>> frame #0: 0x0000000102bde3b1 clang_opcodes.dylib`llvm::orc::JITCompiler::getSymbolAddress(llvm::StringRef const&) [inlined] llvm::orc::JITCompiler::findSymbol(this=0x0000000000000000, name=0x00007ffeefbff2a8) at clang_opcodes.cpp:178:43 [opt]
>>>>>>>> 175      Expected findSymbol(const StringRef &name)
>>>>>>>> 176      {
>>>>>>>> 177          return execution_session.lookup({&main_jit_dylib}, Mangle(name));
>>>>>>>> -> 178      }
>>>>>>>> 179      Expected getSymbolAddress(const StringRef &name)
>>>>>>>> 180      {
>>>>>>>> 181          auto symbol = findSymbol(name);
>>>>>>>> 
>>>>>>>> 
>>>>>>>> ========================
>>>>>>>> Prof. Victor Lazzarini
>>>>>>>> Maynooth University
>>>>>>>> Ireland
>>>>>>>> 
>>>>>>>>> On 8 Oct 2021, at 23:32, Michael Gogins  wrote:
>>>>>>>>> 
>>>>>>>>> If you mean the clang libs use find. If some are missing install the missing features of clang.
>>>>>>>>> 
>>>>>>>>> On Fri, Oct 8, 2021, 18:29 Michael Gogins  wrote:
>>>>>>>>> Run ldd on existing opcodes to find the libs.
>>>>>>>>> 
>>>>>>>>> On Fri, Oct 8, 2021, 17:40 Victor Lazzarini  wrote:
>>>>>>>>> I’ve managed to build the opcodes and run a simple C code on MacOS by adapting your scripts and CSD.
>>>>>>>>> 
>>>>>>>>> I have not tried yet your factory example because I have to find where the C++ libs etc are to pass to the linker.
>>>>>>>>> First attempt led to segfault but that was probably because of these missing libs.
>>>>>>>>> 
>>>>>>>>> Some system header files are giving me lots of spurious warnings but -w will not suppress them not sure why.
>>>>>>>>> 
>>>>>>>>> Next thing I’ll try is to add a simple C opcode and then call it in the Csound code. I think that may be a simpler
>>>>>>>>> way to use the compilation opcode (rather than using the factory).
>>>>>>>>> 
>>>>>>>>> Anyway, it’s great that you have started this. It leads to interesting experiments.
>>>>>>>>> 
>>>>>>>>> ========================
>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>> Maynooth University
>>>>>>>>> Ireland
>>>>>>>>> 
>>>>>>>>>> On 2 Oct 2021, at 02:12, Michael Gogins  wrote:
>>>>>>>>>> 
>>>>>>>>>> WARNINGThis email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
>>>>>>>>>> I have developed two new plugin opcodes for Csound. They embed the Clang/LLVM just-in-time C++ compiler into Csound, and allow Csound to compile C++ code in the Csound orchestra at run time, and to call code thus compiled, for example as opcodes.
>>>>>>>>>> 
>>>>>>>>>> These new opcodes, naturally, require both Csound and the full monty of Clang/LLVM, version 13, to be installed.
>>>>>>>>>> 
>>>>>>>>>> Currently there is a binary build of the opcodes only for Linux.  However, there is only one source code file, and adapting the build script for other operating systems should be straightforward.
>>>>>>>>>> 
>>>>>>>>>> The opcodes are available at https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgogins%2Fclang-opcodes&data=04%7C01%7CVictor.Lazzarini%40mu.ie%7Ce90057231104491909da08d98ccb14b1%7C1454f5ccbb354685bbd98621fd8055c9%7C1%7C0%7C637695626126269396%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=w7RvjGaT4BJc6URhGMP0S8XhcHO5psQ9Zbh49MPIyKM%3D&reserved=0. For more information, see the README.md there.
>>>>>>>>>> 
>>>>>>>>>> I will demonstrate and discuss these opcodes in the upcoming International Csound Users Group virtual meeting on Zoom this coming Wednesday:
>>>>>>>>>> 
>>>>>>>>>> Topic: International Csound Users Group
>>>>>>>>>> Time: Oct 6, 2021 01:30 PM Eastern Time (US and Canada)
>>>>>>>>>> 
>>>>>>>>>> Join Zoom Meeting
>>>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fus02web.zoom.us%2Fj%2F84354088766%3Fpwd%3DektPSkpXeFQrUlZYUFM4cVNPMU01QT09&data=04%7C01%7CVictor.Lazzarini%40mu.ie%7Ce90057231104491909da08d98ccb14b1%7C1454f5ccbb354685bbd98621fd8055c9%7C1%7C0%7C637695626126269396%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4R0EqOPqBXr%2FThOWrqrw5kVwaMxv5rDpzbecPtnjJ1g%3D&reserved=0
>>>>>>>>>> 
>>>>>>>>>> Meeting ID: 843 5408 8766
>>>>>>>>>> Passcode: 630670
>>>>>>>>>> 
>>>>>>>>>> Regards,
>>>>>>>>>> Mike
>>>>>>>>>> 
>>>>>>>>>> -----------------------------------------------------
>>>>>>>>>> Michael Gogins
>>>>>>>>>> Irreducible Productions
>>>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmichaelgogins.tumblr.com%2F&data=04%7C01%7CVictor.Lazzarini%40mu.ie%7Ce90057231104491909da08d98ccb14b1%7C1454f5ccbb354685bbd98621fd8055c9%7C1%7C0%7C637695626126269396%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=wHs1Npu%2B1l7wCvkq1b%2Fdx2oxqXOz1U2RJ6w04gM4VfY%3D&reserved=0
>>>>>>>>>> Michael dot Gogins at gmail dot com
>>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>>> 
>>> 
> 



I can't convince you to put "compile" at the start, to make it consistent with other opcodes?

On Mon 11 Oct 2021, 4:41 p.m. Victor Lazzarini, <Victor.Lazzarini@mu.ie> wrote:

I’ve settled on “module compiler” as it may be used to add other things including callbacks and
function tables.
========================
Prof. Victor Lazzarini
Maynooth University
Ireland

> On 11 Oct 2021, at 16:23, Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:
>
> You see you can’t add the new opcode in your initial csound code because that’s not there and
> it will fail. Once it’s compiled then you can send in an instrument that will use it, so I think callbacks
> are just complicating the issue.
>
> If you add a call to compilestr following the addition of the opcode, then it will work (as in the example).
> The JIT will take any amount of C code you want to throw at it. So as many opcodes as you’d like.
>
> Compile opcodes sounds better alright. I’ll see about changing it.
> ========================
> Prof. Victor Lazzarini
> Maynooth University
> Ireland
>
>> On 11 Oct 2021, at 16:03, Rory Walsh <rorywalsh@ear.ie> wrote:
>>
>> Ah yes, the less dependencies the better. I couldn't agree more with
>> this statement! So once you call compile_opcode(), any subsequent orc
>> compiles will have access to the new custom opcode. Could this be
>> out-sourced to the frontend? For example, could the opcode_compile()
>> opcode trigger a callback that can be set via the API. When it is
>> triggered the frontend could recompile the same orc, only this time
>> ignoring the opcode_compile() call? Also, does this handle multiple
>> opcodes with a single call? If not, I think it should. And if so, now
>> might be a good time to name it compile_opcodes()..? This seems more
>> consistent with other opcodes, i.e, compileorc, compilecsd, etc.
>>
>> On Mon, 11 Oct 2021 at 15:34, Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:
>>>
>>> yes, it’s not ideal. The issue is that when the JIT is run, Csound is already running and the Csound code has already
>>> been compiled.
>>>
>>> If we use a plugin to deploy the JIT as we are doing now, then there is no way round this. An alternative is to build the
>>> JIT inside Csound and use a CSD section for plugins. However that means a big dependency being brought into Csound,
>>> which is not ideal. However, we can make it an optional feature. In any case, that would be a CS7 thing.
>>>
>>> One snag with this is that at the moment, the JIT needs a set of system headers that get include when we add
>>> csdl.h. That’s not ideal, we should be able to just require Csound-provided headers. I think it is possible to fix this,
>>> but we will need to be careful where we place headers in the Csound code. At the moment, since we never needed to
>>> watch out for this, they are all over the place. I managed to move stdio.h so it’s only included where it is needed, but there
>>> are a number of other headers.
>>>
>>> So there’s a lot of experimentation ahead.
>>> ========================
>>> Prof. Victor Lazzarini
>>> Maynooth University
>>> Ireland
>>>
>>>> On 11 Oct 2021, at 14:15, Rory Walsh <rorywalsh@ear.ie> wrote:
>>>>
>>>> I like the look of this a lot guys. Thanks for spending time on it.
>>>> Victor, in your example you create an orchestra and pass it to
>>>> compilestr(). I understand you need to recompile to have the opcode
>>>> available. This seems a little clunky. Don't get me wrong, this is
>>>> awesome, but is there any way the opcode_compile() call could also
>>>> recompile, or rerun the orc without the user having to do so? Or could
>>>> these opcodes be placed in a unique <CsOpcodes> section where the
>>>> opcodes parsed could be appended to the list of copcodes before Csound
>>>> runs?
>>>>
>>>>
>>>> On Mon, 11 Oct 2021 at 13:57, Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:
>>>>>
>>>>> Thanks, I’ll have a go as soon as I can get round to.
>>>>> In the meanwhile, I have been studying your code and the clang llvm interpreter example and I put together a simplified version of the opcode just designed to compile new opcodes (without dependencies). This currently supports C opcodes only, but I’ll look at adding C++ support later.
>>>>>
>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fvlazzarini%2Fopcode_compiler&amp;data=04%7C01%7CVictor.Lazzarini%40mu.ie%7Ce90057231104491909da08d98ccb14b1%7C1454f5ccbb354685bbd98621fd8055c9%7C1%7C0%7C637695626126269396%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=5LwVSbVubhWzMNHr%2FD8ZLk2xFKEB1RhfeHknrRWQwXA%3D&amp;reserved=0
>>>>>
>>>>> The idea is to use this as a platform for exploring how to compile UDOs down to fast LLVM code. UDOs (without any opcode
>>>>> calls to start with) would be parsed to a csound C opcode and then given to the JIT compiler.
>>>>> ========================
>>>>> Prof. Victor Lazzarini
>>>>> Maynooth University
>>>>> Ireland
>>>>>> On 10 Oct 2021, at 03:00, Michael Gogins <michael.gogins@gmail.com> wrote:
>>>>>>
>>>>>> I think I have fixed the crash on exit. In git now.
>>>>>>
>>>>>> On Sat, Oct 9, 2021, 18:15 Michael Gogins <michael.gogins@gmail.com> wrote:
>>>>>> Thanks for the fix. I tried this approach myself and it didn't work, which is why I created the ClangInvokable thing, and I suspect it's also why the Faust team used a similar approach.
>>>>>>
>>>>>> If your fix has been committed, I'll try this myself, in most cases this would be a better way.
>>>>>>
>>>>>> I think I have a fix for the crash on exit, I'll let you know soon.
>>>>>>
>>>>>> Regards,
>>>>>> Mike
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sat, Oct 9, 2021, 17:11 Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:
>>>>>> After fixing a bug in Csound, I am now able to use your JIT compiler opcode to add a new opcode and run it.
>>>>>> The main difference with the factory/clang_invokable method is that since the opcode is added by the Csound
>>>>>> orchestra code, you can only use it in a subsequent compilation.
>>>>>>
>>>>>> Here’s the CSD example (with MacOS compile flags)
>>>>>>
>>>>>> <CsoundSyntheizer>
>>>>>> <CsOptions>
>>>>>> -odac --opcode-lib="./clang_opcodes.dylib"
>>>>>> </CsOptions>
>>>>>> <CsInstruments>
>>>>>> 0dbfs = 1
>>>>>>
>>>>>> SCode = {{
>>>>>> #include <csdl.h>
>>>>>> struct DATASPACE {
>>>>>>  OPDS h;
>>>>>>  MYFLT *out, *in, *gain;
>>>>>> };
>>>>>>
>>>>>> static int init(CSOUND *csound, DATASPACE *p) {
>>>>>>     return OK;
>>>>>> }
>>>>>>
>>>>>> static int perf(CSOUND *csound, DATASPACE *p) {
>>>>>>  MYFLT *out = p->out, *in = p->in, g = *p->gain;
>>>>>>  uint32_t offset = p->h.insdshead->ksmps_offset;
>>>>>>  uint32_t early  = p->h.insdshead->ksmps_no_end;
>>>>>>  uint32_t n, nsmps = CS_KSMPS;
>>>>>>
>>>>>>  if (UNLIKELY(offset)) memset(out,0, offset*sizeof(MYFLT));
>>>>>>  if (UNLIKELY(early)) {
>>>>>>    nsmps -= early;
>>>>>>    memset(&out[nsmps],0, early*sizeof(MYFLT));
>>>>>>  }
>>>>>>
>>>>>>  for(n=offset; n < nsmps; n++) out[n] = in[n]*g;
>>>>>>  return OK;
>>>>>> }
>>>>>>
>>>>>> void* __dso_handle = (void *)&__dso_handle;
>>>>>> extern "C" int csound_main(CSOUND *csound) {
>>>>>>  csound->AppendOpcode(csound, "amp",sizeof(DATASPACE),0,3,"a","ak",
>>>>>>                       (SUBR) init, (SUBR) perf, NULL);
>>>>>>  return 0;
>>>>>> };
>>>>>> }}
>>>>>>
>>>>>> SCscode = {{
>>>>>>  instr 1
>>>>>>   a1 oscili 1,440
>>>>>>   a2 amp a1, 0.5
>>>>>>   out a2
>>>>>>  endin
>>>>>> }}
>>>>>>
>>>>>> SCflags =  "-DTARGET_OS_OSX -DTARGET_OS_IPHONE -I/Users/victor/Library/Frameworks/CsoundLib64.framework/Headers -I/usr/local/lib/clang/13.0.0/include/ -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/"
>>>>>> SLflags = ""
>>>>>>
>>>>>> ires clang_compile "csound_main", SCode, SCflags, SLflags
>>>>>> ires compilestr SCscode
>>>>>>
>>>>>> </CsInstruments>
>>>>>> <CsScore>
>>>>>> i1 0 2
>>>>>> </CsScore>
>>>>>> </CsoundSynthesizer>
>>>>>>
>>>>>>
>>>>>> ========================
>>>>>> Prof. Victor Lazzarini
>>>>>> Maynooth University
>>>>>> Ireland
>>>>>>
>>>>>>> On 9 Oct 2021, at 17:50, Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:
>>>>>>>
>>>>>>> Ok, I'll carry on experimenting and report back.
>>>>>>>
>>>>>>> Prof. Victor Lazzarini
>>>>>>> Maynooth University
>>>>>>> Ireland
>>>>>>>
>>>>>>>> On 9 Oct 2021, at 15:37, Michael Gogins <michael.gogins@gmail.com> wrote:
>>>>>>>>
>>>>>>>> 
>>>>>>>> Some of my pieces get a similar crash at the end on Ubuntu. Others do not crash.
>>>>>>>>
>>>>>>>> Everything is working until Csound is finished performing and begins to exit.
>>>>>>>>
>>>>>>>> In other words it is working the same for you as for me and seems quite usable.
>>>>>>>>
>>>>>>>> I will debug this. Your error messages are helpful.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Mike
>>>>>>>>
>>>>>>>> On Sat, Oct 9, 2021, 10:24 Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:
>>>>>>>> Ok, giving it the libc++ and C++ header location, I get
>>>>>>>>
>>>>>>>> ####### clang_compile: invoking "csound_main" at 0x104837000:
>>>>>>>>>>>>>>> Hello, world! This proves csound_main has been called with csound: 0x7fdc5ef00000.
>>>>>>>>>>>>>>> This proves a lot of libstdc++ stuff works: strings.size(): 1 strings[0]: A test string...
>>>>>>>>>>>>>>> Now that we have manually defined our own __dso_handle, this proves std::cerr works as well!
>>>>>>>> ####### clang_compile: "csound_main" returned: 0
>>>>>>>> ******* Trying to invoke Hello...
>>>>>>>> ####### clang_invoke::init: factory name: "hello_factory"
>>>>>>>> ####### clang_invoke::init: factory function: 0x1048373e0
>>>>>>>>>>>>>>> hello_factory created: 0x7fdc5ecfb850
>>>>>>>> ####### clang_invoke::init: instance: 0x7fdc5ecfb850 thread: 0
>>>>>>>>>>>>>>> This proves clang_invoke has called into this module.
>>>>>>>> ####### clang_invoke::init: invokable::init: result: 0
>>>>>>>> ******* clang_invoke returned: ">>>>>>> This proves clang_invoke can be used as an opcode that returns a string and multiplies a number by 2." and 4
>>>>>>>>
>>>>>>>> csound command: Segmentation fault
>>>>>>>> ####### clang_compile: deleting JITCompiler 0x7fdc6049a400 and ending execution session.
>>>>>>>> deativate: ip, nxt = 0x7fdc5fbab020 , 0x0
>>>>>>>> ####### clang_invoke::noteoff
>>>>>>>>
>>>>>>>> So it runs but then it crashes. The debugger says
>>>>>>>>
>>>>>>>> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x380)
>>>>>>>> frame #0: 0x0000000102bde3b1 clang_opcodes.dylib`llvm::orc::JITCompiler::getSymbolAddress(llvm::StringRef const&) [inlined] llvm::orc::JITCompiler::findSymbol(this=0x0000000000000000, name=0x00007ffeefbff2a8) at clang_opcodes.cpp:178:43 [opt]
>>>>>>>> 175      Expected<JITEvaluatedSymbol> findSymbol(const StringRef &name)
>>>>>>>> 176      {
>>>>>>>> 177          return execution_session.lookup({&main_jit_dylib}, Mangle(name));
>>>>>>>> -> 178      }
>>>>>>>> 179      Expected<JITTargetAddress> getSymbolAddress(const StringRef &name)
>>>>>>>> 180      {
>>>>>>>> 181          auto symbol = findSymbol(name);
>>>>>>>>
>>>>>>>>
>>>>>>>> ========================
>>>>>>>> Prof. Victor Lazzarini
>>>>>>>> Maynooth University
>>>>>>>> Ireland
>>>>>>>>
>>>>>>>>> On 8 Oct 2021, at 23:32, Michael Gogins <michael.gogins@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> If you mean the clang libs use find. If some are missing install the missing features of clang.
>>>>>>>>>
>>>>>>>>> On Fri, Oct 8, 2021, 18:29 Michael Gogins <michael.gogins@gmail.com> wrote:
>>>>>>>>> Run ldd on existing opcodes to find the libs.
>>>>>>>>>
>>>>>>>>> On Fri, Oct 8, 2021, 17:40 Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:
>>>>>>>>> I’ve managed to build the opcodes and run a simple C code on MacOS by adapting your scripts and CSD.
>>>>>>>>>
>>>>>>>>> I have not tried yet your factory example because I have to find where the C++ libs etc are to pass to the linker.
>>>>>>>>> First attempt led to segfault but that was probably because of these missing libs.
>>>>>>>>>
>>>>>>>>> Some system header files are giving me lots of spurious warnings but -w will not suppress them not sure why.
>>>>>>>>>
>>>>>>>>> Next thing I’ll try is to add a simple C opcode and then call it in the Csound code. I think that may be a simpler
>>>>>>>>> way to use the compilation opcode (rather than using the factory).
>>>>>>>>>
>>>>>>>>> Anyway, it’s great that you have started this. It leads to interesting experiments.
>>>>>>>>>
>>>>>>>>> ========================
>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>> Maynooth University
>>>>>>>>> Ireland
>>>>>>>>>
>>>>>>>>>> On 2 Oct 2021, at 02:12, Michael Gogins <michael.gogins@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>> WARNINGThis email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
>>>>>>>>>> I have developed two new plugin opcodes for Csound. They embed the Clang/LLVM just-in-time C++ compiler into Csound, and allow Csound to compile C++ code in the Csound orchestra at run time, and to call code thus compiled, for example as opcodes.
>>>>>>>>>>
>>>>>>>>>> These new opcodes, naturally, require both Csound and the full monty of Clang/LLVM, version 13, to be installed.
>>>>>>>>>>
>>>>>>>>>> Currently there is a binary build of the opcodes only for Linux.  However, there is only one source code file, and adapting the build script for other operating systems should be straightforward.
>>>>>>>>>>
>>>>>>>>>> The opcodes are available at https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgogins%2Fclang-opcodes&amp;data=04%7C01%7CVictor.Lazzarini%40mu.ie%7Ce90057231104491909da08d98ccb14b1%7C1454f5ccbb354685bbd98621fd8055c9%7C1%7C0%7C637695626126269396%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=w7RvjGaT4BJc6URhGMP0S8XhcHO5psQ9Zbh49MPIyKM%3D&amp;reserved=0. For more information, see the README.md there.
>>>>>>>>>>
>>>>>>>>>> I will demonstrate and discuss these opcodes in the upcoming International Csound Users Group virtual meeting on Zoom this coming Wednesday:
>>>>>>>>>>
>>>>>>>>>> Topic: International Csound Users Group
>>>>>>>>>> Time: Oct 6, 2021 01:30 PM Eastern Time (US and Canada)
>>>>>>>>>>
>>>>>>>>>> Join Zoom Meeting
>>>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fus02web.zoom.us%2Fj%2F84354088766%3Fpwd%3DektPSkpXeFQrUlZYUFM4cVNPMU01QT09&amp;data=04%7C01%7CVictor.Lazzarini%40mu.ie%7Ce90057231104491909da08d98ccb14b1%7C1454f5ccbb354685bbd98621fd8055c9%7C1%7C0%7C637695626126269396%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=4R0EqOPqBXr%2FThOWrqrw5kVwaMxv5rDpzbecPtnjJ1g%3D&amp;reserved=0
>>>>>>>>>>
>>>>>>>>>> Meeting ID: 843 5408 8766
>>>>>>>>>> Passcode: 630670
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Mike
>>>>>>>>>>
>>>>>>>>>> -----------------------------------------------------
>>>>>>>>>> Michael Gogins
>>>>>>>>>> Irreducible Productions
>>>>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmichaelgogins.tumblr.com%2F&amp;data=04%7C01%7CVictor.Lazzarini%40mu.ie%7Ce90057231104491909da08d98ccb14b1%7C1454f5ccbb354685bbd98621fd8055c9%7C1%7C0%7C637695626126269396%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=wHs1Npu%2B1l7wCvkq1b%2Fdx2oxqXOz1U2RJ6w04gM4VfY%3D&amp;reserved=0
>>>>>>>>>> Michael dot Gogins at gmail dot com
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>
>