> 29000 transistors? But it's the same as an ARM2 which apparently was full 32bit and had an integer multiplier.
It's a very good point. I think it's worth to ask a few questions in return.
How many years separated the two designs?
Does ARM2 support an equivalent ISA, in terms of features (not encoding)?
For instance, the 8086 has support for BCD integers, specialized instructions for loops, the ability to use its registers as 16 bits or 8bits (doubling the register count in the later case).
Conversely, ARM2 had, for example, a barrel shifter, immediate constants, every instruction being conditional, etc., all of which are absent from 8086.
My point exactly. They have different ISA, and as such cannot be compared on the transistor count alone.
They each correspond to a different era, with different needs, as BCD clearly tells.
If today's HW engineers had a chance to implement a small cpu core with the same tr count, would they come up with the same ISA as the ARM1 or 8086? Would they choose to implement integer division (DIV and IDIV in x86), or not and leave it to software (ARM)? Would they pick CISC, RISC, VLIW, or something else?
> Does the microcode contain any "junk code" that doesn't do anything?
> It seems to! While most of the unused parts of the ROM (64 instructions) are filled with zeroes, there are a few parts which aren't. The following instructions appear right at the end of the ROM
Could it be the signature of the microcode implementor?
> Plainly named but patently cool, eFuel is a synthetic gasoline that burns exactly like the traditional stuff yet has minimal environmental impact.
> But how is eFuel made? [...] the hydrogen is combined with carbon dioxide captured from the air, and through the magic of chemistry it all gets synthesized into methanol, which is then converted into gasoline.
How can this be carbon neutral if it burns like traditional gasoline? Doesn't it produce CO2? Does the synthesis process capture exactly the same amount of CO2 than what is released from combustion?
Also, if it is possible to do this, isn't there also a fuel that would not release CO2 at combustion while consuming CO2 for synthesis?
Your drawing is saved when you leave the page. Dialog boxes are for destructive actions. There is no demo mode - what you're using is the full product.
Wouldn't it be possible for a process to ask to be pinned to a specific CPU core, or the OS to handle programs with extra tags indicating their ISA requirements, so that it could restrict the scheduling to those cores matching the requirements?
About a decade ago, as an intern helping research this, I developed an app to manually tag processes as "big core only" or "little core only" etc. This was for the QuickIA[0], which had a Xeon in one socket and an Atom in the other. It was fun to kick off a gigantic compression task and watch the "expected time to completion" progress bar change dramatically when you migrated the process between sockets.
You all would probably find the "QuickIA Software Support" section interesting, they go through a few issues you run into when you have incompatible micro architectures running in a single system. It also might help illuminate where Intel's head was at during the early research phase of creating a heterogeneous processor.
That's what people generally expected when the whole P-core vs E-core on different microarchitectures design was announced. Instead of going for this, Intel went out of their way to state that there would be no AVX-512 even on P-cores and that's that. Ignoring this obvious solution is part of why I'm so flabbergasted at the situation.
Then they can just say so and spin it as a PR win - "look how security conscious we are these days". Very publicly removing a formerly-headline feature with no explanation and then even failing at that is just mind boggling.
I decided to search for SMP, which stands for Symetric Multi Processing, to verify its definition. This acronym is used for hardware sporting several identical CPUs, which is what we've seen so far in the x86 world.
The opposite is called AMP, for Asymetric Multi Processing. The Wikipedia article on the subject describes several OS level strategies to handle that sort of hardware.
If you are asking him what use case he is describing there, it's dark net markets. Buying and selling of drugs and other items via TOR using crypto currency.
> Most of the good features that people associate with Ubuntu are actually in Debian, with none of the proprietary weirdness that creeps into Ubuntu year over year.
A lot of what you find in Debian also comes from what Ubuntu does. In fact, I believe that many people hired by Ubuntu in the early days were experienced maintainers for Debian.
20 years ago, the problem was all about getting Linux consumer desktop friendly. On the server side, it was mostly OK, people there were not afraid of a TTY, because it was the primary entry point to learning Linux, and Unix in general, whereas in the Windows world, people first approach was (and still is) the GUI. Debian wasn't as good as it is today in the desktop area.
Ubuntu appeared on the market mainly to solve that problem (they were not the first ones to do that), and "leverage" on the acquired expertise to make money.
Nowadays, the money is in servers and IoT, so they are focusing to that segment of the market.
The nature of open source meant that of course, Debian benefits from their work.
The main advantage of Silverblue isn't just toolbox (which isn't originally an Ubuntu tool, btw).
The main advantage of Silverblue is its readonly root fs. Toolbox comes as the provided way for devs to be able to work on top of that feature.
I think Debian has/had some energy devoted to turn the root fs read-only as an option (perhaps in order to move to an ostree based distro, ostree being already available as a package in Sid). Hopefully they'll manage to get it working.
Also, please note that it's not a silver bullet. An immutable FS is a good feature for security (both from malicious adversaries and an oblivious self), but of course it's not enough.
> I got tired of running `pacman -Syu`, rebooting, and having my machine not turn on due to some new kernel change or some video driver change, or something else.
It's a very good point. I think it's worth to ask a few questions in return.
How many years separated the two designs?
Does ARM2 support an equivalent ISA, in terms of features (not encoding)?
For instance, the 8086 has support for BCD integers, specialized instructions for loops, the ability to use its registers as 16 bits or 8bits (doubling the register count in the later case).