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
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ Pd-dev mailing list [email protected] https://lists.puredata.info/listinfo/pd-dev
