Ok.  I am also looking at the code for loading GEN routines from plugins
here.

csoundLoadExternal() has:

      /* opcode library */
      m.fn.o.opcode_size =
          (long (*)(void)) csoundGetLibrarySymbol(h, opcode_size_Name);
      if (m.fn.o.opcode_size == NULL)
        goto notPluginErr;
      m.fn.o.opcode_init =
          (OENTRY *(*)(CSOUND *)) csoundGetLibrarySymbol(h,
opcode_init_Name);
      if (m.fn.o.opcode_size() < 0L)
        m.fn.o.fgen_init =
            (NGFENS *(*)(CSOUND *)) csoundGetLibrarySymbol(h,
fgen_init_Name);
      else
        m.fn.o.fgen_init = NULL;

and csoundInitModules() has:

        length = m->fn.o.opcode_size();
        /* deal with fgens if there are any, */
        /* signalled by setting top bit of length */
        if (length < 0L) {
          length &= 0x7FFFFFFFL;    /* Assumes 32 bit */
          if (m->fn.o.fgen_init != NULL) {
            NGFENS  *names = m->fn.o.fgen_init(csound);
            for (i = 0; names[i].name != NULL; i++)
              allocgen(csound, names[i].name, names[i].fn);
          }
        }


The aspect that I really dislike is the setting of the high bit in
opcode_size.  But examining the code here, I do not even see why it is
necessary.

If csoundGetLibrarySymbol(h, fgen_init_Name) returns NULL then there are no
loadable FGENS.  And if it is NULL, then the allocgen() loop will not be
called.  I can see no reason right now for the tests

    if (m.fn.o.opcode_size() < 0L)
and
    if (length < 0L) {
          length &= 0x7FFFFFFFL;

Am I missing something, or can this part of the process be removed?

Thanks.

Anthony Kozar
anthonykozar AT sbcglobal DOT net
http://akozar.spymac.net/



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Anthony Kozar wrote:

> The aspect that I really dislike is the setting of the high bit in
> opcode_size.  But examining the code here, I do not even see why it is
> necessary.
> 
> If csoundGetLibrarySymbol(h, fgen_init_Name) returns NULL then there are no
> loadable FGENS.  And if it is NULL, then the allocgen() loop will not be
> called.  I can see no reason right now for the tests
> 
>     if (m.fn.o.opcode_size() < 0L)
> and
>     if (length < 0L) {
>           length &= 0x7FFFFFFFL;
> 
> Am I missing something, or can this part of the process be removed?

Yes, the checks are not needed for correct functionality (I did not
add them, by the way), although they possibly make plugin loading
slightly faster by reducing the number of symbol lookups. If you do
remove the checks, do not forget to change the macro FLINKAGE in
csdl.h as well, so that it no longer sets the most significant bit.
Alternatively, we could just get rid of fgen_init() completely, and
add a new API function for registering new GEN routines, similarly
to csoundAppendOpcode().


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Istvan Varga wrote on 10/14/05 4:54 AM:

> Yes, the checks are not needed for correct functionality (I did not
> add them, by the way), although they possibly make plugin loading
> slightly faster by reducing the number of symbol lookups. If you do
> remove the checks, do not forget to change the macro FLINKAGE in
> csdl.h as well, so that it no longer sets the most significant bit.

OK.  I think that I will make the changes unless there are any objections.
It will seem a lot cleaner to me to not have opcode_size() returning a
negative number.

> Alternatively, we could just get rid of fgen_init() completely, and
> add a new API function for registering new GEN routines, similarly
> to csoundAppendOpcode().

I really like the simplicity of the opcode_init() / OENTRY method for adding
opcodes -- it makes it so easy to convert opcodes from different Csound 4
code bases without writing any new code.

So I also like the fgen_init() mechanism as an option.  But an API function
for adding new GEN routines would also be very useful for a host
application.  I will look into it if no one else does.

Anthony Kozar
anthonykozar AT sbcglobal DOT net
http://akozar.spymac.net/



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Anthony Kozar wrote:

> I really like the simplicity of the opcode_init() / OENTRY method for adding
> opcodes -- it makes it so easy to convert opcodes from different Csound 4
> code bases without writing any new code.

Though it does have the disadvantage compared to csoundAppendOpcode()
that if OENTRY is changed in any way then the plugins using opcode_init()
would break. Fortunately, OENTRY is not changed frequently.

> So I also like the fgen_init() mechanism as an option.  But an API function
> for adding new GEN routines would also be very useful for a host
> application.  I will look into it if no one else does.

There is already a function that adds a named GEN routine (allocgen)
that - with a few minor changes - could be added to CSOUND; is a name
like csound->AddNamedGen() suitable ? However, it is still only usable
in plugins and not host applications because it depends on some functions
that may possibly call longjmp (examples include the Csound memory
allocators). I am not sure if keeping fgen_init() is really important,
as it is rarely used compared to opcode_init().


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net