Software and hardware obsolescence in the kernel
The software side
Obsolete hardware, he said, can be defined as devices that are no longer being made, usually because they have been superseded by newer, cheaper, and better products. Obsolete hardware can still be useful, and often remains in use for a long time, but it's hard to know whether any specific device is still used. Obsolete code is a bit different; the hardware it enables might still be in production, but all of its users are running older kernels and are never going to upgrade. In such cases, the code can be removed, since nobody benefits from its ongoing maintenance.
Bergmann's proposal is to create a way of documenting which code in the kernel is there solely for the support of obsolete hardware; in particular, it would note the kernel configuration symbols associated with that hardware. For each symbol, the document would describe why it is still in use and for how long that situation is expected to continue. The consequences of removing this support (effects on other drivers that depend on it, for example) would be noted, as would the benefits that would come from removing it.
There are various groups that would be impacted by this change. The kernel
retains support for a number of hobbyist platforms, for example; these
include processor architectures with no commercial value but an ongoing
![[Arnd Bergmann]](https://static.lwn.net/images/conf/2020/lpc/ArndBergmann-sm.png "Arnd Bergmann")
hobbyist following. The kernel still supports a number of Sun 3
workstation models; he has no idea whether anybody is actually
running such systems or not. Kernel developers generally like to keep
hobbyist platforms alive as long as somebody is willing to maintain them.
Then there are platforms with few users, but those users may really need them. These include various types of embedded systems, industrial controllers, military systems, and more. There are also systems that are clearly headed toward obsolescence in the future. These include 32-bit architectures which, while still heavily used now, will eventually go away. Systems with big-endian byte order have declined 90% in the last ten years, and may eventually vanish entirely.
So where should this sort of information be documented? He proposed a few options, including a new file in the documentation directory, in the Kconfig files that define the relevant configuration symbols, somewhere on wiki.kernel.org, or somewhere else entirely. Responding to a poll in the conference system, just over half of the attendees indicated a preference for a file in the kernel tree.
At this point your editor had to jump in and ask how this idea compares to the kernel's feature-removal-schedule.txt file. This file was added in 2005 as a way of warning users about features that would go away soon; this file itself was removed in 2012 after Linus Torvalds got fed up with it. Why should the fate of this new file be different? Bergmann responded that this file would not be a schedule for removal of support; instead, it would be a way of documenting that support needs to be kept for at least a certain period of time. Users of the affected hardware could easily update the file at any time to assure the community that they still exist. As documentation for the reasons to keep support in the kernel, it would be more useful.
Florian Weimer asked what the effect would be on user space if this proposal were adopted; the answer was "none". User-space interfaces are in a different category, Bergmann said, with a much higher bar to be overcome before they can be removed. This file would cover hardware-specific code. Mike Rapoport added that it would be a way to know when users would be unaffected, once it becomes clear that nobody is running upstream kernels on the hardware in question.
Catalin Marinas suggested creating a CONFIG_OBSOLETE marker for code that supports obsolete hardware, but Will Deacon was nervous about that idea. He recently did some work on the page-table code for 32-bit SPARC machines; he got no comments on those changes, but he did get reports when various continuous-integration systems tested them. A CONFIG_OBSOLETE marker might be taken as a sign by the maintainers of such systems that the code no longer needs to be tested, reducing the test coverage significantly.
Bergmann added that 32-bit SPARC is an interesting case. People have been finding serious bugs in that code, he said, and System V interprocess communication isn't working at all. There is a lot of testing of 32-bit SPARC user space, but the tests all run on 64-bit kernels, where these problems do not exist. He is confident that this code has few — if any — remaining users.
Len Brown returned to the question of the old feature-removal-schedule.txt file, asking what had been learned from that experience. Bergmann replied that his proposed documentation is intended to help plan removal. It is, he said, a lot of work to try to figure out if a particular feature is being used by anybody; documenting users in this way would reduce that work considerably. Laurent Pinchart added that this information could also be useful for developers who would like to find users of a given piece of hardware to test a proposed change.
As the session came to a close, James Bottomley noted that this kind of problem arises often in the SCSI subsystem, which tends to "keep drivers forever". Eventually, though, internal API changes force discussions on the removal of specific drivers, but that is always a hard thing to do. It is easy to say that a removed driver can always be resurrected from the Git history if it turns out to be needed, but that doesn't work out well in practice.
Bergmann ended things by noting that the maintainer of a given driver is usually the person who knows that nobody is using a given device. But once that happens, the maintainer often goes away as well, taking that knowledge with them. At that point, it's nobody's job to remove the code in question, and it can persist for years.
System-on-chip obsolescence
Bergmann returned to this topic in another session dedicated to the life cycle of system-on-chip (SoC) products. Having spent a lot of time working on various aspects of architecture support in the kernel, he has learned a few things about how support for SoCs evolves and what that might mean for the architectures currently supported by the kernel.
There are, he said, five levels of support for any given SoC in the kernel:
- Full upstream support, with all code in mainline, all features working, and new kernel features fully supported.
- Minimal upstream support, but fixes and updates still make it into the stable kernel releases.
- Updates in mainline are sporadic at best; perhaps fixes go into the long-term-support kernels.
- No more upstream support; users are getting any updates directly from the vendor.
- The system runs, but there are no updates or ongoing support in the mainline kernel. There might still be code in the kernel, but it is not used by anybody.
The most important phase for SoC support is the bringup stage, when things are first made to work; if at all possible, that support should be brought all the way to the "full support" level. The level of support normally only goes down from there. People stop applying updates and, eventually, those updates stop appearing at all.
Problems at bringup tend to happen in fairly predictable areas, with GPU drivers being at the top of the list. That said, the situation has gotten a lot better in recent times, with increasing numbers of GPUs having upstream support. Android patches can be another sticking point; that, too, is improving over time. Short time to market and short product lifespan can both be impediments to full support as well.
Bergmann put up a diagram displaying the "CPU architecture world map" as of 2010; it can be seen on page 6 of his slides [PDF]:
![[CPU architecture
world map]](https://static.lwn.net/images/conf/2020/lpc/arnd-cpumap.png)
This map plots architectures used in settings from microcontrollers through to data-center applications on one dimension, and their affinity to big-endian or little-endian operation on the other. These architectures were spread across the map, with IBM Z occupying the big-endian, data-center corner, and numerous architectures like Blackfin and unicore32 in the little-endian, microcontroller corner.
There were a lot of architectures available at that time, he said, and the future looked great for many of them. The Arm architecture was "a tiny thing" only used on phones, not particularly significant at the time. But phones turned out to be the key to success for Arm; as it increased its performance it was able to eliminate most of the others.
The SoC part of the market, in particular, is represented by the middle part of the map: systems larger than microcontrollers, but smaller than data-center processors. There are three generations of these that are important to the kernel. The first, typified by the Armv5 architecture, came out around 2000 and is still going strong; these are uniprocessor systems with memory sizes measured in megabytes. The Armv7-A generation launched in 2007 with up to four cores on an SoC and memory sizes up to 2GB; this generation is completely dominated by Arm processors. Finally, the Armv8-A (and x86-64) generation, beginning in 2014, supports memory sizes above 2GB and 64-bit processors.
He discussed memory technologies for a while, noting that DDR3 memory tends to be the most cost-effective option for sizes up to 2-4GB, but it is not competitive above that. That's significant because middle-generation processors cannot handle DDR4 memory.
The only reason to go with first-generation processors, he said, is if extremely low cost is the driving factor. For most other applications, 64-bit systems are taking over; they are replacing 32-bit SoCs from a number of vendors. The middle, Armv7-A generation is slowly being squeezed out.
Kernel support implications
So what are the implications for kernel support? He started with a plot showing how many machines are currently supported by the kernel; most of those, at this point, are described by devicetree files. There are a few hundred remaining that require board files (compiled machine descriptions written as C code). He suggested that the time may be coming when all board-file machines could be removed; if those machines were still in use, he said, somebody would have converted them to devicetree.
By 2017, it became clear that many architectures were approaching the end of their lives; that led to the removal of support for eight of them in 2018. Some remaining architectures are starting to look shaky; there will probably be no new products for the Itanium, SPARC M8, or Fujitsu SPARC64 processors, for example. The industry is coalescing mostly on the x86 and Arm architectures at this point.
Those architectures clearly have new products coming out in 2020 and beyond, so they will be around for a while. There are some others as well. The RISC-V architecture is growing quickly. The IBM Power10 and Z15 architectures are still being developed. Kalray Coolidge and Tachyum Prodigy are under development without in-kernel support at this point. There is a 64-bit version of the ARC architecture under development with no kernel support yet. There are still MIPS chips coming out from vendors like Loongson and Ingenic and, perhaps surprisingly, still SoCs based on the 20-year-old Armv5 core being introduced.
Big-endian systems are clearly on their way out, he said. There were a number of architectures that supported both; most are moving to little-endian only. SPARC32 and OpenRISC are holdouts, but their users are expected to migrate to RISC-V in the relatively near future. About the only architecture still going forward with big-endian is IBM Z.
There are some new SoC architectures in the works. The most significant one is RISC-V, with numerous SoCs from various vendors. Expectations for RISC-V are high, but there are still no products supported in the kernel. The ARC architecture has been around for 25 years and remains interesting; it sees a lot of use in microcontrollers. There is not much support for 32-bit ARC SoCs in the kernel, and no support yet for the upcoming 64-bit version. That support is evidently under development, though.
Where does all this lead? Bergmann concluded with a set of predictions for what the situation will be in 2030. The market will be split among the x86-64, Armv8+, and RISC-V architectures, he said; it will be difficult for any others to find a way to squeeze in. The upstreaming of support for these architectures in the kernel will continue to improve. IBM Z mainframes will still be profitable.
The last Armv7 chips, instead, have been released now, but they will still be shipping in 2030 (and in use for long after that). So 32-bit systems will still need to be supported well beyond 2030. For those reasons and more, he is not expecting to see further removals of architecture support from the kernel for at least the next year.
At the other end, 128-bit architectures, such as CHERI,
will be coming into their own. That is likely to be a huge challenge to
support in the kernel. The original kernel only supported 32-bit systems
until the port to the Alpha architecture happened; that port was only
feasible because the kernel was still quite small at the time. The (now
much larger) kernel
has the assumption that an unsigned long is the same size as a
pointer wired deeply into it; breaking that assumption is going to be a
painful and traumatic experience. Fixing that may be a job for a new
generation of kernel hackers.
| Index entries for this article | |
|---|---|
| Kernel | Architectures |
| Conference | Linux Plumbers Conference/2020 |
Posted Aug 28, 2020 22:37 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (48 responses)
Posted Aug 28, 2020 23:11 UTC (Fri)
by mpr22 (subscriber, #60784)
[Link]
Posted Aug 29, 2020 1:21 UTC (Sat)
by nevets (subscriber, #11875)
[Link]
But I do miss working on BE systems, as it makes reading raw memory out one byte at a time still makes sense
Posted Aug 29, 2020 1:25 UTC (Sat)
by roc (subscriber, #30627)
[Link] (30 responses)
The market reason is that Intel took over and a lot of code accidentally or deliberately requires little-endian.
Posted Aug 29, 2020 16:18 UTC (Sat)
by marcH (subscriber, #57642)
[Link] (29 responses)
Long story short, little endian is more machine-friendly while big endian is more user-friendly: hexdump output is easier to read (because human numbers are big endian).
Posted Aug 29, 2020 19:31 UTC (Sat)
by epa (subscriber, #39769)
[Link] (28 responses)
Posted Aug 29, 2020 19:57 UTC (Sat)
by mpr22 (subscriber, #60784)
[Link] (27 responses)
Posted Aug 30, 2020 5:34 UTC (Sun)
by epa (subscriber, #39769)
[Link] (26 responses)
Posted Aug 30, 2020 8:16 UTC (Sun)
by amarao (guest, #87073)
[Link]
Posted Aug 30, 2020 10:19 UTC (Sun)
by mpr22 (subscriber, #60784)
[Link]
Posted Aug 30, 2020 14:49 UTC (Sun)
by pizza (subscriber, #46)
[Link] (13 responses)
Um, no. Arabic is written right-to-left, but numbers are written left-to-right, ie big-endian.
Now the numbers may be *read* right-to-left, or a mixture of the two ("125" is read as "one hundred five-and-twenty"), but in written form, they're left-to-right.
Posted Aug 30, 2020 18:05 UTC (Sun)
by epa (subscriber, #39769)
[Link] (12 responses)
I always assumed that Arabic numbers were written and read in the same order as the rest of the text, in other words with the least significant digit coming first (little-endian) but I freely admit I have no knowledge of the Arabic language so it could be more complex than I thought.
Posted Aug 30, 2020 19:57 UTC (Sun)
by pizza (subscriber, #46)
[Link] (11 responses)
Yep!
Posted Aug 31, 2020 6:34 UTC (Mon)
by epa (subscriber, #39769)
[Link] (10 responses)
Posted Aug 31, 2020 17:11 UTC (Mon)
by marcH (subscriber, #57642)
[Link]
This zig-zag doesn't feel like a very hard hand writing challenge, I mean not unless you have to deal with crazy long numbers. For computers and terminals it's apparently a bit harder :-)
> I guess that’s one concrete reason why left-to-right scripts are superior (apart from ink smudging).
Ink smudging _and_ hiding what you just wrote. Look at how left-handed people tend to bend their wrist, even with a pencil.
My urban legend is that right-to-left languages were superior for... carving. Ten commandments and all that :-)
Posted Aug 31, 2020 20:53 UTC (Mon)
by nybble41 (subscriber, #55106)
[Link] (7 responses)
They're read big-endian but written little-endian. Endianness is determined by the position (address) of each digit, not temporal order in which they're written. The least-significant digit is located at the lowest address, closest to the beginning of the text. When "serialized" (read aloud or subvocalized) the numbers are converted into big-endian format, with the most significant digit spoken first.
Posted Aug 31, 2020 21:22 UTC (Mon)
by marcH (subscriber, #57642)
[Link] (6 responses)
No because the numbers are not part of the text, they're a left-to-right insert in a right-to-left text. There are effectively two "address spaces" embedded in one another (a.k.a. "zig-zag").
As explained here, Arabic speakers start with the most significant digit when they read and write just like everyone else and that it is what should define what the "lowest address" is, otherwise non-Arabic speakers are misled into thinking Arabic speakers do something different which is exactly what happened in this thread. Speech readers would be confused too.
Posted Aug 31, 2020 22:22 UTC (Mon)
by nybble41 (subscriber, #55106)
[Link] (4 responses)
> As explained here, Arabic speakers start with the most significant digit when they read and write just like everyone else and that it is what should define what the "lowest address" is…
It doesn't make sense to talk about big-endian or little-endian without a single, consistent frame of reference for the addressing which is independent of the content. In a context where you would write the elements of a list right-to-left, that means starting with the lowest address on the right and monotonically increasing toward the left. Only after having defined this addressing scheme can we venture to answer whether the components of the list are written big-endian or little-endian with respect to that surrounding context.
The digit you read or write first (temporally, not spatially) has nothing to do with endianness. The order in which you wrote the digits is not part of the written record. Someone coming along later can't even tell what order the digits were recorded in; it makes no difference to them whether you wrote the least- or most-significant digit first. All they can see is the order of the digits as they are laid out visually on the page.
In serial communication the standard is different. There it matters which digit is pronounced first, because the temporal order of the symbols is *all* you can observe.
Posted Sep 1, 2020 1:23 UTC (Tue)
by marcH (subscriber, #57642)
[Link] (3 responses)
Of course they can, that's called "reading". I can hardly believe you wrote this...
Computers are not as smart though, so they may need some additional clues: https://www.w3.org/International/articles/inline-bidi-mar...
Posted Sep 1, 2020 15:01 UTC (Tue)
by nybble41 (subscriber, #55106)
[Link] (2 responses)
Are you being deliberately obtuse? If I sent you a picture of some digits I wrote left-to-right and some digits I wrote right-to-left, "reading" is not going to be enough to tell them apart. Here, I'll demonstrate:
1234
To simulate physical writing I filled both lines with spaces and then overwrote the spaces with digits. One line was filled in left-to-right, and the other line right-to-left. Please tell me, which one was written left-to-right?
Posted Sep 1, 2020 16:28 UTC (Tue)
by marcH (subscriber, #57642)
[Link] (1 responses)
I thought you were.
Natural languages are all about context, that's why computers need Unicode bidi = a bit more help. This has been well discussed and explained in several other places in this thread (thanks to all those who did) but if not obtuse you are definitely not receptive. Never mind.
Posted Sep 2, 2020 3:51 UTC (Wed)
by nybble41 (subscriber, #55106)
[Link]
Indeed, natural language is all about context. I get the feeling that we are talking about two completely different things and getting frustrated because the other person's answers make no sense in the context of what we each thought the conversation was about. I have been trying to describe how the terms "big-endian" or "little-endian" would apply to the *visual* layout of Arabic numerals *at rest*, for example as symbols written on paper—akin to the individual bytes of an integer field which is part of a larger structure stored in RAM or a file on disk. You seem to be interpreting my statements in the context of data which is *being* written, or read, or typed into a computer—a *serialization* of the data. Or perhaps you are referring to the particular way that the digits would be serialized as Unicode code points in a text file. Naturally my statements would seem like nonsense when taken that way; they were not intended for that context.
For data at rest there is no "time" component; all that matters is the relationships between the addresses or coordinates where each of the digits is stored. For digits written in a single line on paper this corresponds to linear physical coordinates; a digit may appear either to the left or the right of another symbol. In terms of the analogy to the storage of an array of multi-byte integers in computer memory, a system in which the most-significant digit of each number in a list of numbers is physically located on the same side as the first element of the list is "big-endian" and a system in which the least-significant digit is physically closest to the first element of the list is "little-endian". Any given serialization of the data (the process of reading or writing, for example) may employ a different "endianness" independent of the visual layout, and indeed that is the case for Arabic numerals: they are stored or rendered (on paper or other visual medium) as little-endian, but read, written, typed, or spoken aloud with the most significant digit first, in big-endian format.
Anyway, this debate is almost as pointless as the fictional conflict from which we get the terms "big-endian" and "little-endian".[1] I only replied in hopes of conveying that we are arguing *past* each other more than we are actually disagreeing about anything of substance.
[1] https://www.ling.upenn.edu/courses/Spring_2003/ling538/Le...
Posted Aug 31, 2020 23:23 UTC (Mon)
by kjpye (subscriber, #81527)
[Link]
If you are reading a number like 8034175, you start "eight million", but you can't get past the "eight" until you have scanned from the right of the number to the left to determine the magnitude.
So a non-Arabic speaker will read left to right, encounter the number and skip to the end of the number and scan back to determine the magnitude and then read the number left to right and continue reading towards the right.
An Arabic speaker will encounter the right-hand end of the number first, scan across it to determine the magnitude and then read the number left to right. Then they will jump back to the left of the number and continue reading towards the left.
The only real difference is in whether the jump occurs before reading the number (non-Arabic) or after (Arabic).
Posted Sep 1, 2020 0:43 UTC (Tue)
by notriddle (subscriber, #130608)
[Link]
Figure out the endianness of THAT notation!
Posted Aug 30, 2020 15:14 UTC (Sun)
by jem (subscriber, #24231)
[Link] (9 responses)
Or are they? As is common knowledge, Arabic is written right-to-left, but it is my understanding that numbers are read left-to-right. Digits are shown in the same order as in Western scripts, for example two hundred and thirty-five is "235" or "٢٣٥", depending on whether Western Arabic or Eastern Arabic (Hindi) numerals are used. When this number is read, the reader first looks at the hundreds. Likewise, when numbers are entered on a device, the input system temporarily changes direction to left-to-right, so the digits are entered in the order 2, 3, 5 and the result is displayed as "235". Reference: Numbers in Arabic.
Posted Aug 30, 2020 17:31 UTC (Sun)
by karkhaz (subscriber, #99844)
[Link] (8 responses)
This is precisely what little-endian means, right? Consider the following sequence of four numbers, written in an LTR language like English. You start reading at X and finish reading at Y.
X 123 555 1234 Y
In Arabic, this sequence is written as
Y ۱۲٣٤ ۵۵۵ ۱۲٣ X
In English, your eyes continuously move from left-to-right. In Arabic, your eyes zig-zag across the page: from right-to-left to read the sentence, but from left-to-right when reading each of the three numbers. This is analogous to little-endian, where the bytes within a structure are laid out in opposite direction to the addresses of the structures.
Posted Aug 30, 2020 18:41 UTC (Sun)
by jem (subscriber, #24231)
[Link] (2 responses)
Posted Oct 14, 2020 10:50 UTC (Wed)
by immibis (subscriber, #105511)
[Link] (1 responses)
I don't think so.
Posted Oct 14, 2020 18:31 UTC (Wed)
by nybble41 (subscriber, #55106)
[Link]
Yes, the serialization of the word on the 8-bit bus would be accurately labeled big-endian if the MSB is transferred first—not that this would be observable to software. The storage would still be little-endian since the LSB is stored at the lowest-numbered address. This can be confirmed by accessing the same memory address with byte- and word-oriented instructions.
Posted Aug 30, 2020 18:51 UTC (Sun)
by iabervon (subscriber, #722)
[Link] (4 responses)
I expect that, if you grew up using big-endian numbers and then learn Arabic and see a number in it, you'll zig-zag. But if you grew up with Arabic, you'll read "1234 555 123" as "three, twenty, one hundred; five, fifty, five hundred; four, thirty, two hundred, one thousand", going right-to-left through the number.
I suspect that big-endian practice comes from a culture that used Roman numerals, which start with the highest-value information and don't require knowing how many more digits are coming to assign a value to the first digit, getting Arabic texts on arithmetic and keeping the computation the same while translating the explanation, and the Arabic texts had the ones digit on the right because that's the first digit you produce in addition, multiplication, or subtraction, and they put the first digit of a number where they put the first letter of a word.
Posted Aug 30, 2020 19:26 UTC (Sun)
by karkhaz (subscriber, #99844)
[Link] (3 responses)
No, this really isn't the case. Native Arabic readers don't start reading the lowest-magnitude digit first, they skip to the largest digit and read left-to-right. Both when reading, and when uttering the number (with the exception that units are uttered before tens).
As another example, consider the date range 1979-2020. In Arabic this is written ١٩٧٩-٢٠٢٠ and pronounced "one thousand and nine hundred and nine and seventy to two thousand and twenty".
Posted Aug 30, 2020 21:23 UTC (Sun)
by karkhaz (subscriber, #99844)
[Link]
[1] https://lwn.net/Articles/749992/
Posted Aug 30, 2020 22:47 UTC (Sun)
by marcH (subscriber, #57642)
[Link]
Very useful thanks, I suspected such a "full zig-zag" but wasn't sure.
I admit I didn't consider right-to-left languages at the time I wrote "human numbers are big endian" above. Thank you right-to-left languages for this making this zig-zag exception and keeping my statement correct, much appreciated :-)
More seriously, it's easy to imagine the rationale for this zig-zag:
Posted Aug 31, 2020 20:46 UTC (Mon)
by nybble41 (subscriber, #55106)
[Link]
So numbers are written in little-endian notation (given right-to-left addressing for "unstructured" data, i.e. plain text), and converted to big-endian when "serialized" (spoken aloud) without rearranging the rest of the text. That sounds exactly like a traditional little-endian network stack to me.
Posted Aug 29, 2020 11:05 UTC (Sat)
by anton (subscriber, #25547)
[Link] (4 responses)
Concerning technical reasons, I lean towards little-endian for the following technical reasons: bit numbering and byte numbering should follow the same direction, otherwise larger bit arrays become cumbersome to program (IIRC the 68000 bit field instructions got this wrong by combining little-endian bit ordering with big-endian byte ordering). For bit numbering (also for byte numbering, but there it does not play such a big role), big endian means that different word sizes have different numbers for the least significant bit; i.e., the number 1 has bit 63 set in a 64-bit word and bit 31 set in a 32-bit word. I find this unpleasant, but then, I grew up with the little-endian 6502, so it may just be that I am not used to it.
Posted Aug 29, 2020 15:15 UTC (Sat)
by arnd (subscriber, #8866)
[Link] (3 responses)
Regarding the bit numbering, calling the MSB 'bit 0' seems to be an IBM thing, all other big-endian CPUs I've seen still call the LSB 'bit 0', but they instead have inconsistent numbering when looking at bits vs. bytes, so the first byte of a 64-bit number contains bits 63 through 56.
Posted Aug 29, 2020 16:23 UTC (Sat)
by anton (subscriber, #25547)
[Link]
But if you want to extract, say, bits 30-33 of a 64-bit value on a (32-bit) 68020, this mixing of little-endian bit order and big-endian byte order gets in the way, and you know why IBM number the bits as they do.
So apparently everyone (but IBM) prefers little-endian bit order, and in a some cases (like the example above) this means that little-endian byte order is also preferable.
Posted Aug 31, 2020 22:23 UTC (Mon)
by willy (subscriber, #9762)
[Link] (1 responses)
The disease metastatized outside of IBM.
I'm surprised nobody's yet mentioned the mixed endian ARM FPU system (maybe it's too old) where the bytes in each 32-bit word were stored little endian (as befitted the LE architecture that ARM was at the time), but the words were stored in the wrong order. ie 45670123
Posted Sep 11, 2020 19:27 UTC (Fri)
by nix (subscriber, #2304)
[Link]
(Still looking back in history, the VAX had even crazier endiannesses, particularly for its weirdo floating-point formats.)
Posted Aug 29, 2020 20:06 UTC (Sat)
by ppisa (subscriber, #67307)
[Link] (6 responses)
When computation goes only within CPU and memory then there is minimal difference when one or another endianing is used except for arbitrary arithmetic precision where start from LSB bit, word help to propagate carry. But it is niche case and there is no problem to have little-endian sequence of big-endian worlds which is no problem in this case. Build cores with configurable endianness is no problem regarding the memory. The data are stored on both systems in same way in the worlds in memory and only for accesses shorter than world size the bytes multiplexer/router uses different rule based on size and LSB address bits. Again minimal hardware and no software overhead.
But the things change rapidly when the system needs to interact with external world. There endianness matter and there is case of nightmare when you have byte grained data buffers combined with machine word sized control registers. You want to access data buffers directly and read serialized data but you want to use fast single cycle access to registers. The same for serialized data from external world.
The Internet Protocol has been probably developed on big-endian system the first so network order is defined as big-endian (I do not count Corba which is endianness neutral or modern later defined protocols or automotive CAN, but all IP, TCP, UDP, RPC, NFS... are big-endian). Big-endian addresses serialization has advantage that router can start to decide about destination queue even when only initial part of address field is received (probably no win for IPv4 today but for IPv6 there can be some advantage). So big-endian server systems have advantage for long time.
But then PC has started to dominate cheap computing and started to grow even into small servers area and Intel has been successful in forming consortium which defined PCI standard under its lead in 1992. Because PCI was and is successful and defined model to design and manage mid range peripheral devices for almost 30 years already. The PCI (today PCIe) network, disk, video controller chips has been COTS products and to reduce cost they and PCI started to be used even in higher class systems in the places where their throughput has been enough. Specialized Inifiband etc... interconnect is still used for big systems for main data exchanges flow, but management peripherals are often COTS PCIs, even big systems offer PCIe slots etc...
And there comes significant problem for big endian systems. They can map PCI devices in native world order, it would work well with access to control registers etc... but data stored to main memory through bus "master" (what is today and tomorrow sugester term there) accesses and when data are taken as serialized to byte stream or UTF-8 text etc, then swapping endianness in kernel, during buffer copy or even worse for zero copy mapped pages in target applications would be nightmare. I think I have seen in the past that some systems mapped PCI devices swapped in a early days, but today they map them in a little-endian manner which means that ioread and iowrite and related kernel functions to access peripherals registers are by default little endian and most of the drivers use these functions directly. https://lkml.org/lkml/2005/4/4/230
So the big-endian systems has to provide memory access instructions or mechanism to use little-endian order for peripherals to mitigate impact or have to provide fast instructins to swap endianness to limit impact to reasonable level. Because even much of the software is developed and tested by developers on their little-endian PCs then porting of projects to big-endian is only additional costs, makes problems with management peripherals and PCIe is used even for main data paths today where it provides enough bandwidth....
So even that there is minimal theoretical difference and correlation between used endianness and performance for given algorithm, there are practical reasons to switch to little-endian even that network order processing of headers and protocols has some small cost (CPUs has optimized instructions for that).
Posted Aug 30, 2020 9:06 UTC (Sun)
by anton (subscriber, #25547)
[Link]
XDR (used by RPC) and NFS were developed at Sun, which was big-endian (68000 and SPARC). Concerning TCP, IP, and UDP, I don't know what hardware was used for developing that, and if it even was byte-addressed (while also supporting longer words in hardware; if not, byte order is not an issue as far as the hardware is concerned).
Posted Aug 30, 2020 9:07 UTC (Sun)
by kreijack (guest, #43513)
[Link] (4 responses)
This means that an architecture there is no a conversion, and that in the other one there will be some form of conversion.
E.g. BTRFS use the little endian format. To access the filesystem metadata BTRFS uses a set of macros that in little endian architecture do nothing, in the big endian architecture do a translation le->be.
Posted Aug 30, 2020 16:11 UTC (Sun)
by Wol (subscriber, #4433)
[Link] (1 responses)
But when the particular variant I work with was ported from little-endian architectures to big-endian, the promise you could just copy a FILE (the equivalent of a SQL table) and read it was broken.
So they supplied a little utility so that, when copying between different endian machines, this utility would swap the byte metadata over. Bit like the cr2lf utility.
Cheers,
Posted Sep 11, 2020 19:40 UTC (Fri)
by nix (subscriber, #2304)
[Link]
This approach has two significant advantages over endian-flipping to a format-specified hardwired endianness: firstly, you never incur endian-flipping overhead in the common case of the same endianness being used on the generator and reader, no matter what the endianness of your machine; secondly, almost the entire codebase can completely ignore all this awful stuff, and only one localized place (the place that endian-flips if a foreign endianness is detected) needs to know about it.
The downside is that I need to explicitly test creating CTF on a machine with one endianness and then using it on one with the opposite endianness, or the endian-flipping code will never be exercised and will eventually silently rot. But still it seems to be much less bug-prone than forcing the format to be one specific endianness and compensating for that everywhere.
Posted Sep 3, 2020 15:49 UTC (Thu)
by mchouque (subscriber, #62087)
[Link] (1 responses)
You couldn't mount a filesystem coming from a BE on a LE machine and vice-versa.
e2fsck used to have an option for that:
-S This option will byte-swap the filesystem, regardless of its
Posted Sep 3, 2020 17:44 UTC (Thu)
by geert (subscriber, #98403)
[Link]
When people realized the incompatibility, two options were considered:
Posted Sep 11, 2020 10:05 UTC (Fri)
by rep_movsd (guest, #100040)
[Link] (2 responses)
I never understood why someone would use an un-intuitive big endian format ( which is clearly based on the fact that we write numbers left to right manually )
Posted Sep 11, 2020 17:18 UTC (Fri)
by mpr22 (subscriber, #60784)
[Link] (1 responses)
Of course, most people don't have to do that very often these days.
Posted Sep 11, 2020 18:12 UTC (Fri)
by mjg59 (subscriber, #23239)
[Link]
Posted Aug 28, 2020 22:38 UTC (Fri)
by josh (subscriber, #17465)
[Link] (26 responses)
Why break that assumption? We could require that 128-bit architectures have 128-bit unsigned long. (At least within the kernel, if not in userspace. But if we're talking about a new architecture and new userspace, why *not* require that?)
Yes, there are types like uintptr_t and ptrdiff_t. But why not take the path of least resistance here?
Posted Aug 28, 2020 23:44 UTC (Fri)
by acarno (subscriber, #123476)
[Link] (18 responses)
Now could you do some fun compiler trickery where you assume 128-bit pointers in the code but then chop them up into 64-bit memory addresses (and vice-versa)? That may be a hacky-but-workable path forward.
Posted Aug 29, 2020 0:12 UTC (Sat)
by sbaugh (guest, #103291)
[Link]
So it sounds like you're in agreement with the parent - if, as you say, 128-bit data is needed, then since we already need 128-bit pointers, we might as well make unsigned long 128 bits.
Posted Aug 29, 2020 3:15 UTC (Sat)
by willy (subscriber, #9762)
[Link] (2 responses)
Intel have already moved from 4 to 5 level page tables (48 to 57 bits of virtual address space) for data centre CPUs. That'll last about another ten years.
I think the first thing we'll need is 128 bit files (-D_FILE_OFFSET_BITS=128). Then we'll need larger block devices. Then we'll need larger virtual address spaces for each process.
It'll be a long time before we need 16EiB of memory in a machine, but that amount of address space will be troublesome fairly soon.
Posted Aug 30, 2020 17:47 UTC (Sun)
by khim (subscriber, #9252)
[Link] (1 responses)
In a somewhat sane world you would be correct. But in practice nobody think much about making work for software engineers. Five-level tables were introduced to address physical memory, not for anything else. Other points are valid, though. We may need more than 16EiB of memory in a machine and when that would happen we would either need PAE or extend pointers again.
Posted Aug 30, 2020 18:11 UTC (Sun)
by willy (subscriber, #9762)
[Link]
I hope we don't get to a PAE situation, but that's a long way off. 128 bit off_t is the next problem to address.
BTW, I realised I've been saying 16EiB for off_t, but I forgot that off_t is signed, so actually 8EiB is the current limit.
A 128-bit off_t will let us go to 76 bit file sizes with the page cache (and a 4KiB page size), which should last us until around 2045. I hope we have three credible 128-bit CPUs by then.
Posted Aug 29, 2020 5:57 UTC (Sat)
by jem (subscriber, #24231)
[Link] (13 responses)
Before 128 bits are needed, we have to go through steps 64, 80, 96, 112, each with a duration of a few decades, if Moore's law holds.
Posted Aug 29, 2020 15:02 UTC (Sat)
by ianmcc (subscriber, #88379)
[Link] (2 responses)
Posted Aug 29, 2020 18:45 UTC (Sat)
by marcH (subscriber, #57642)
[Link]
https://www.pcworld.com/article/3546295/why-you-cant-get-...
Posted Aug 31, 2020 7:45 UTC (Mon)
by smurf (subscriber, #17840)
[Link]
128 bit kernel integers, on the other hand, make no sense whatsoever IMHO.
Posted Aug 29, 2020 23:51 UTC (Sat)
by willy (subscriber, #9762)
[Link] (9 responses)
Consider a giant cluster (eg weather forecasting). No individual machine has more than 16TiB of memory, but we want to have a unique address for each byte across the entire cluster. With 4096 nodes in the cluster, we're at 56 bits today.
We're only 6 bits away from being out of bits. That's pretty scary.
Yes, there's never going to be a need for a CPU with address registers bigger than 128 bits. I don't see busses being designed for addressing more than 80 bits for a good long time. But as soon as you need more than 64 bits of address, you double the register size. So we're going to need 128 bit CPUs sooner rather than later. Hopefully nobody makes an IA-64 sized cockup of the transition this time and we get a decent instruction set out of it.
Posted Aug 30, 2020 4:15 UTC (Sun)
by marcH (subscriber, #57642)
[Link] (3 responses)
I'm not sure it's wise to waste silicon and bandwidth with local address lines to address remote memory. RDMA is not the only option.
> So we're going to need 128 bit CPUs sooner rather than later.
The era of silicon custom for HPC is long gone.
Posted Aug 30, 2020 14:54 UTC (Sun)
by willy (subscriber, #9762)
[Link] (2 responses)
But I'm not talking about supporting lots of physical address bits. I'm talking about supporting:
1. Files larger than 16 EiB
We can hack around the missing 128 bit data types for a while. We did it on 32 bit systems for a decade before 64 bit systems were so prevalent that we stopped caring about inefficient 32 bit systems.
The era of custom silicon for HPC is very much still with us. Fujitsu's A64FX and Sunway's SW26010 are in 2 of the top 5 supercomputers. And HPC is far from the only user of large virtual addresses.
Posted Aug 30, 2020 15:23 UTC (Sun)
by Paf (subscriber, #91811)
[Link]
Also, the era of custom silicon for HPC is ... complex. It’s *mostly* over - the machines with it tend to be exceptions. Fujitsu is the last major vendor doing their own CPUs for HPC, and the Chinese machine noted can’t buy top class CPUs (plus they want to do their own to close that gap).
IBM, the former Cray and SGI (now both HPE), Bull in Europe... none of them have done a full up HPC CPU in quite a while. Cray is pushing towards 20 years, SGI I think is even further out from their last MIPS. IBM comes the closest, but their Cell and big Power chips have always been intended to have significant other markets.
Posted Aug 30, 2020 23:09 UTC (Sun)
by marcH (subscriber, #57642)
[Link]
That doesn't really change the problem: you're still forcing all local memory addresses to pay the additional price of a significant number of extra, constant zeroes only for the programming convenience of an addressing scheme unified with non-local memories that have totally different performance characteristics.
Hardware engineers "wasting" bandwidth and other resources in their design for software convenience? That doesn't sound very likely.
Posted Aug 30, 2020 7:19 UTC (Sun)
by epa (subscriber, #39769)
[Link] (4 responses)
Posted Aug 30, 2020 14:58 UTC (Sun)
by willy (subscriber, #9762)
[Link] (3 responses)
struct page *pages[15];
Do you really want to have each of these pointers be 10 bytes long? It doesn't even make sense for the pointers to be 12 bytes long. 16 bytes does make sense. And then you can use the top few bits for exciting things like ARM's pointer tagging.
Posted Aug 30, 2020 18:10 UTC (Sun)
by epa (subscriber, #39769)
[Link] (2 responses)
Posted Aug 30, 2020 18:12 UTC (Sun)
by willy (subscriber, #9762)
[Link] (1 responses)
Posted Aug 30, 2020 23:26 UTC (Sun)
by marcH (subscriber, #57642)
[Link]
Please share your thoughts (or references) if you have.
(as already mentioned by jem above:
Posted Aug 29, 2020 9:11 UTC (Sat)
by pm215 (subscriber, #98099)
[Link]
Posted Aug 29, 2020 10:29 UTC (Sat)
by smcv (subscriber, #53363)
[Link] (5 responses)
ISO C says char is at least 8 bits, short and int are at least 16, long is at least 32, and (I think) long long is at least 64. On ILP32 (e.g. 32-bit Linux/Windows), LP64 (64-bit Linux) and LLP64 (64-bit Windows) platforms, you can implement int8_t, int16_t, int32_t and int64_t as typedefs for the standard types: If you make long more than 64 bits, then you don't have enough types to implement all of int8_t, int16_t, int32_t and int64_t as typedefs to the standard types: you have {char, short, int}, you want {8, 16, 32, 64}, and there are not enough types to go round. One of them would have to be a typedef for some architecture-specific type, __int64 or something, which is almost certainly going to break expectations in the kernel and/or user-space:
Posted Aug 30, 2020 8:04 UTC (Sun)
by nybble41 (subscriber, #55106)
[Link] (4 responses)
Also, strictly speaking the C standard doesn't require a conforming implementation to provide all (or any) of the fixed-width integer typedefs. Leaving them out would break a lot of existing software, of course. Portable programs should be using the flexible [u]int_leastN_t or [u]int_fastN_t aliases instead, which don't require a specific width—just something greater than or equal to the requested size.
Posted Aug 30, 2020 11:57 UTC (Sun)
by smcv (subscriber, #53363)
[Link]
That's what I'd do if I was designing a 128-bit ABI, but then I'd be breaking the common assumption (particularly in the Linux kernel) that long and pointer are the same size (i.e. long and intptr_t are the same).
Posted Aug 30, 2020 17:56 UTC (Sun)
by khim (subscriber, #9252)
[Link] (2 responses)
Can you list such programs somewhere? I think one screen of 25 lines would succeed if you remove one which not only use these "least" and "fast" types but would actually work if there are no precise int8_t and int32_t types.
Posted Aug 30, 2020 18:29 UTC (Sun)
by nybble41 (subscriber, #55106)
[Link] (1 responses)
In most cases switching from intN_t to int_leastN_t or int_fastN_t is a simple matter of search-and-replace. The exceptions are where programs rely on wrapping at a certain width (applicable only to unsigned values) or map C integer types directly onto external cross-architecture data structures. In the first case you just make the wrapping explicit ((x + y) & 0xffffffff). In the second case it might be necessary to actually parse the data structure from bytes rather than map it directly, but then again you probably needed something similar to deal with endianness and alignment variations anyway.
I suspect the main reason why more programs don't use the more portable types is simply that the exact-width forms are shorter and easier to type. Perhaps it would have been better to standardize on something like int_exactN_t instead to put them on more even footing rather than implicitly encourage less portable code.
Posted Aug 31, 2020 9:42 UTC (Mon)
by pm215 (subscriber, #98099)
[Link]
Posted Aug 29, 2020 11:13 UTC (Sat)
by arnd (subscriber, #8866)
[Link] (3 responses)
Posted Aug 31, 2020 9:18 UTC (Mon)
by geert (subscriber, #98403)
[Link] (2 responses)
A few years ago, someone who worked for the Australian navy told me that, given how low they kept running m68k MVME boxes, he expected the "new" PPC MVME boxes to keep running beyond y2038. So yes, "modern" 32-bit ARM should easily surpass that.
Posted Aug 31, 2020 11:46 UTC (Mon)
by arnd (subscriber, #8866)
[Link] (1 responses)
If they are already on older software releases, updating to modern kernel and glibc is already going to be tricky, and getting worse as time passes. I hope we can still update a lot of the Armv7 systems that are already deployed
Incidentally it seems that the last CPU used on MVME cards (64-bit QorIQ P5020) is at the end of its 10 year expected life, but support for that generation never made it upstream. The 2019 manual for the previous generation (32-bit MVME7100/MPC8641D) lists Linux-2.6.25 as the default, with Linux-2.4 still an option for older machines "beyond 2020".
Posted Aug 31, 2020 12:09 UTC (Mon)
by geert (subscriber, #98403)
[Link]
Posted Aug 29, 2020 11:59 UTC (Sat)
by BirAdam (guest, #132170)
[Link] (5 responses)
Posted Aug 29, 2020 12:14 UTC (Sat)
by mpr22 (subscriber, #60784)
[Link] (1 responses)
Statically linked binaries all the way back to the a.out->ELF horizon often work just fine (modulo being basically a giant ball of security holes... that most crackers probably aren't aware of).
Posted Sep 13, 2020 4:04 UTC (Sun)
by set (guest, #4788)
[Link]
Posted Aug 30, 2020 9:22 UTC (Sun)
by kreijack (guest, #43513)
[Link] (1 responses)
Howvever, most of the problems are not due to the OS, but the new requisites. I think that Windows is capable to allow to work a lot of DOS program of 90 years. But how these program deals with (.e.g) the date after 2000 ? or the long file name ? or the network ?
Posted Aug 30, 2020 18:04 UTC (Sun)
by khim (subscriber, #9252)
[Link]
It's chicken-and-egg problem. Most users want (and some need) long-years-gurantee, but they don't use Linux, they use Windows. And the remaining few enthusiasts don't need such guarantees precisely because they were selected (by distro-makers) from the set of all users precisely by that criteria. As for Linux is widely deployed to a very huge number of architecture... please don't make me laugh: the Linux which is deployed on tens of billions (hundred of billions) devices have nothing to do with the CADT Model which BirAdam complains about. That one is almost exclusively for x86... because yes, only there you can send users to Windows.
Posted Sep 1, 2020 15:10 UTC (Tue)
by atnot (subscriber, #124910)
[Link]
Posted Aug 29, 2020 17:34 UTC (Sat)
by marcH (subscriber, #57642)
[Link] (30 responses)
I keep reading this on LWN and I still don't get it: why would a micro-controller (embedded in a larger SoC or not) with a memory requirement measured in megabytes waste silicon, bandwidth and what else with 64 bits addresses? Doesn't make sense to me.
Maybe this should be read as: "the Linux kernel is losing interest for small/embedded systems".
> There are still MIPS chips coming out from vendors like Loongson and Ingenic and, perhaps surprisingly, still SoCs based on the 20-year-old Armv5 core being introduced.
Posted Aug 29, 2020 19:19 UTC (Sat)
by arnd (subscriber, #8866)
[Link] (12 responses)
My intuition at first was also that 32-bit systems would remain relevant in Linux for much longer, but after looking at it in more detail while working on the y2038 problem, I came to a different conclusion, and I tried to explain this in my presentation in some detail.
The thing is that while low-end systems hang around for much longer than high-end ones, hardware companies tend to discontinue products once nobody wants to buy them because the replacements are both cheaper and better. The low-end 64-bit SoCs with Cortex-A53/A35/A55 using LP-DDR4 are already replacing the high-end of 32-bit Arm32 (and other 32-bit) SoCs with DDR3 and are eating away at that market the cheaper they get.
The low end of 32-bit Linux is also disappearing because code bloat means need increasingly larger memory to do the same things as before. You would not build a system with under 128MB (10 years ago this would have been 16MB) any more unless you are extremely cost-driven and need to save those 20 it would cost to double the memory at the expense of engineering time to fit the product in less RAM. On the other hand, using a microcontroller with an RTOS might let you do the same product with the same engineering cost but even cheaper hardware.
Once the two sides meet in the middle, there is no point of doing new products on 32-bit Linux and we only need to maintain the ones that are still get kernel updates. The exact time frames are speculation, but I'm convinced that the two trends are continuing.
Posted Aug 29, 2020 22:17 UTC (Sat)
by marcH (subscriber, #57642)
[Link]
This is what happens when LWN spoils us with great conference reports with full sentences: we don't feel the need to look at slides and bullet points :-)
Speaking of full sentences, your comment above makes this topic much clearer, thanks! Appreciated.
The 128 Megabytes requirement for OpenWRT is a bit conservative; I retired about 6 months ago a wifi router with 32M and it was still running fine the latest OpenWRT version at the time, no crash observed. Even 128M is quite far from the 4G limit.
I remember when Linksys switched the WRT54G away from Linux to save RAM and cost... is there any more recent example? Not everyone needs/wants to run a complex media server on their wifi router. Or maybe there is none; maybe you're right and hardware has finally become cheaper than software :-)
Unless some hackers "scratch their own itch" some day and attempt to convert some of these well documented (thanks to OpenWRT) routers to some open source RTOS just for fun?
Posted Aug 29, 2020 23:38 UTC (Sat)
by excors (subscriber, #95769)
[Link]
I guess the most common issue is power - the microcontroller can run in standby mode in ~1uA and wake up almost instantly, and 128MB of DRAM can't, so for battery-powered devices there's often no choice. And microcontrollers seem to typically give you a lot more pins for connecting external peripherals directly, and are more likely to include features like low-power wireless protocols, so you might need one for those reasons. It's often not about being cost-driven.
There are the chips in the middle, with a few MBs of RAM and more computational ability than a microcontroller but lower power consumption than a 128MB SoC. They seem to be in the same price range again, so I think they're chosen for their features and power and not price, and they're not going to become obsolete just because DRAM is cheap. That's the area where Linux and RTOSes could potentially compete, and it sounds like you're suggesting Linux should give up and should let the RTOSes win. But even though I don't think they'll become obsolete, I suspect those chips will always be for fairly niche use cases - few products will have exactly the right set of feature requirements and power constraints that mean they can't just use a microcontroller or Linux or both - so it seems fair enough to consider them not worth the effort.
(RTOSes aren't great there because there's no standard abstraction layer to let you port code between different vendors' SDKs, and the development tools are generally very limited (probably no MMU and no Valgrind/ASan so good luck avoiding memory errors), and often the SDKs are just badly written (though they're getting better), which is acceptable for microcontroller firmware but becomes painful when you're writing enough code to fill several megabytes. But Linux isn't great there because it's not designed to scale down that far, and it's probably less painful for the RTOSes to scale up.)
Posted Aug 30, 2020 9:44 UTC (Sun)
by anton (subscriber, #25547)
[Link] (9 responses)
Will applications run on bare metal on these systems, if they have, say, 64MB? If not, what system software will run underneath? Is Linux (the kernel, not a distribution like Debian) really too big for such machines?
Posted Aug 30, 2020 12:03 UTC (Sun)
by arnd (subscriber, #8866)
[Link] (2 responses)
Where I see Cortex-M replace ARMv5 or MIPS32r2, those seem to run an either an environment supplied by the chip vendor, or an RTOS like FreeRTOS, VxWorks, NuttX, or Zephyr. Linux without MMU has filled another niche for a long time, but I don't see it growing in use.
The three most likely scenarios I see for the future of 32-bit Linux would be
Posted Aug 30, 2020 12:21 UTC (Sun)
by james (subscriber, #1325)
[Link] (1 responses)
Posted Aug 30, 2020 16:24 UTC (Sun)
by arnd (subscriber, #8866)
[Link]
Cortex-A35 and A55 are both very nice power-efficient superscalar cores that can run at high clock frequencies and 4-way SMP or larger. A32 just leaves out the 64-bit instructions from A35, which makes it unfit for a lot of the use cases that would otherwise want such a core.
What I find missing is a much simpler design that sacrifices performance and scalability to get close to the power and size constraints of the higher-end Cortex-M parts without losing the MMU at the same time.
Posted Aug 30, 2020 12:46 UTC (Sun)
by excors (subscriber, #95769)
[Link] (5 responses)
64MB sounds like a particularly awkward point, because even if you can squeeze Linux down to fit there wouldn't be much RAM left over for your application, and it's hard to see why you'd bother designing a 64MB system with Linux instead of e.g. a 4MB one with an RTOS (if your application is small and you care about power) or a 256MB one that fits Linux comfortably (if you don't care much about power). (Price presumably isn't a big factor here since DRAM is cheap.)
uClinux could apparently run in 4MB RAM, but I think that's a point where you should really just use an RTOS. If you have a choice, maybe Zephyr which is somewhat Linux-inspired but can run in 8KB RAM and can scale up to MBs and looks less amateurish than some other popular RTOSes. In the rare cases where you do have 64MB, you'll probably have to stick with the RTOS because that's the least unsuitable option.
Posted Aug 30, 2020 13:41 UTC (Sun)
by pm215 (subscriber, #98099)
[Link]
Posted Sep 3, 2020 13:51 UTC (Thu)
by pm215 (subscriber, #98099)
[Link] (3 responses)
So "A-profile means 64 bit" is now wrong from the other direction too :-)
Posted Sep 3, 2020 15:37 UTC (Thu)
by excors (subscriber, #95769)
[Link] (2 responses)
Some of the existing documentation actually refers to the "ARMv8-R AArch32 architecture profile", and the Cortex-R82 is called "ARMv8-R AArch64", so it looks like that's how they're distinguishing it. The term "ARMv8-R" is now ambiguous and can refer to two very different architectures (one with an MMU, one without).
Posted Sep 3, 2020 19:47 UTC (Thu)
by pm215 (subscriber, #98099)
[Link] (1 responses)
If you'd prefer a different definition, Peter Greenhaugh is in the anandtech comments on https://www.anandtech.com/show/16056/arm-announces-cortex... defining Cortex-R as being all about low interrupt latency, tightly-coupled memory and the like. (Low-and-predictable latency has always been why the MPU.)
Posted Sep 4, 2020 8:39 UTC (Fri)
by geert (subscriber, #98403)
[Link]
Posted Aug 30, 2020 0:00 UTC (Sun)
by vadim (subscriber, #35271)
[Link] (12 responses)
For anything larger, 32 bit is increasingly cramped. Take for instance a TV. A modern sort will deal with 4K compressed video, include a web browser, probably do voice recognition... A modern web browser takes huge amounts of RAM that a 32 bit architecture might be able to cope with, but not with a huge amount of headroom. Even a Raspberry Pi today comes with an 8GB RAM option.
Plus, with everyone switching over to 64 bit you might as well go with that and save yourself the trouble with beating your head against issues that were missed because nobody tried compiling on 32 bits lately.
Posted Aug 30, 2020 4:48 UTC (Sun)
by marcH (subscriber, #57642)
[Link] (11 responses)
I don't think there's any formal definition of "micro-controller" but I admit I misused the word. What I meant is "system with a RAM requirements in megabytes".
Now you're raising another, interesting question: will systems with RAM requirements in kilobytes _also_ abandon 32 bits and switch to 64? That would seem like an even bigger waste of silicon.
> For anything larger, 32 bit is increasingly cramped. Take for instance a TV
While the future of 32 bits addresses is debatable, I don't believe that _all_ systems requirements of the future will be measured either in kilobytes or in gigabytes but none in megabytes. A TV is just one example, everyone with a crystal ball tells us that _all_ objects will be smart and connected in the future so I predict a continuum of requirements with no gap between kilobytes and gigabytes.
BTW a wifi router, a smart thermostat and a smart speaker all need less than 1 gigabyte nowadays. Does everyone want a high resolution screen with 3D graphics on their smart thermostat? Does everyone want a wifi router or modem that is also a media server? Did people who bought cars stop using bikes?
> Plus, with everyone switching over to 64 bit you might as well go with that and save yourself the trouble with beating your head against issues that were missed because nobody tried compiling on 32 bits lately.
Will re-using 64 bits hardware become cheaper than maintaining 32 bits software? I agree this is the real question here. Will hardware designers who routinely underestimate the cost of software accept this fact is another interesting question. Now let's fast forward to the future when Linux doesn't support 32 bits anymore. Will no other 32 bits software alternative fill the gap? A bit hard to believe.
If ever, many of us will be retired or dead when 32 bits architectures disappear.
Posted Aug 30, 2020 5:29 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Battery powered devices are still firmly in 32-bit land for now. Although phase-change memory or NVRAM might start to change that.
Posted Aug 30, 2020 8:49 UTC (Sun)
by pbonzini (subscriber, #60935)
[Link] (2 responses)
Probably not, to begin with there is no y2038 issue there. Microcontrollers that need wakeups far in the future typically use a real-time clock which provides D/M/Y dates and second-resolution wakeups; otherwise you count cycles and then 32-bits are enough to measure several seconds in the future.
Posted Aug 30, 2020 22:36 UTC (Sun)
by marcH (subscriber, #57642)
[Link] (1 responses)
I expect 64 bits arithmetic on a 32 bits system to be a bit slow but not really rocket science. A quick internet search seems to confirm that.
Posted Aug 31, 2020 21:44 UTC (Mon)
by nybble41 (subscriber, #55106)
[Link]
In my own extremely informal benchmarks, a series of 100M 64-bit divisions took about 40% longer to complete when compiled as a 32-bit x86 binary vs. the same code compiled for amd64. Both versions were run on the same 64-bit CPU and compiled with clang-9 -O2.
[1] https://github.com/llvm-mirror/compiler-rt/blob/master/li...
Posted Aug 30, 2020 10:26 UTC (Sun)
by vadim (subscriber, #35271)
[Link] (2 responses)
Probably not. But likely not forever.
Say, 3D printers started with Arduino's ATmega, but are increasingly moving on to 32 chips. Because at some point people realized things like "I'd like to take pictures of the print, but that's not really possible on 8K RAM", and "Why am making myself suffer by worrying how much RAM the serial buffer is taking, when I could use something with a few megabytes on it for just a couple bucks more?"
> BTW a wifi router, a smart thermostat and a smart speaker all need less than 1 gigabyte nowadays.
A router will probably use a 64 bit chip, because I'm going to guess that the combination of "fast" and "low memory" is a rare one. Dealing with gigabit speeds requires considerable power. Plus 64 bit architectures tend to come with new instructions that are better at mass processing data.
Smart thermostats and such will probably remain on microcontrollers and not use an OS at all.
> If ever, many of us will be retired or dead when 32 bits architectures disappear.
Yeah, but it's likely Linux won't be needed on those. If you add Linux you likely want a substantial userspace (which now is primarily developed on 64 bits), or want to run a web browser (which is cramped on 32 bits already).
And eventually, when you can get a 64 bit chip for a dollar, it just makes little sense to bother with an old, rarely used architecture where a lot of common software doesn't compile out of the box, even if technically it's a bit wasteful.
Posted Aug 31, 2020 5:49 UTC (Mon)
by marcH (subscriber, #57642)
[Link] (1 responses)
So far I've only witnessed something opposite: time-consuming discussions between highly paid managers about how to save 20 cents on the BoM cost of a PC. Most managers totally oblivious to the software/firmware impact.
I heard the TV industry is even "meaner". BTW I won't make the same mistake again when I buy my second "smart" TV and I will check boot time and responsiveness! The first wasn't even a cheap brand...
Posted Aug 31, 2020 6:26 UTC (Mon)
by vadim (subscriber, #35271)
[Link]
There's also a fierce competition at all levels. Some companies are certainly trying to make the cheapest printer possible, but others know their product will cost $1000 or more and are trying to justify such a price. And the old setup of a text based display and having to laboriously tune everything by hand is increasingly going out of favor. These days you want a pretty UI and as much self-calibration as possible and that is hard to squeeze into the cramped Atmel chips.
Posted Aug 30, 2020 20:31 UTC (Sun)
by iabervon (subscriber, #722)
[Link] (3 responses)
For example, I bet in 2040, all the available 32-bit chips will have predictable instruction latency and power usage, with no branch prediction or speculative execution, because they're fast enough to meet requirements in the worst case, so they might as well have that be the only case. This goal may have also forced out task-switching in favor of having a core per task, leading to Linux not being as compelling on these systems.
Posted Aug 31, 2020 1:22 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
Turns out that the toolchains for 8-bit just suck and you have a hard limit of 64kb for direct addressability. So a switch to 32 bits will cause a hit to the code size, but you're likely not writing anything complex involving tons of pointers anyway.
Posted Aug 31, 2020 3:34 UTC (Mon)
by excors (subscriber, #95769)
[Link]
Posted Aug 31, 2020 5:36 UTC (Mon)
by jem (subscriber, #24231)
[Link]
It's a slow death. You have to take human factors into account, too. A few years ago I met a hardware guy who had designed a new device based on an Atmel microcontroller. This Atmel device was available in two versions, pin compatible with identical peripherals. The only difference was that one version had an ARM core, and the other one had a 8-bit 8051 core. Of course he had chosen the 8051 version, because that was what he was familiar with writing software to (in assembly). The cost of moving to a 32-bit RISC core is essentially negligible today. A RISC-V core can be implemented in 0.28 mm2.
Posted Aug 31, 2020 7:19 UTC (Mon)
by gdt (subscriber, #6284)
[Link] (2 responses)
I keep reading this on LWN and I still don't get it: why would a micro-controller (embedded in a larger SoC or not) with a memory requirement measured in megabytes waste silicon, bandwidth and what else with 64 bits addresses? Doesn't make sense to me. Computer architecture is a balancing act. If you have a 32-bit computer with a low amount of RAM but with the speed of solid state storage and gigabit networking then if you load up the I/O then the small amount of memory versus the buffering needed will lead to the memory allocations fragmenting badly, eventually causing the computer to become unbearably slow, and then unreliable. So the speed of the world outside of the SoC puts a pressure for more memory. Adding more memory alone may not be sufficient, because not all memory is equally addressable, especially for buffering. Add too much memory and the result is rococo wonderfulness as described in this LWN article. Eventually you get to the point where the balancing act gets increasingly constrained, and moving to a bigger tent makes sense. You can see that same broad pressure on SoCs which have no DMA: during a file copy a modern SSD will interrupt immediately the CPU clears interrupts, starving user space. But it really hurts to being paying more money to buy slower, smaller storage.
Posted Aug 31, 2020 8:21 UTC (Mon)
by jem (subscriber, #24231)
[Link] (1 responses)
Posted Sep 1, 2020 9:31 UTC (Tue)
by farnz (subscriber, #17727)
[Link]
Back in the day, you ran the applications that currently use A7 cores on 8051s and similar chips. To a very large extent, this is all a balancing act; if 64 bit cores become cheaper than 32 bit, then hardware will move to 64 bit cores, even though an 8 bit core is plenty.
After all, lots of devices are moving to 32 bit ARM v7-M cores, even though an 8051 is still plenty when you have 2k RAM and 16k Flash, because a 32 bit ARM is nicer to develop for, and the sheer volume of ARM cores means it's now cheaper to buy an ARM device than an 8051.
Posted Aug 31, 2020 18:08 UTC (Mon)
by smoogen (subscriber, #97)
[Link]
Instead it is a lot 'cheaper' in manufacturing to come up with a 64 or 128 bit chip you can use across lines and maybe stick some stuff in front which makes it act like its 8bit or 32 bit ancestor. That means you can shrink the amount of factory space you need which cuts costs.
Posted Aug 29, 2020 17:47 UTC (Sat)
by marcH (subscriber, #57642)
[Link]
That's a surprising definition of a SoC. I've googled a bit and all definitions I found look like this instead: "SoC is a complete processing system contained in a single package". Also found this: "Ultimately, SoCs are the next step after CPUs."
Granted, none of the definitions I found are "exact science" because none of them define when a system is considered "complete". However they all consider off-the-shelf data-center processors as "SoCs" considering their level of integration.
BTW a SoC can by definition embed different architectures in a single chip
Some SoCs could even be running multiple copies of Linux on a single chip. Well, only until Linux stops supporting 32 bits and embedded of course :-)
Posted Aug 29, 2020 18:00 UTC (Sat)
by marcH (subscriber, #57642)
[Link] (4 responses)
Removing code is very hard in general.
- Juniors developers: with the help of project managers, flood code bases with new bugs and Duplication & Divergence (a.k.a copy/paste)
- Experienced developers: review code and try to keep aforementioned flood under control.
- Seniors developers: root cause and fix bugs that were let in. Refactor and _remove_ duplicated or dead code.
It's sad the industry seem to still value new code more than deleted code, should be the other way around. People finding bugs should also be paid much more than people adding them. I digress.
I think the main reason the kernel is high quality is because it's pretty hard to add code to it. I vaguely remember a quote from Linus summarising the job of a maintainer: saying "no".
Posted Sep 4, 2020 9:45 UTC (Fri)
by dvdeug (guest, #10998)
[Link] (3 responses)
An industry is going to value what sells.
Maybe Minix really is a super-reliable system with crystal clear code. Does it run on x86-64? No. Does it run on ARM64? No. Does it run on a Raspberry Pi? No. So I have a super-reliable system I can run in an emulator in a system that valued working over elegance.
For another example, "I just downloaded a file and opened it up" beats "I just downloaded a file and turns out to be TIFF with CCITT T.6 bi-level encoding or a PCX file or use a Microsoft MPEG-4 Version 3 video codec" and I have to dig up code that works (who cares if it's elegant) or give up on viewing it.
There are points when stuff should just go. But if you rewrite Linux filesystem code so it supports ext4 and iso9660 and drops support for all those obsolete and half-supported filesystems like NTFS and JFS and hpfs and VFAT, I don't see why anyone not a kernel programmer should consider that an improvement, even if it did get 0.7% faster. And even among kernel programmers, it seems they're the most likely to have a partition for other operating systems and old drives and disks around with non-ext4 filesystems.
I believe Linus also talks about not breaking code that runs on Linux. It's easy to delete obsolete features if you don't care about code that wasn't updated yesterday.
Posted Sep 4, 2020 17:07 UTC (Fri)
by marcH (subscriber, #57642)
[Link] (2 responses)
Sure but I was writing about something entirely different: removing duplication or _unused_ code, no customer cares about that. This saves maintenance costs and makes adding new features easier yet good luck "selling" this to your average manager in your annual review. I don't know who is Arnd's manager but he seems like a lucky guy ;-)
Same with validation: employees who find bugs before customers save their companies a lot of money and should be rewarded correspondingly. How often have you seen that happening?
There's generally no tracking of who adds the most bugs either. If they really meant business, companies would have a "guilty" field in bug trackers. It wouldn't be rocket science thanks to "git blame" (the command name is a good start...) but I guess "creators" who add new code and bugs are too venerated for that to ever happen. We even have "rock stars", says a lot.
I heard a rumour that Apple is... different in that respect. It seems to achieve some results wrt. to quality.
tl;dr: most companies are still clueless with respect to actual development costs.
Posted Sep 6, 2020 1:43 UTC (Sun)
by dvdeug (guest, #10998)
[Link] (1 responses)
The second line of the article says:
>> Removing code that is no longer useful can be harder, mostly because it can be difficult to know when something is truly no longer needed.
> Same with validation: employees who find bugs before customers save their companies a lot of money and should be rewarded correspondingly. How often have you seen that happening?
https://thedailywtf.com/articles/The-Defect-Black-Market
Besides the subtleties of making it work, there's the questions of financial value. There's a certain point where getting something out today is much better than getting something slightly better out tomorrow, especially when tomorrow is going to bring new hardware you have to run on and thus new bugs.
> most companies are still clueless with respect to actual development costs.
I think that modern capitalism has made many companies worry about today and not tomorrow. Long-term thinking can be discouraged in these projects. There's also developer preferences; most programmers want to write the interesting new code, not spend a week trying to figure why these 10,000 lines of spaghetti code are returning a value that it obviously can't return. There's other developers who will refactor and refactor even when it produces more bugs and less clarity than they started with. Neither encourage companies to go back and clean up.
But I go back to my original comment; people will curse an OS that crashes once a day, but they won't use an OS that doesn't work on their system. Several times in business I've been told how to work about nasty bugs in specialized programs; maybe they got reported upstream, maybe not, but I was told e.g. to twiddle with business numbers until the report printed and then fix them in pen. The upstream is not clueless with the actual development costs in those cases; the users will curse it and work around the bugs, as long as it does what they need. Windows 95 may have sucked, but it was good enough the users tended to stick around despite the bugs.
Posted Sep 6, 2020 19:00 UTC (Sun)
by marcH (subscriber, #57642)
[Link]
If you don't mind cheating then it's much more valuable to sell defects _outside_ the company. Works for both testers and developers.
Spy agencies and criminals wouldn't be doing their work if they were not approaching "vulnerable" developers asking them to add some security "mistakes" in poorly reviewed and tested areas of the code. Easier to hide and deny with an unsafe language like C where intentional memory corruption mistakes are barely distinct from unintentional ones. Even more discreet in a project that does not separate security bugs from other bugs. The only thing difficult to hide is the check/reward.
> There's also developer preferences; most programmers want... Neither encourage companies...
I think management not studying and not questioning what "their programmers want" is a good indicator of "companies being clueless about development costs". "Rock Stars" programmers is of course the extreme version of that.
Posted Sep 1, 2020 8:48 UTC (Tue)
by tdz (subscriber, #58733)
[Link]
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
1234
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
In Arabic, for example, written numerals are little-endian.
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
[2] https://en.wikipedia.org/wiki/Bidirectional_text#Unicode_...
Software and hardware obsolescence in the kernel
- Numbering "compatibility" with other languages of course, and
- All humans of all languages seem interested by the Most Significant digits first; e.g. "rounding".
Software and hardware obsolescence in the kernel
I don't think that technical reasons are compelling enough to have caused this outcome (otherwise we would not have taken >50 years to get here). It seems to be more an issue of network effects (as can be seen by the switch of Power to little-endian). Interestingly, in the heyday of RISC big-endian seemed to be winning (SPARC, PA-RISC, IBM RT (and later Power) and most MIPS were big-endian, only ARM, MIPS-based DecStations (and later Alpha) were little-endian); of these architectures only the little-endian ARM is really successful nowadays; MIPS and Power still exist, but Power now is mainly in the little-endian camp, and MIPS was bi-endian from the start (and looking at popcon.debian.org, little-endian seems to be more popular for MIPS these days).
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Yes, Motorola calls the LSB bit 0 on both the 68000 and the 88000 architectures (88000 was also among the big-endian RISC bunch in practice (selectable in theory)). Both of these architectures have bit-field instructions, which makes bit numbering relevant; on architectures where you have to synthesize bit field operations from shifts, it does not matter for that purpose how the manufacturer numbers the bits.
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
You work out the network effects nicely. And I guess that PCI (and followons) have a stronger network effect than network protocols, because network latencies are so large and bandwidth on most machines so low that you can afford byte reversal easier than when accessing PCI/PCIe peripherals.
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Wol
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
-s This option will byte-swap the filesystem so that it is using
the normalized, standard byte-order (which is i386 or little
endian). If the filesystem is already in the standard byte-
order, e2fsck will take no action.
current byte-order.
Software and hardware obsolescence in the kernel
1. Add non-natitve endian support to ext2, i.e. do byteswapping when needed, protected by a config option,
2. Declare ext2 to be little-endian, and provide an option to migrate the big-endian format to little-endian.
Option 2 was picked, as 1 (when enabled) incurred a high runtime cost due to the conditional byteswapping code, and 2 turned out not that much slower than 1 (when disabled), due to the compiler doing a quite good job in optimizing the code.
After a while, all big-endian ext2 file systems had been migrated, and e2fsck no longer needed the -s option.
Similarly, XFS was declared to be big-endian, as it originated on big-endian SGI machines.
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
2. Storage devices larger than 16 EiB
3. Virtual address spaces larger than 16 EiB
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
https://stackoverflow.com/questions/6716946/why-do-x86-64... )
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
ILP32 LP64 LLP64
8 char char char
16 short short short
32 i./l. int i./l.
64 l.l. long l.l.
ILP32 LP64 LLP64 new thing
8 char char char char
16 short short short short
32 i./l. int i./l. int?
64 l.l. long l.l. __int64?
128 long
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
One clarification, as I think my explanation from the talk wasn't good enough:
Software and hardware obsolescence in the kernel
"The last Armv7 chips, instead, have been released now, but they will still be shipping in 2030 (and in use for long after that). So 32-bit systems will still need to be supported well beyond 2030"
What I actually meant to say here is that
It is possible that RV32 begins to take over from Armv7-A during that time, but I don't see the others (ARC, Xburst2, Xtensa, ...) take a significant chunk of the 32-bit Linux market.
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
https://github.com/voltumna-linux/meta-artesyn/blob/maste... on the other hand does have updates for modern kernels.
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
This being said, OpenWRT is indeed probably the clearest measurement of the current "Linux code bloat" because its userspace requirements are incredibly conservative.
https://openwrt.org/supported_devices/432_warning
Software and hardware obsolescence in the kernel
ARM certainly believes that 32-bit has a significant future. To my surprise, ARMv8-M is a pure 32-bit architecture (it implements a variant of the T32 (Thumb) instruction set); they even developed a new vector extension (Helium) for it. (And yes, I would prefer if they had naming that made such fundamental differences as between ARMv8-A and ARMv8-M more apparent).
Software and hardware obsolescence in the kernel
I don't think of Cortex-M (or MMU-less RV32 for that matter) playing a huge role in 32-bit Linux: unless you add an MMU, the pain of running Linux on these makes it similar or worse than running a simple RTOS that is designed for MMU-less operation from the start. Leaving out FPU, DSP/SIMD, L1$ and DRAM controllers on a given chip tips the scales even more away from Linux.
Software and hardware obsolescence in the kernel
There's the ARM Cortex-A32, which is a 32-bit only ARM v8-A core explicitly below the A35 / A53 / A55 lines. You could argue that this is your option b ("below the Cortex-A7"), or you could argue that this is a modern replacement for the A7.
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
https://community.arm.com/iot/b/internet-of-things/posts/...
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Still, it has branch prediction, so less predictability.
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
[2] https://github.com/llvm-mirror/compiler-rt/blob/master/li...
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/...
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
Software and hardware obsolescence in the kernel
> Besides the subtleties of making it work,...
Software and hardware obsolescence in the kernel