Sorry IOhannes, my previous mail was sent right before your explanation saying where I got it wrong. So please ignore it.
Katja On Wed, Feb 4, 2015 at 11:51 AM, IOhannes m zmoelnig <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 2015-02-04 10:57, katja wrote: >> >> To be sure if I understand the idea correctly: the setup method of >> each class is renamed (by the build system, essentially), and >> precision-aware Pd looks for that new name so it loads the code >> for the proper precision. This way you can bundle two versions of a >> class (or lib) in a single executable, one for each precision. The >> setup method of the wrong precision will not be called by Pd. Am I >> right? > > no. we might misunderstand each other. > > the basic idea (without phat binaries) > ==== > > - - Pd only looks for the good olde <name>_setup() function (or it's > hexmunged equivalent). > - - the external registers a new object-class with a precision-aware > callback function (*class_new* for single-precision; *class_new64* for > double precision); class_new64() is used automatically due to a define > in m-pd.h triggered by a double-precision build. > > loading scenarios: > * when an external is loaded, the Pd-runtime calls the external > *setup* function (via *dlopen()*). > > * the external then registers it's objectclasses with the pd-runtime > > ** nothing really changes for a single-precision Pd-runtime (including > a legacy Pd-runtime) loading a single-precision external. > > ** when a double-precision external is loaded by a double-precision > runtime, the objectclasses will be registered via the new callback > "class_new64()". > > ** when a single-precision external is loaded by a double-precision > runtime, it will register the objectclasses via class_new() which is a > noop (probably giving the user a warning about mismatched precisions) > > ** when a double-precision external is loaded by a (new) > single-precision runtime, it will register the objectclasses via > class_new64() which is a noop (probably giving the user a warning > about mismatched precisions) > > ** when a double-precision external is loaded by a legacy > (single-precision) runtime, it would register the objectclasses via > class_new64() which does not exist (and thus the dlopen()ing ofthe > external won't work in the first place) > > > multi-precision libraries (what i call "phat binaries" for lack of a > better work; it's contains both "fat" and "precision") > === > > - - the external's setup()-function calls both class_new() and > class_new64() to register two different specializations of the same > object (i just borrowed the term "specialization" from C++-templates) > > - - a (new) single-precision Pd will discard the class_new64() call, and > thus only *see* the single-precision objectclass. > > - - a (new) double-precision Pd will discard the class_new() call, and > thus only *see* the double-precision objectclass. > > - - a legacy (single-precision) Pd will not be able to load the phat > binary, since the "class_new64" symbol is missing. > > > the last item is obviously a little problem, but that problem always > exists if an external uses a newly introduced function (e.g. using > "logpost()" will make the external unusable on Pd<=0.42) > >> Does it also mean the rest of the wrong-precision code will not be >> loaded? What will happen with unintentionally exported symbols, >> like private functions accidentally not declared static, or >> functions defined in shared files? Compiler-dependent methods exist >> to hide symbols by default. Then, the same approach for renaming >> class setup methods according to precision, might be used to >> explicitly define them as exported symbol. > > good points. > my approach assumed, that the code was written "correctly" ("proper"). > that is: t_float/t_sample is used throughout; *all* functions that > need not be exported are not exported. probably others. > > hiding (aka: not-exporting) symbols by default won't help us much, as > this only works at the dylib boundaries: within the entire phat-binary > the symbols are still visible (so it's different from "static" functions). > > anyhow: my point was mainly, that it should be fairly simple to create > phat binaries of many (simplistic) externals (and i think most > externals fall into this category). > for more complex externals, a lot of manual work might still be involved, > >> >> What would a legacy Pd build do with fat-precision binaries? Could >> we consider single precision the default and not rename the setup >> function compiled for single precision so it will still work with >> legacy Pd? If the extensions are not modified, a user can't see >> whether an external is fat-precision or not. > > see my other (short) mail (and the above explanations): > single-precision externals should continue to use the olde names. > if we want to support phat binaries in legacy runtimes, we probably > should think again (adding an extension will not help us here either). > at least on linux (and most likely on OSX; but more unlikely on W32) > it should be possible to provide a "stub-external", that only exports > the new "class_new64" symbol (as a noop). > having this stub-external loaded, should allow to dlopen() a phat > binary (or a double-precision binary) with the double-precision parts > not doing any harm. > > fgmasdr > IOhannes > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQIcBAEBCAAGBQJU0fnBAAoJELZQGcR/ejb4ZvsQAIq1zomPlsirrBGFE7oVIc1p > qPecDk9zReG1E/wSyU6ntLNasXUAojd44eTo4acijH86RR7n+MRQB5RgAAhmf1mm > ZVesL8R7AoJ1qYkCg8AfkgSkYD+GZWydebfiEHTiWks4fq7amzYWeHk8BENMHCAU > 4f7j2N1bp66E1GQTdhS/dI/Rm39Q/8Ja8M7lrI2nYbQx0WzGBYFV9hMkuYGO96zq > aCNb3+UCMwTUDfWRFnyeGxTystOOB2kuaxPDKivYmpduX7Anfryb/IaypkVBxRoQ > goU2b/FhglKyiNtlQRLqDwbxSgMD84rfwxFnQbGyRA79ZQHEi+riYB0l9ayrO3pM > PwDKcfMIBA09awtWlv+a7uYXrQgK44nZcSoHkvZgGuZmQobEAZIwWKw8VgO+H5Di > D/XoUDmXGPsHnElSc1kSMFwk0jIXZb2QaVQAK3fy4xvAZ+wWbzcPdS5GdF4rw0QR > rXyjXMRY84G+3j+a5X4pByVaR6LFFDGaacnKE8hltdYhFhDhbrH6PQ/jn/UJGAMG > JY+44knoIJQPlnXrWzsn56VnVXet8uE4SG1XSIueSKZpvwVJ42aYmStXZHJygk/r > eQ0EMZ2YzIRbssCux5OYM7Oos/XOT2nSqE6aAFJACMJ2j++pEJUspOZwkC2DJc2I > 31iJOloztJrgoa3z++RI > =ZJt5 > -----END PGP SIGNATURE----- > > _______________________________________________ > Pd-dev mailing list > [email protected] > http://lists.puredata.info/listinfo/pd-dev _______________________________________________ Pd-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
