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

Christof Ressi info at christofressi.com
Tue Nov 24 16:19:25 CET 2020


> 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





More information about the Pd-list mailing list