MIPS Becomes RISC-V • Hacker News Board

Re: MIPS Becomes RISC-V

#181

Post by [deleted] » Tue, Mar 09, 2021, 5:21 AM UTC

bogomipz wrote: post #150

retrac wrote: post #84

Earlier quoted context omitted.

That's how IBM implemented the AS/400 platform. Everything compiled down to a processor-agnostic bytecode that was the "binary" format. That IR was translated to native code for the underlying processor architecture as the final step. And objects contained both the IR and the native code. If you moved a binary to another host CPU, it would be retranslated and run automatically. The migration to POWER as the underlyin…

This is really fascinating. Is there a reason why we haven't seen more of this approach as it seems like it was pretty successful for IBM. Is there a practical reason that would prevent an open source project from building something similar?

[deleted]

Re: MIPS Becomes RISC-V

#182

Post by indolering » Tue, Mar 09, 2021, 5:49 AM UTC

KirillPanov wrote: post #158

segfaultbuserr wrote: post #152

Earlier quoted context omitted.

> In 2010 MIPS wanted $2 million from Berkeley to allow them to use the MIPS instruction encodings Do you have a source for that? I see that you're a RISC-V expert, and I know MIPS, Inc. is notorious for patent lawsuits, so I trust you. I'm just curious about the Berkeley project.

