[PD] PD 64 bits precision "for real"?

[Alexandre Torres Porres]

I think of it as a variant. It's the same program but with 64 bit precision.

Just like we have the section "*Compiled versions for older, 32-bit
processors*" for download in miller's site. As far as externals go, those
have the same problem and one would need to get pd 32 bits just to run old
external libraries not available for the newer Pd. One example is the [hid]
external that we just now made available (finally).

And in the end if we have downloads for Pd 0.52-0 in 64 bit precision, then
it'd be Pd 0.52-0 just like the one with Pd with 32 bit precision...

So yeah, I guess we need to make it available for download for 32 bits
precision as well, just like we should keep the ones for 32 bit processors
and even for PPC (although no new versions will be made available I guess
as miller's machine broke, so probably not).

So, just make a section "*Compiled with double (64-bit) precision*" and
another as "*Compiled with single (32-bit) precision*"

As for how the app comes out. I remember that when it was something new,
the ones compiled for 64-bit processors had a different name. Now it's the
other way around. For example, the mac one comes as "i386" at the end of
the app name!

 We can just have something like that and start by making a distinction,
with something like Pd-0.52-0-double, and some time in the future (up to 3
versions later the most, I guess) it'll be the "regular" one and the others
can be called Pd-0.55-0-single.

cheers

Em ter., 24 de nov. de 2020 às 12:21, Christof Ressi <info at christofressi.com>
escreveu:

> > unless a 64-bit version had some way
> > of running 32-bit externals
>
> Pleeease, let's not call it "64-bit" vs. "32-bit". Those terms usually
> refer to the CPU target architecture. It's "single precision" vs.
> "double precision"
>
> > so any externals
> > built for previous versions would crash
> IOhannes added a clever mechanism to avoid runtime crashes. Incompatible
> externals will instead refuse to load.
>
> What we need is to find an easy way to create "fat" binaries (containing
> both single and double precision of the same library) and/or come up
> with a naming convention, so both versions can co-exist (similar to how
> we use ".*_amd64" and ".*_i386" to distinguish between 64-bit and 32-bit
> Intel binaries).
>
> > it would be effectively a
> > different program, not just a new version.
> I would say it's neither. It's just a build option.
>
> Christof
>
> On 24.11.2020 16:07, Martin Peach wrote:
> > On Tue, Nov 24, 2020 at 5:07 AM jayrope <jayrope at gmail.com> wrote:
> >> Why do we need _any_ name change?
> >> Any obvious version jump would do it already, 0.6, no?
> > A 64-bit Pd would not be compatible with any previous version because
> > all the memory structures would be differently sized, so any externals
> > built for previous versions would crash. While any patches using
> > vanilla objects would still work, unless a 64-bit version had some way
> > of running 32-bit externals in parallel, it would be effectively a
> > different program, not just a new version.
> >
> > Martin
> >
> >
> >
> > _______________________________________________
> > Pd-list at lists.iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20201124/e7dce2ed/attachment.html>