MIPS (was: Byte Addressability And Beyond)

Michael S <already5chosen@yahoo.com> writes:

On Sun, 5 May 2024 00:26:49 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>

On Sat, 04 May 2024 15:18:37 GMT, Scott Lurndal wrote:
 

Personally I prefer ARM64 architecture over MIPS64 by a considerable
margin, in almost all respects ... 

 
I know MIPS (like SPARC) originated in that brief window when it was
thought that delayed branches were a good idea, and so it remained
saddled with that (mis)feature for the rest of its life.

>
Delay slot was deprecated back in MIPSr6,  almost a decade ago.

MIPS has a number of other misfeatures that made us disable dynamic
superinstructions in Gforth and are a problem for other code-copying
code generators:

First and foremost, the architectural load delay slot (and, I think,
similar constraints wrt multiply and divide instructions and/or
MFHI/MFLO) mean that, unlike for every other architecture we have
looked at (including IA-64), you cannot just concatenate two pieces of
code which do work when they are connected with an indirect jump.

Another nasty property of MIPS is the way direct jumps and calls are
encoded: The target address is assembled from IIRC the top 6 bits of
the current PC and the rest of the address as absolute number in the
instruction.  This means that the call/jump would not show up as
non-relocatable in Gforth's sanity tests, but if copied a piece of
code to a target area in a different 256MB-segment, it would fail.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
  Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>