←back to thread

126 points bundie | 1 comments | | HN request time: 0.31s | source
Show context
shirro ◴[] No.44460275[source]
Seems like a tough call for operating systems to do this when things are moving so fast. With risc-v its probably better to be future looking given current limitations but if a lower spec risc-v exploded in popularity you miss out.

Debian decided, probably very sensibly at the time, to set their minimum target for their 32 bit arm hardfloat distro to armv7. I guess hardly anyone used armv6 with hardware floating point apart from some obscure Broadcom chip. Then the original Raspberry Pi was released, moved an insane number of units, and Debian users would have been stuck with no hardware floating point. Fortunately Mike Thompson recompiled Debian for armv6 with hardfloat and that Debian fork (Raspbian) ended up becoming the basis for the official Raspberry Pi OS.

replies(3): >>44460738 #>>44463914 #>>44474962 #
saurik ◴[] No.44460738[source]
The original two generations of iPhone were armv6 with hardware floating point, so that always felt to me like the sane baseline. Android wasn't using hardware floating point on armv6, but I think that was only because the compilers they had sucked (an issue that didn't apply to Apple), and many/most of the devices in fact shipped with the same hardware. I dunno... like, I don't know exactly what went into Debian's decision there, but I could see it having been made for the wrong reasons: looking at what software had been deployed rather than what hardware was common?
replies(2): >>44460759 #>>44462555 #
sanxiyn ◴[] No.44460759[source]
You can look at Debian's reasoning here: https://wiki.debian.org/ArmHardFloatPort. As I understand, the decision was mostly based on hardware.
replies(2): >>44460847 #>>44461256 #
1. saurik ◴[] No.44461256[source]
I might be missing it, but, after going through that entire page, the only things I am seeing that are relevant are the following four sentences, and none of them provide a rationale?

> Currently the Debian armhf port requires at least an Armv7 CPU with Thumb-2 and VFP3D16.

> It might make sense for such a new port -- which would essentially target newer hardware -- to target newer CPUs. For instance, it could target Armv6 or Armv7 SoCs, and VFPv2, VFPv3-D16 or NEON.

> In practice armel will be used for older CPUs (armv4t, armv5, armv6), and armhf for newer CPUs (armv7+VFP).

> Some concern for fast-enough, pretty awesome (600MHz+) Armv6 + VFPv2 processors here - i.MX37 etc. - which will not be supported by armhf default flavour, but.. we will have to live with that