plugin - Page 1

Pollux :
plus if you want to support any number of external plugins, out-of-the-box nostub dlls aren't going to work either... (this is so to prevent developers from having ideas such as yours )

in my opinion kernel mode would be far simpler, except if you intend to develop a whole dll framework for nostub ^^

hibOu
: you think that my ideas are crazy ? (as you smiley suggests)

Pollux
:

hibOu
: you think that my ideas are crazy ? (as you smiley suggests)

No, my smiley was targetted at the not-so-anynomous TIGCC maintainer who wants to prevent programmers from implementing a plugin system just because he thinks it's a bad idea

Of course I, for one, think it's a good idea (though I doubt of the efficiency of the SVG format itself: XML was not designed to be compact or efficient, it was designed to be human-readable; thus it would be a good idea to at least use a different encoding for XML, or even switch to a binary, space-efficient format such as Flash -- IIRC it is a documented standard, much like PDF, so it might be worth considering )

spectras :
Well typically you will want to define a set of mandatory function to be exported by a dynamic library
For instance, you define that a valid plugin is a dynamic library that exports a function with the prototype int init_hibview_plugin(.....)

Then, all you have to do to load a plugin is :
- load the library
- locate the init_hibview_plugin function (as it is exported this should be quite easy)
- call the function, giving it all the parameters it may need to be fully functionnal (for instance this could be the address of a table of recognized formats into which the plugin could add itself). You may allow the plugin access to internal functions of the main program, though doing so makes future program evolution more difficult (plugin incompatibility).
- check that the plugin does not fail its initialization

Well that's a bit rough, but the main idea is here. If you want I will work on a fully grown example (I'm working on a set of ti-89 programming examples, and this would be a good candidate), but right now I have to leave so I do not miss an appointment.

- as I can "transmit" pointers on datas from the main code to the plugin (and the reverse), can I transmit pointers of function and execute them ? (I don't think I need it, but I'm curious)

- can I load several libraries ? if yes, are the function namespace separated ? (there won't be confusion between the init_plugin function form the svg plugin and the init_plugin function from the fash plugin (just a example ))

/* assumes library foo has a  void myfunction(char * message) */
loadlibrary("foo");
myfunction("hello");

typedef void (*myfunction_type)(char * message);

foohandle = loadlibrary("foo");
myfunction_address = (myfunction_type) getaddress(foohandle, "myfunction");
(*myfunction_address)("hello");

- can I call a library from a library ?

examples are always welcomed

spectras
:

- can I load several libraries ? if yes, are the function namespace separated ? (there won't be confusion between the init_plugin function form the svg plugin and the init_plugin function from the fash plugin (just a example ))

Yes you can. And there is no such thing as namespace confusion since dynamically loaded libraries functions cannot be directly referred to in your code. That is you cannot write

/* assumes library foo has a  void myfunction(char * message) */
loadlibrary("foo");
myfunction("hello");

This would create either a linking error or a load-time symbol resolution, neither of which is what you want.

Instead you would write

typedef void (*myfunction_type)(char * message);

foohandle = loadlibrary("foo");
myfunction_address = (myfunction_type) getaddress(foohandle, "myfunction");
(*myfunction_address)("hello");

This explicitly loads the library, look for the "myfunction" symbol then runs it.

- can I call a library from a library ?

It works on all desktop OS. I guess it also works with kernels such as PreOS, though you should test it or ask PpHd to be sure.

examples are always welcomed

Unfortunately I'm very busy at the moment and that should last until monday. I hope you're not in a hurry if you choose to wait for a working example

Errrh, before you go and try and get a headache about it : the two samples above are only kind of a pseudo code, they are not real function names or anything. If you want to have a look at a fully working example of the concept, this dlopen example does exactly that (it runs on GNU/Linux).

You can. Although if the dynamic linking is done correctly that should not be necessary since the plugin should have access to all the functions of the program (check this, it is true on all desktop OS, but it may not be on ti89; PpHd should know more about this).

typedef void (*myfunction_type)(char * message);
foohandle = loadlibrary("foo");
myfunction_address = (myfunction_type) getaddress(foohandle, "myfunction");
(*myfunction_address)("hello");
This explicitly loads the library, look for the "myfunction" symbol then runs it.

 LibRef *foo = kernel__LibsBegin ("foo", 1); // Load version 1 of library foo
 myfunction = kernel__LibsPtr (foo, 0);   // Function 0 of library foo
 (&myfunction) ("Hello");
 kernel__LibsEnd (foo);

 LibRef *foo = kernel__LibsBegin ("foo", 1); // Load version 1 of library foo
 kernel__LibsCall (foo, 0, "Hello");   // Call Function 0 of library foo
 kernel__LibsEnd (foo);

 kernel__LibsExec ("foo", 1, 0, "Hello"); // Load library, execute function and close library

It works on all desktop OS.

I guess it also works with kernels such as PreOS, though you should test it or ask PpHd to be sure.

PpHd :
Or in Kernel code:

 LibRef *foo = kernel__LibsBegin ("foo", 1); // Load version 1 of library foo
 myfunction = kernel__LibsPtr (foo, 0);   // Function 0 of library foo
 (&myfunction) ("Hello");
 kernel__LibsEnd (foo);

or simpler:

 LibRef *foo = kernel__LibsBegin ("foo", 1); // Load version 1 of library foo
 kernel__LibsCall (foo, 0, "Hello");   // Call Function 0 of library foo
 kernel__LibsEnd (foo);

or even simpler:

 kernel__LibsExec ("foo", 1, 0, "Hello"); // Load library, execute function and close library

BTW, you should pay attention to the argument passing convention. For example, if you wish to use kernel__LibsCall, then your convention *has* to be the stkparm convention.

PpHd :
Not really. It works also with mregparm. The only problem is to declare properly the kernel function to push the 2/3 first arguments on the stack, and the others in the registers, without making tigcc cries.

FMI, are kernel core functions really different from "usual" functions ? The calling conventions of most ExtGraph grayscale functions is a mix of __regparm__ (d0-d3/a0-a1) and __stkparm__ (the rest), and they're defined in a very simple way I never saw TIGCC complaining about.

I don't see what you mean, could you be clearer? Of course I did not mean that your whole program had to be stkparm, just that the function you want to export has to be stkparm. (thanks to __attribute__((stkparm)))

PpHd :
The problem : it is the same function from a C compiler, but with different parameters. So a a declaration with incomplete list of argument is the best solution '...'.

In clear: you can use mregparm, but it will be a nightmare. So use stkparm instead.

It's NOT possible to do so with regparm

void f (const char *name, char version, char num, int toto asm("d0")) asm ("kernel__0000");
void g (const char *name, char version, char num, int *toto asm("a0")) asm ("kernel__0000");

int h(int *name, int toto)
{
  f ("totoland", 1, 0, toto);
  g ("totoland", 1, 1, name);
}

        .globl  h
h:
        link.w %a6,#0
        move.l %a2,-(%sp)
        subq.l #4,%sp
        clr.b 3(%sp)
        move.b #1,1(%sp)
        pea .LC0
        lea kernel__0000,%a2
        move.w 12(%a6),%d0
        jbsr (%a2)
        subq.l #4,%sp
        move.b #1,3(%sp)
        move.b #1,1(%sp)
        pea .LC0
        move.l 8(%a6),%a0
        jbsr (%a2)
        move.l -4(%a6),%a2
        unlk %a6
        rts