[PD-dev] [PD] more about float limitation

IOhannes m zmoelnig zmoelnig at iem.at
Wed Feb 4 11:51:48 CET 2015


-----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-----



More information about the Pd-dev mailing list