Some unlikely 2021 predictions
Some unlikely 2021 predictions
Posted Jan 7, 2021 0:37 UTC (Thu) by jedix (subscriber, #116933)Parent article: Some unlikely 2021 predictions
Nvidia will realise they can avoid the GPL by writing graphics driver in BPF and start accepting cryptocurrency as payment for devices.
Someone will write a Twitter to BPF translation layer.
Systemd will be reimplemented in BPF.
Processors and phones will be sold with known hardware bugs to ensure upgrading.
Posted Jan 7, 2021 1:43 UTC (Thu)
by hisdad (subscriber, #5375)
[Link] (2 responses)
Posted Jan 7, 2021 8:26 UTC (Thu)
by edeloget (subscriber, #88392)
[Link] (1 responses)
I would oppose such a change, as it seems it would break my own workflow and it looks like a kernel ABI regression...
Posted Jan 7, 2021 15:10 UTC (Thu)
by georgm (subscriber, #19574)
[Link]
Posted Jan 7, 2021 17:04 UTC (Thu)
by jafd (subscriber, #129642)
[Link] (7 responses)
I'm sure you meant "will continue to be sold", but otherwise concur with the sentiment.
Posted Jan 10, 2021 3:44 UTC (Sun)
by NYKevin (subscriber, #129325)
[Link] (6 responses)
I'm not a hardware expert, but my simplified and (probably) wrong understanding is as follows: You can't economically turn out perfect silicon every time. Instead, the production process has a certain percentage of errors, and you try to lower this percentage as much as possible, but eventually you start running into diminishing returns. The manufacturer (hopefully) discovers those errors autonomously with a standardized testing process, but then you have to decide what to do with the bad silicon:
1. Throw it away (or recycle it, to the extent that it is practical to do so).
Option #1 is obviously the least profitable option, and options 2-4 can all be accurately described as "selling silicon with known hardware bugs." But IMHO only option #4 is actually dishonest. I also tend to imagine that #4 is rare, at least for the serious manufacturers. Consider how easily the FDIV bug was found - there's always going to be some person who is stress testing your hardware in a "weird" configuration, and if there's a bug, that person has a fairly good chance of finding it.
(OTOH, Spectre took multiple decades to find, and was endemic across the entire industry for that whole time, so maybe I'm a bit optimistic here.)
Posted Jan 10, 2021 9:46 UTC (Sun)
by Wol (subscriber, #4433)
[Link] (4 responses)
For example, I have a 3-core Athlon. I suspect it's actually a 4-core, but the fourth core failed QA and was disabled. Fine, I bought and paid for a 3-core, so I got what was advertised.
Spectre, on the other hand, was a design flaw - the chip did exactly what was claimed. The problem is it ALSO did something else ...
Similar to the Zilog Z80, actually, except they found the bug before it shipped - how many people remember (or realised) that although it had a RightShift instruction, it didn't have a LeftShift? They deleted it from the spec because it was buggy.
So some people investigated, and discovered that the instruction code for LeftShift actually did a LeftShiftAndIncrement :-) Which - I believe - found its way into the spec because people used it ... :-)
Cheers,
Posted Jan 10, 2021 11:14 UTC (Sun)
by jem (subscriber, #24231)
[Link] (3 responses)
You are again repeating this myth that the "Shift Left Logical" instruction is missing from the Z-80 because it was found to be buggy. Yes, the Z-80 only has three shift instructions, SLA, SRA, and SRL. The SLL instruction is missing because it is not needed: the SLA (Shift Left Arithmetic) does the same thing. Only right shifts differ between arithmetic and logical shifts.
The Z-80 has a lot more undocumented instructions, none of which are bugs. They just work the way they do because of how the processor was wired. Zilog did not intend them to be used, but also did not want to waste silicon to disable them is such a simple processor.
Posted Jan 10, 2021 16:59 UTC (Sun)
by Wol (subscriber, #4433)
[Link] (2 responses)
So the question remains. WHY did Zilog not want SLL to be used? And I hate to say it, but the *obvious* explanation is it was buggy. Especially as the instruction quite clearly existed, and *almost* worked. Three instructions is not "logically complete". And ime, not being logically complete is *asking for trouble*. What happens if an assembler-writer uses SRL, and then also uses SLL because it's the logically obvious instruction? PEOPLE DON'T READ SPECS - THEY JUMP TO CONCLUSIONS, and it's very likely people will just assume SLL exists.
(I'm aware there was a whole bunch of 16-bit instructions that happily worked on pairs of 8-bit registers but weren't documented, and also I think 8-bit instructions that worked on the 16-bit registers, but I'm not aware of any other instruction that clearly should have existed and didn't.)
Do you have any *evidence* as to why SLL wasn't documented? Or are you just looking at what happened after the chip was released, and jumping to a different conclusion from other people?
Cheers,
Posted Jan 10, 2021 18:39 UTC (Sun)
by jem (subscriber, #24231)
[Link]
Tell that to CPU architects. Motorola's 6800 had the same three shift instructions as the Z-80. The 80x86 processors also only have three shift instructions. The 8086 User's Manual states: "SHL and SAL (Shift Logical Left and Shift Arithmetic Left) perform the same operation and are physically the same instruction. ARM has the LSR, LSL, and ASR. RISC-V has SRLI, SLLI, and SRAI (shift right/left logical/arithmetic immediate). MIPS? Same thing.
It is a well known fact that an arithmetic shift only differs from a logical shift when shifting "right", i.e. towards the less significant bit positions. This has been known for decades, and I doubt the engineers at Zilog were stupid when they added these instructions. So to me, the *obvious* explanation was that Zilog copied the three instructions from the Motorola 6800, and left the op code that was left unused to do what it happened to do.
What Zilog *should* have done was to do what Intel did later with the 8086: document the assembler mnemonic SLL as an alias for SLA. Or used the name SLL instead of SLA.
>And ime, not being logically complete is *asking for trouble*. What happens if an assembler-writer uses SRL, and then also uses SLL because it's the logically obvious instruction?
What *I* think is asking for trouble is when an assembler writer jumps to conclusions about the instruction set. "Ah, there is an error in the documentation, Zilog forgot to document the SLL instruction. Ok, let's use the *obvious* opcode for that." And the ship the assembler without testing it.
>Do you have any *evidence* as to why SLL wasn't documented?
Do *you* have any evidence for your original claim? That Zilog didn't intend to design their processor according to industry practice at the time, and they really intended to define four shift operations, of which two are identical? And with a stroke of extremely good luck they could just drop the SLL instruction from the documentation, when they realized at the last moment that it didn't work as expected. What are the odds of that?
Posted Jan 12, 2021 22:43 UTC (Tue)
by floppus (guest, #137245)
[Link]
Sure, you can argue it'd be more parsimonious for the two opcodes to do exactly the same thing, but the undocumented function is occasionally useful to save a byte and four clock cycles.
Whether the undocumented function was intentional or not, who knows... but if it were unintentional, you'd expect that the result would be (x<<1)|(x>>7), or (x<<1)|CF, or (x<<1)|(x&1), or something even weirder, rather than (x<<1)|1.
If you simply want your assembler to emit an SLA opcode whenever you write SLL, that's an issue with the assembler, not the hardware. ;)
Posted Jan 10, 2021 13:44 UTC (Sun)
by excors (subscriber, #95769)
[Link]
Also not an expert, but I think you're conflating two different classes of issue:
1) Errors in the design. Often bugs in the HDL code that defines the chip's behaviour and that were not detected by static analysis or by testing in simulation; sometimes bugs that are outside of the logic you were testing, e.g. a crypto block that leaks secrets to an attacker who's precisely monitoring the power lines.
If you discover those issues while running tests on real silicon, it takes many months and millions of dollars to fix the design and produce a new revision of the silicon. It's usually possible, and far cheaper and quicker, to develop a workaround in software(/microcode/firmware/etc), so CPUs typically come with lists of dozens or hundreds of errata that the relevant software developers need to be aware of. In extreme cases the workaround might be to disable a major hardware feature (like TSX in Haswell), though usually the workarounds are much less painful.
If you're producing a new revision of the silicon anyway (e.g. to fix an unworkaroundable bug, or for a new chip with new features), but you have a good software workaround for a particular errata, you might still choose not to fix that errata. 'Fixing' the design risks introducing new bugs (which may delay the new revision for months and cost millions more), so it's safer to leave it alone, and the errata can persist for a long time.
2) Random defects in the fabrication of each chip, because you're pushing the manufacturing technology to the limit and it's a messy physical process and the atoms don't all go where you want them to. In that case you can turn off (i.e. configure the hardware/microcode/firmware/software/etc to not use) the bad parts of the silicon, or run at a lower frequency / higher voltage that doesn't trigger the fault. You get chips with a lot of variation in capabilities and power efficiency, then the marketing people work out how to divide them up neatly and sell them at different prices.
All of those practices will continue because they're sensible economic tradeoffs, and because computers would be unaffordable if customers insisted on perfect hardware.
Posted Jan 7, 2021 20:03 UTC (Thu)
by NYKevin (subscriber, #129325)
[Link] (3 responses)
The gaming industry already does this at the software level. For now, they have not yet realized that they can charge for the day 1 patch, but it's only a matter of time IMHO.
(Related: Even now, they will sell you a game for $60, then sell you the remaining 3/4 of the game for N easy payments of $1.99.)
Posted Jan 9, 2021 6:51 UTC (Sat)
by nilsmeyer (guest, #122604)
[Link] (2 responses)
I'm not sure about that. So far the software world has been mostly untouched by it, but you have a legal right to get a product that is in working order when you pay for it. At the moment, software quality issues are often seen as force majeure, an accident. Even the language used is often invoking that image, "computer bug", "data leak" and so on. What it really is is often human error. And there are real costs associated - I'm mostly talking about the b2b sphere here but what would happen if everyone who bought a buggy video game demanded a refund?
Posted Jan 9, 2021 12:22 UTC (Sat)
by mpr22 (subscriber, #60784)
[Link] (1 responses)
It depends. How buggy is "buggy"?
Posted Jan 9, 2021 17:30 UTC (Sat)
by Wol (subscriber, #4433)
[Link]
I bought a Terry Pratchett game for Win95 - I don't think I got much further than the first few "rooms" whatever they were. And inasmuch as I could find reports for it, it was very temperamental about the hardware, and advice was "re-install 95, install the game, don't install anything else". Not good news if you don't have a spare PC ...
Cheers,
Some unlikely 2021 predictions
that doesn't block when it runs out of zeros.
..
Some unlikely 2021 predictions
> that doesn't block when it runs out of zeros.
> ..
Some unlikely 2021 predictions
Some unlikely 2021 predictions
Some unlikely 2021 predictions
2. Turn off the bad parts of the silicon, and sell the portion you didn't turn off at a discount.
3. Use firmware or microcode to correct the problem, and (if performance is impacted) sell it at a discount.
4. Sell it as-is and hope nobody notices.
Some unlikely 2021 predictions
Wol
Some unlikely 2021 predictions
Some unlikely 2021 predictions
Wol
Some unlikely 2021 predictions
Some unlikely 2021 predictions
Some unlikely 2021 predictions
Some unlikely 2021 predictions
Some unlikely 2021 predictions
Some unlikely 2021 predictions
Some unlikely 2021 predictions
Wol