[PD-dev] multi-architecture deken packages

[IOhannes m zmölnig]

this all started as a thread on github:
https://github.com/ericlyon/pd-fftease/issues/45

since i think it is of general interest (and i'm pretty sure i will 
never ever find the relevant info under the "time for a new release? 
(FFTease-3.1)" thread again, i'm taking this discussion here.

the thread mainly revolves around how to create a single deken-package 
that contains binaries for all the relevant architectures.
i'm too lazy to recap it here.

the current discussion state is, how to deal with all those arm-variants 
out there.

if somebody has more insight into the arm architectures, please shed a 
light :-)

::::::

it's not complicated: the 32bit arm variants `armv6`, `armv7`, `armv8` 
(aka `aarm32`),... are backwards compatible.
- you can run a binary compiled for `armv6` on any `armv7` or `armv8` CPU.
- you can run a binary compiled for `armv7` on any `armv8` CPU.
- but you cannot run a binary compiled for `armv8` on the older `armv7` 
resp `armv6`  CPUs (missing instruction set)
- similarly, you cannot run a binary compiled for `armv7` on the older 
`armv6` CPU.

it's very similar to `i386` and `i686` and `Pentium-i7` and the like.
typically, the newer CPUs will have instruction sets that outperform the 
older CPUs (`MMX/SSE/AVX` on the `x86` platform; `NEON` on `arm`).
however, if you have a modern `Pentium-i7` and you are running an 
`i386`-compatible binary you will probably still get decent performance, 
because the processor is so much faster.
with `arm`-chipsets it is a bit different, as they are much less 
powerful, so you hit the limitations sooner.

@porres wrote:
 > I'm confused now, does this mean Raspbian is just for RPi Zero/1?

it means that you can use Raspbian on the RPi Zero/1/2/3 and 4.
however, you will get sub-optimal performance on the RPi2 and above.

if you enable the normal Debian repositories on the RPi, you will get 
into trouble on the RPi Zero/1, as the binaries might (and most likely: 
will) have instructions that the RPi Zero/1 lacks.

 > so i'm confused, is the organelle a rasp 1?

it all depends on which version you have. the [current 
specs](https://www.critterandguitari.com/organelle#design-specs) mention 
a `ARM Cortex A53` which is an `aarch64` processor (`armv8`)

@emviveros wrote
 > "compute module" are not important since **RPizero variants are 
important**, so armv6 should be disponible.

i'm not sure i understand what you mean.
i tried to say, that i believe that
- "compute module" is not important
- RPi/zero is of (limited) importance
- because of the RPi/zero we probably want to support `armv6`

i guess you are saying the same(?)

and
 > My first annoying is how to name armv6, armv7 and armv8 (aarch64) 
binaries to create a unified deken package for arm compilations.

i don't know what this means either.
however, i think we should forget about a unified `arm32` deken package.

 > armv6 = ?? (maybe .pd_linux)
 > armv7 = .l_arm
 > armv8 = .l_arm64


to which @porres answered:
 > anyway, let's just have these 3 together and I guess there won't be 
any issues :)



at least for me, `armv8` is not the same as `aarch64`.
most `armv8` are capable of both 32bit (`aarch32`) and 64bit (`aarch64`) 
instruction sets, but the 64bit part is optional.
i'd prefer to use the `armv8` name for the 32bit variant *only*. when 
talking about the 64bit variant, we should use `aarch64`.

regarding `armv6` and `armv7` in a single folder, i'm not sure whether 
this would work:
- if a `Pd-armv7` happens to see the `armv6` external first, it will 
just load it (and never try to `armv7` binary)
- if a `Pd-armv6` happens to see the `armv7` external first, it will 
just try load it: and i think the *loading* would succeed, leading to 
crashes whenever an illegal (armv7-)instruction is encountered.

but as i've written above: the `armv6` is a very limited platform. you 
probably do not want to install any binaries that you cannot use on it 
anyhow. so i'd suggest to cram all the architectures into a fat deken 
package with the exception of `armv6` which you should package separately.


mgfds
IOhannes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20210414/4f3ca20a/attachment.sig>