Re: Crazy cross-MIPS-boards stunts possible?

["Maciej W. Rozycki" <macro%linux-mips.org@localhost>]

On Wed, 2 Dec 2020, Swift Griggs wrote:

> > embedded applications.  A newer ABI (NUBI) was outlined to phase out the old
> > o32/n32/n64
> 
> What version of the MIPS ISA did n64 come along, was that MIPS IV ?

 It was MIPS III, the first 64-bit ISA.  Likewise n32, a 64-bit ILP32 ABI.  
There are only relatively minor differences between MIPS III and MIPS IV: 
a couple of new instructions added (most notably conditional moves, some 
FP stuff), the expansion of FP condition flags from 1 to 8, and COP3 
support removal.

> > Then there were further attempts with the nanoMIPS architecture,
> 
> nanoMIPS... never heard of that. Cool. I see notes about qemu deprecating
> support for it and not too much else.

 It taped out actually, look for I7200 and MediaTek.  E.g.:

<https://www.anandtech.com/show/12699/mips-announces-i7200-32bit-cpu-with-new-nanomips-isa>

That was it though really.  Software resources may have been lost as they 
have never got to being upstreamed; `archive.org' may have recorded 
something.  I have copies of public ISA documentation if for historical 
interest; they may have been publicly archived as well.

> > including a functional toolchain, but it all has gone once the latest
> > incarnation of the owner of the architecture went bust earlier this year.
> 
> Sounds like an Amiga story.

 Yeah, sadly.

> > the remaining board material, including in particular blank PCBs, was moved
> > to the US. It was then used to assemble more boards sometime in 2000s.
> 
> Hmm, I used to work near LSI on Garden of the Gods in Colorado Springs. I
> wonder if any of the components or assembly touched that site.

 I don't know.  MIPS Technologies (MTI) acquired the Copenhagen site along 
with staff from LSI back in late 1998.  See e.g.:

<https://www.hpcwire.com/1998/11/20/mips-technologies-opens-development-center-denmark/>

Given its three-year lifespan the branch was short-lived really.

> > Given the persistent demand around 2008 a new, software-compatible variant
> > was designed, called Malta-R,
> 
> Was that by the same group of folks or a new company? I assume all this stuff
> was for profit and not any kind of open-hardware thing, or was it?

 Same company (MTI), different people, i.e. not the original designers, 
though some of those involved with the rework were already on board in the 
MIPS Denmark days.  The company had a convoluted history.

 Boards were for in-house development support as well as customers.  They 
were not meant themselves as a source of profit; rather they were tools, 
sometimes sold, sometimes lent, sometimes given away if the company saw an 
advantage in it.  Royalties on MIPS architecture and MIPS core licences 
were the actual source of profit, similarly to ARM's model of business.

> > You may have a hard time finding one that someone wants to get rid off, as
> > usually with this kind of stuff.
> 
> Understood, but sometimes patience pays off. SGI MIPS hardware has fluctuated
> over the years of the used market but the general trend seems to be upward on
> price and downward on availability.

 The difference is SGI hardware was end user stuff.  I don't recall ever 
seeing any development hardware of this kind being sold second-hand, not 
at least among the several items of my various level of interest I have 
been watching out for for years now.  I guess they have been either kept 
in storage, or decommissioned and given away to employees or scrapped.

> > The SEAD-3 has an FPGA rather than a core card, so (unlike the Malta) it
> > always has a soft CPU core.
> 
> The Vampire "68080" in my Amiga 500 is the same idea. Super-fast 68k clone
> with some SIMD features nicely integrated. I think they made a standalone
> Vampire, now, too. Won't run NetBSD though because of some MMU silliness.

 With Malta (equipped with a suitable core card) or SEAD-3 you would also 
download a replacement CPU bitfile for the FPGA over USB if one that was 
already in the flash wasn't suitable for your purpose.  The bitfile port 
presented itself as a bi-directional USB printer, so you could just `cat' 
the bitfile to it and then read the status back, also with `cat', which 
reported the CPU type, RTL options and the date of synthesis.

 For external customers the bitfiles were encrypted and had to match the 
individual key stored within each SEAD-3 board or Malta core card, so that 
each such bitfile could only be used with the single board it has been 
made for.  For in-house use they were unencrypted and readily available 
for everyone on-board, as we used to swap them frequently.  Great for CPU 
bring-up.

> > They are development boards after all, so they had to suit whatever the
> > customer's requirements were.
> 
> Bi-endianness is still cool and still not widely available enough, IMHO, even
> if you old  MIPS dogs think it's old hat. :-)

 Huh?  I thought everyone had it these days. ;)

  Maciej