[PD-dev] [PD] more about float limitation
katjavetter at gmail.com
Wed Feb 4 11:56:48 CET 2015
Sorry IOhannes, my previous mail was sent right before your
explanation saying where I got it wrong. So please ignore it.
On Wed, Feb 4, 2015 at 11:51 AM, IOhannes m zmoelnig <zmoelnig at iem.at> 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
> 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
> ** 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.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> -----END PGP SIGNATURE-----
> Pd-dev mailing list
> Pd-dev at lists.iem.at
More information about the Pd-dev