Re: Byte Addressability And Beyond

On 03/05/2024 16:40, Michael S wrote:

On Fri, 03 May 2024 08:51:30 GMT
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
 

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

On Thu, 02 May 2024 17:37:47 GMT, Anton Ertl wrote:
 

... MIPS has left the general-purpose computing field.

>
Not so sure that it has. I think the Chinese “LoongArchâ€_
machines are a MIPS derivative.

>
They may have started with MIPS, like several others, but now they are
LoongArch.  Looking in
<https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html#common-memory-access-instructions>,
I don't find anything about byte order, but it says:
>
|LoongArch bit designations are always little-endian.
>

Also, if you want to think of “MIPSâ€_ as a corporate entity, that
would be the company currently known as “Imagination
Technologiesâ€_. It is true they have given up on the MIPS
architecture

>
That's even worse for MIPS than what I know of, which was that it was
used for embedded uses.
>
- anton

 My impression was that embedded MIPS had two main players behind it:
- Microchip on the low end. Measured on Arm scale from about Cortex-M3
class to Cortex-M7 class.
- Cavium on the high end. From Cortex-A55 to not quite Cortex-A73.
 Microchip will continue to sell it for decade at least. Microchip does
not tend to talk openly about directions, however their behavior shows
that their direction right now is away from MIPS and currently toward
Arm.
 

Microchip are good at continuing to produce old devices.  But as you say, they have moved to ARM for 32-bit.
Basically, Microchip managed to ruin embedded MIPS as a choice of processor core.  They used a four-pronged attack here :
1. They picked an older MIPS core for their first PIC32 line, rather than the newer ones that more directly competed with microcontroller ARM cores of the time, thus ensuring that their microcontroller would not be power or performance competitive.
2. They made serious hardware errors in the first chips.  A big marketing feature of the PIC32 was that it supported 480 Mbps USB - but it did not, and it took a very long time to make a fixed version.  In the meantime, the chip was still advertised as being the only available microcontroller with 480 Mbps USB on chip, with am errata saying "reduce USB to 12 Mbps" as a "workaround" for the problem.  This helped the PIC32 gain a reputation as a broken and poor-quality device, which reflected (unfairly) on the core.
3. They called it "PIC32".  If you are familiar with the PIC series, you know they have their good points - they are very robust and reliable microcontrollers (the PIC32 was the exception here), available for decades in hobby-friendly packages.  And they also have the most brain-dead processor core known to man, making the 8051 pleasant in comparison, combined with some of the worst quality and buggiest compilers ever written and sold at ridiculously high prices.  Thus anyone familiar with Microchip PIC devices (most small-systems embedded developers) and unfamiliar with MIPS (most small-systems embedded developers) would assume that the PIC32 core would be horrible to work with and almost impossible to program in reasonable standard C, with the "32" referring to some random part of the architecture rather than the processor width.
4. They set themselves against the open source development tools community by packaging a modified GCC as though it were /their/ compiler.  Every indication that it was not made by Microchip themselves was hidden in the tiniest of small print.  The library that they provided was licensed as strictly as their lawyers could manage - you were not allowed to use it with development tools other than the binaries provided by Microchip.  (You /could/, in theory, get their modified GCC source for the compiler - but only at extreme effort.  It was not quite at the point of delivering the source on open reel tape, but not far off it.)  The modifications that Microchip made to GCC were to disable any kind of optimisation unless you had bought the amazingly expensive version of the development tool license from them.  So most people had to use the devices with no optimisation at all.
At the same time, people were using better ARM cores with full optimisations.  In practice, ARM cores were 10-20 times faster than MIPS appeared to be, thanks to Microchip.  It is no wonder they never caught on.
I'm sure there are other reasons why MIPS failed, despite having cores that were comparable or better than ARM for small-systems embedded devices.  But Microchip has to take a large chunk of the blame, IMHO.