Patterson always smirks when people ask him what the "V" is for, and mumbles an uncharacteristically vague reply (something about it being the fifth chip project he's worked on or something like that...) It's no coincidence that MIPS used roman numerals for its architectures, MIPS-I, MIPS-II, MIPS-III, MIPS-IV, and MIPS-V. So instead of using MIPS-V Berkeley created RISC-V. You aren't going to get anybody who was inv…

I think you understate the level of IP vetting RISC-V has undergone. All but 6 instructions in the RV32G instruction set could be found in implementations that were at least 20 years old; the remaining six were novel [1].

RISC-V owes MIPS about as much as MIPS owes Patterson. MIPS-V was already ~15 years old when RISC-V was first used in the classroom. RISC-V purposefully paired back the layers of marketing cruft and failed experiments that had grown over Patterson et al.'s original RISC architecture.

There is less confidence in the extensions, but as RISC-V turns 10 ... patent trolls had better hurry if they want to extort anyone based on the ISA alone.

[1]: https://live-risc-v.pantheonsite.io/wp-content/uploads/2016/...

Re: MIPS Becomes RISC-V

#183

Post by retrac » Tue, Mar 09, 2021, 5:53 AM UTC

Fordec wrote: post #59

MaxBarraclough wrote: post #36

Everyone's right to celebrate the success of RISC-V, but part of me thinks it's a shame that there's relatively little architectural diversity ( edit I should have said ISA diversity ) in modern CPUs. MIPS, Alpha, and Super-H, have all but faded away. Power/PowerPC is still out there somewhere though. Apparently they're still working on SPARC, too. [0] At least we'll always have the PS2. ...until the last one breaks,…

We need diversity for solving different problems, not for diversity sake. What problem did MIPS solve in a unique way that others didn't? Because it wasn't desktop, mobile, embedded, graphics or AI.

> What problem did MIPS solve in a unique way that others didn't?

The MIPS R2000 was debatably the first commercial RISC chip. It solved whatever problem you needed a really fast CPU for in 1985. The alternatives on the market were the Intel 386 and the Motorola 68000. The Intel 386 at 16 MHz did about 2 MIPS (heh - millions of instructions per second) with 32 bit integer math. At 16 MHz, the R2000 did about 10 MIPS. Even accounting for RISC code bloat, that's 3 - 4x faster.

Note how there were only two competitors selling 32-bit designs in the market they entered. I think that's probably the biggest impact of MIPS. They actually sold the chip! They wanted companies to design their own computer systems around it. Use it in an embedded device. Whatever. That was not the norm c. 1985 - 1988 for high-end silicon.

There were machines faster than the 386 or 68020 at that time. You could buy one of the fast microprocessor-based VAXes recently introduced. Or if not too squeezed for office space and with a blank cheque, one of the super-minis like a real VAX or IBM's new "mini-mainframe". After '86, maybe you'd buy one of the other RISC options, like SPARC or PA-RISC.

Whatever you bought, it would be the whole system. Take it or leave it. DEC would not sell you something like a CVAX processor all by itself just so you can build it into a product that will compete against them. (Well, they would sell you one, just not at a price you could afford if you aren't a defence contractor.)

Both DEC and SGI would use MIPS processors in their workstations of the late 80s, as did some less well-known names. The embarrassment of having to use a competitor's processor to sell a decently fast and affordable UNIX workstation would inspire DEC to create the Alpha. In this vein of "we'll sell it to whoever wants to buy it!" MIPS was also doing ARM-style core IP licensing, before ARM did. That's probably part of why MIPS was so prominent as an embedded architecture in the late 90s and early 2000s, in everything from handhelds to routers to satellites.

Re: MIPS Becomes RISC-V

#184

Post by monocasa » Tue, Mar 09, 2021, 6:07 AM UTC

projektfu wrote: post #141

monocasa wrote: post #93

Earlier quoted context omitted.

No, they're probably talking about how modern z/Arch and POWER cores share a lot of HDL source these days.

Yeah, I figured that most of the previously microcoded CISC instructions were basically software at this point.

What's probably closest to the truth is that they have a very similar set of micro ops that they both translate to internally.

Re: MIPS Becomes RISC-V

#185

Post by thristian » Tue, Mar 09, 2021, 6:17 AM UTC

joshgoldman wrote: post #138

If you did Nintendo 64 assembly, then you know about these guys Disclaimer: I knew someone who worked at Nintendo

Super Mario 64 has a character named MIPS the Rabbit[1] named after the N64's processor architecture.

[1]: https://www.mariowiki.com/MIPS

Re: MIPS Becomes RISC-V

#186

Post by kindall » Tue, Mar 09, 2021, 6:33 AM UTC

tachyonbeam wrote: post #148

TorKlingberg wrote: post #122

Earlier quoted context omitted.

I don't know if MIPS is the same, but I worked on an other architecture where NOP is 0x0, and it had an interesting effect. If you called an uninitialized function pointer, and it happened to point into zero:ed out memory, the CPU would execute NOPs for a good while until it hit something else. If that something else was code, it would start executing some function from the start, but with garbage arguments. It would…

Seems like a better design choice would be to have instruction 0x0 throw some kind of page fault violation or other exception the OS can catch then.

Shades of the 6502, where 0 was BRK

Re: MIPS Becomes RISC-V

#187

Post by simcop2387 » Tue, Mar 09, 2021, 6:35 AM UTC

chrisseaton wrote: post #131

cptskippy wrote: post #117

Earlier quoted context omitted.

> it's yet to leave the lab. You can buy them on Amazon. https://www.amazon.com/dp/B08W2J9B8J https://www.mouser.com/ProductDetail/?qs=pUKx8fyJudB1sOWbbEn...

> You can buy them on Amazon. > Currently unavailable. We don't know when or if this item will be back in stock. Clearly not!

Shows as in stock on the 15th for me. I suspect there's some bot arbitrage going on there.

Re: MIPS Becomes RISC-V

#188

Post by pantalaimon » Tue, Mar 09, 2021, 6:38 AM UTC

chrisseaton wrote: post #131

cptskippy wrote: post #117

Earlier quoted context omitted.

> it's yet to leave the lab. You can buy them on Amazon. https://www.amazon.com/dp/B08W2J9B8J https://www.mouser.com/ProductDetail/?qs=pUKx8fyJudB1sOWbbEn...

> You can buy them on Amazon. > Currently unavailable. We don't know when or if this item will be back in stock. Clearly not!

How about these then

https://aliexpress.com/item/4000221852639.html

https://aliexpress.com/item/1005001762637137.html

https://aliexpress.com/item/4000394347886.html

Re: MIPS Becomes RISC-V

#189

Post by mycall » Tue, Mar 09, 2021, 6:41 AM UTC

brucehoult wrote: post #135

hamburglar wrote: post #113

Earlier quoted context omitted.

- the NOP instruction is 0x0 :)

RISC-V deliberately made sure both all 0s and all 1s are forever illegal instructions, in all instruction lengths.

Specifically to avoid infinite loops?

Re: MIPS Becomes RISC-V

#190

Post by dragontamer » Tue, Mar 09, 2021, 7:18 AM UTC

sujayakar wrote: post #169

dragontamer wrote: post #109

Earlier quoted context omitted.

> Very cool! Independent of the cool use of `aesenc` and `aesdec`, the features for skipping ahead in the random stream and forking a separate stream are awesome. Ah yeah, those features... I forgot about them until you mentioned them, lol. I was thinking about 4x (512-bits per iteration) with enc(enc), enc(dec), dec(enc), and dec(dec) as the four 128-bit results (going from 256-bits per iteration to 512-bits per ite…

> Bit-reverse is unimplemented on x86 for some reason, but bswap64() is good enough. You totally nerd-sniped me! I implemented a basic "reverse 128-bit SIMD register" routine with `packed_simd` in Rust. The ideas to process 4 bits a time: let lo_nibbles = input & u8x16::splat(0x0F); let hi_nibbles = input >> 4; Then, we can use `pshufb` to implement a lookup table for reversing each vector of nibbles. let lut = u8x16…

> This is neat! How do you choose odd numbers so the final generated numbers are high quality?

This was years ago, so I forget the details. But it was along the lines of...

    uint32_t hash(uint32_t seed, uint32_t k1, uint32_t k2){
        return (brev(seed*k1) * k2);
    }

    uint32_t evaluate(uint32_t seed, uint32_t k1, uint32_t k2){
        return popcnt(hash(seed, k1, k2) ^ seed);
    }

The goal is to find the values of k1 and k2 that resulted in an evaluate(seed, k1, k2) close to 16-bits (aka: 50% of bits change, the definition of "avalanche condition"). There's probably some statistical test I could have done that'd be better, but GPUs have single-cycle popcount and single-cycle XOR.

I forgot exactly which search methods I used, but note that a Vega64 GPU easily reaches 10 Trillion-multiplies / second, so you can exhaustively search a 32-bit space in a ~millisecond, and a 40-bit space in just a couple of seconds.

You can therefore search the values of k1 and k2 ~8-bits at a time every few seconds. From there, plug-and-play your favorite search algorithm (genetic algorithms? Gradient descent? Random search? Simulated annealing?).

--------

After that, I'd of course run it through PractRand or BigCrush (and other tests). In all honesty: random numbers (with bottom bit set to 1) from /dev/urandom are already really good.

---------

Exhausting the 64-bit space seems unreasonable however. I was researching FNV-hashes (another multiplication-based hash), trying to understand how they chose their constants.