fstrthnscnd

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?

> 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).

> 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?

Great work!

Answering myself:

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.

> 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?

You should probably show a confirmation box when leaving the page - if that's possible - unless that feature is disabled in demo mode?

Perhaps there are undisclosed security implications?

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?

What is it about?

> for example, just to add two numbers you have to shift mantissas and 6502 has no fast way to do it

How much work is there to do beside shifting mantissa? (A shift is also necessary for many fixed point calculations).

But, wasn't the original argument discussing the merits of Bash as a shell? So you're saying that Bash is great as a shell because it's a shell?

so it's not Bash by itself which is great, it's POSIX shells?

> they are part of POSIX (a Standard which is implemented by multiple OS) and therefore often available

That's not an intrinsic property of Bash.

> - you can use them to compose programs written in different languages

> - you can easily connect the output of one program with the input of another (pipes)

This last point subsumes the previous one. So basically, you're saying Bash is great because it's a shell?

> 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.