Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MIPS Becomes RISC-V

eejournal.com

Post reply on HN
Print view View original

101–110 of 225 posts

Re: MIPS Becomes RISC-V

#101

Post by sujayakar »

dragontamer wrote: post #78
sujayakar wrote: post #56

Earlier quoted context omitted.

I'm very interested in this space! I've been hacking on some open-source libraries around these ideas: rsdict [1], a SIMD-accelerated rank/select bitmap data structure, and arbolito [2], a SIMD-accelerated tiny trie. For rsdict, the main idea is to use `pshufb` to implement querying a lookup table on a vector of integers and then use `psadbw` to horizontally sum the vector. The arbolito code is a lot less fleshed out…

Cool stuff! I'll give it a lookover later. A few years ago, I wrote AESRAND ( https://github.com/dragontamer/AESRand ). I managed to get some well-known programmers to look into it, and their advice helped me write some pretty neat SIMD-tricks. EX: I SIMD-implemented a 32-bit integer -> floating point [0.0, 1.0] operator, to convert the bitstream into floats. As well as integer-based nearly bias-free division / modul…

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.

> My current home project is bump-allocator + semi-space garbage collection in SIMD for GPUs. As far as I can tell, both bump-allocation and semi-space garbage collection are easily SIMDified in an obvious manner. And since cudamalloc is fully synchronous, I wanted a more scalable, parallel solution to the GPU memory allocation problem.

This is a great idea. I wonder if we could speed up LuaJIT even more by SIMD accelerating the GC's mark and/or sweep phases...

If you're interested in more work in this area, a former coworker wrote a neat SPMD implementation of librsync [1]. And, if you haven't seen it, the talk on SwissTable [2] (Google's SIMD accelerated hash table) is excellent.

[1] https://github.com/dropbox/fast_rsync

[2] https://www.youtube.com/watch?v=ncHmEUmJZf4

Re: MIPS Becomes RISC-V

#102

Post by skissane »

retrac wrote: post #84
elihu wrote: post #74

Earlier quoted context omitted.

I wish the barriers to using new architectures were lower. For instance, suppose binaries were typically distributed in a platform-agnostic format, like LLVM intermediate representation or something equivalent. When you run your program the first time, it's compiled to native code for your architecture and cached for later use. I realize I've sort of just re-invented Javascript. But what if we just did away with nati…

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…

> That's how IBM implemented the AS/400 platform. Everything compiled down to a processor-agnostic bytecode that was the "binary" format

Originally, AS/400 used its own bytecode called MI (or TIMI or OMI). A descendant of the System/38's bytecode. That was compiled to CISC IMPI machine code, and then after the RISC transition to POWER instructions.

However, around the same time as the CISC-to-RISC transition, IBM introduced a new virtual execution environment – ILE (Integrated Language Environment). The original virtual execution environment was called OPM (Original Program Model). ILE came with a new bytecode, W-code aka NMI. While IBM publicly documented the original OPM bytecode, the new W-code bytecode is only available under NDA. OPM programs have their OMI bytecode translated internally to NMI which then in turn is translated to POWER instructions.

The interesting thing about this, is while OMI was originally invented for the System/38, W-code has a quite different heritage. W-code is actually the intermediate representation used by IBM's compilers (VisualAge, XL C, etc). It is fundamentally the same as what IBM compilers use on other platforms such as AIX or Linux, and already existed on AIX before it was ever used on OS/400. There are some OS/400-specific extensions, and it plays a quite more central architectural role in OS/400 than in AIX. But W-code is conceptually equivalent to LLVM IR/bitcode. So here we may see something in common with what Apple does with asking for LLVM bitcode uploads for the App Store.

> 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

Not always true. The object contains two sections – the MI bytecode and the native machine code. It is possible to remove the MI bytecode section (that's called removing "observability") leaving only the native machine code section. If you do that, you lose the ability to migrate the software to a new architecture, unless you recompile from source. I think, most people kept observability intact for in-house software, but it was commonly removed in software shipped by IBM and ISVs.

Re: MIPS Becomes RISC-V

#103

Post by makomk »

slezyr wrote: post #88
mortenjorck wrote: post #5

This is more or less analogous to Blackberry moving to Android, isn’t it? Storied, old-guard tech company loses most of its market share, trades in its first-party stack for a rising open-source alternative. Is MIPS still a big enough name to make this much of a coup for RISC-V? Or is this the last-ditch effort of a fallen star of the semi market?

Check your router's CPU. I own 4 routers and all of them use MIPS. RISC-V is more like Graphene, it's yet to leave the lab.

Home routers used to be one of the last holdouts of MIPS, but all the modern ones have been switching to ARM. It's pretty much on its last legs there aside from the really cheap, low-end stuff.

Re: MIPS Becomes RISC-V

#104

Post by skissane »

msla wrote: post #85
elihu wrote: post #74

Earlier quoted context omitted.

I wish the barriers to using new architectures were lower. For instance, suppose binaries were typically distributed in a platform-agnostic format, like LLVM intermediate representation or something equivalent. When you run your program the first time, it's compiled to native code for your architecture and cached for later use. I realize I've sort of just re-invented Javascript. But what if we just did away with nati…

> For instance, suppose binaries were typically distributed in a platform-agnostic format, like LLVM intermediate representation or something equivalent. When you run your program the first time, it's compiled to native code for your architecture and cached for later use. IBM's OS/400 (originally for the AS/400 hardware, now branded as System i) did precisely this: Compile COBOL or RPG to a high-level bytecode, which…

> Other OSes could definitely do it.

See https://en.wikipedia.org/wiki/Architecture_Neutral_Distribut...

Using ANDF you could produce portable binaries that would run on any UNIX system, regardless of CPU architecture. It was never commercially released though. I think while it is cool technology the market demand was never really there. For a software vendor, recompiling to support another UNIX isn't that hard; the real hard bit is all the compatibility testing to make sure the product actually works on the new UNIX. ANDF solved the easy part but did nothing about the hard bit. It possibly would even make things worse, because then customers might have just tried running some app on some other UNIX the vendor has never tested, and then complain when it only half worked.

Standards are always going to have implementation bugs, corner cases, ambiguities, undefined behaviour, feature gaps which force you to rely on proprietary extensions, etc. That's where the "hard bit" of portability comes from.

Re: MIPS Becomes RISC-V

#105

Post by Koshkin »

rwmj wrote: post #33
zokier wrote: post #20

The progression of headlines is funny: 1) MIPS Strikes Back: 64-bit Warrior I6400 Arrives https://news.ycombinator.com/item?id=8258092 We are still in the game 2) Linux-running MIPS CPU available for free to universities – full Verilog code https://news.ycombinator.com/item?id=9444567 Okay, we are not doing so great, maybe we can get young kids hooked? 3) MIPS Goes Open Source https://news.ycombinator.com/item?id=187…

I have one of the purple MIPS SBCs from back when MIPS was briefly owned by Imagination ( https://en.wikipedia.org/wiki/Imagination_Creator https://elinux.org/MIPS_Creator_CI20 ). Slow as hell even back in 2014. I wonder if one day it'll be a museum piece :-?

Microchip PIC32 seems to be plenty fast.

Re: MIPS Becomes RISC-V

#106

Post by tyingq »

zdw wrote: post #76
Fordec wrote: post #59

Earlier quoted context omitted.

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.

SPARC is well known to be different enough (big endian, register windowing of the stack, alignment, etc.) that it exposes a lot of bugs in code that would be missed in a little-endian, x86 derived monoculture. https://marc.info/?l=openbsd-bugs&m=152356589400654&w=2

I had a neat experience a long time ago when I wrote a Perl XS module in C, in my x86 monoculture mindset. When you deploy something to their package manager (CPAN), it's automatically tested on a lot of different platforms via a loose network of people that volunteer their equipment to test stuff...https://cpantesters.org.

So, I immediately saw it had issues on a variety of different platforms, including an endianess problem. Cpantesters.org lets you drill down and see what went wrong in pretty good detail, so I was able to fix the problems pretty quickly.

It used to have a ton of different platforms like HPUX/PA-RISC, Sun/Sparc, IRIX/MIPS and so on, but the diversity is down pretty far now. Still lots of OS's, but few different CPUs.

Re: MIPS Becomes RISC-V

#107

Post by gnufx »

elihu wrote: post #74
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,…

I wish the barriers to using new architectures were lower. For instance, suppose binaries were typically distributed in a platform-agnostic format, like LLVM intermediate representation or something equivalent. When you run your program the first time, it's compiled to native code for your architecture and cached for later use. I realize I've sort of just re-invented Javascript. But what if we just did away with nati…

Surely the barrier to using a new architecture is being able to boot a kernel and run (say) the GNU toolchain, as demonstrated with RISC-V. Then you just compile your code, assuming it doesn't contain assembler, or something. Whether or not you'll have the same sort of board support issues with RISC-V as with Arm, I don't know.

Re: MIPS Becomes RISC-V

#108

Post by gnufx »

dragontamer wrote: post #9
gautamcgoel wrote: post #4

This is huge. It looks like the only architectures widely-deployed in ten years will be x86, ARM, Power, and RISC-V (maybe also SPARC64 in Japan, although that's rare in the US).

The big innovation in architectures is in the SIMD world. AVX512 (x86 512-bit), SVE (ARM 512-bit), NVidia PTX / SASS (32x32-bit), AMD RDNA (32x32-bit), AMD CDNA (64x32-bit). 64-bit cores (aka: classic CPUs) are looking like a solved problem, and are becoming a commodity. SIMD compute however, remains an open question. NVidia probably leads today, but there seems to be plenty of room for smaller players. Heck, one maj…

The V in SVE is for vector, the S isn't for SIMD, and it's length-agnostic; I don't know how similar it is to the RISC-V vector extension. Think CDC, Cray, NEC, not AMD/Intel. I guess the recent innovation in that space is actual matrix multiplication instructions in CPUs.

Re: MIPS Becomes RISC-V

#109

Post by dragontamer »

sujayakar wrote: post #101
dragontamer wrote: post #78

Earlier quoted context omitted.

Cool stuff! I'll give it a lookover later. A few years ago, I wrote AESRAND ( https://github.com/dragontamer/AESRand ). I managed to get some well-known programmers to look into it, and their advice helped me write some pretty neat SIMD-tricks. EX: I SIMD-implemented a 32-bit integer -> floating point [0.0, 1.0] operator, to convert the bitstream into floats. As well as integer-based nearly bias-free division / modul…

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. > My current home project is bump-allocator + semi-space garbage collection in SIMD for GPUs. As far as I can tell, both bump-allocation and semi-space garbage collection are easily SIMDified in an obvious manner. And since cudamalloc is fully synchronous, I…

> 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 iteration, with only 3-more instructions). I don't think I ever tested that...

But honestly, the thing that really made me stop playing with AESRAND was discovering multiply-bitreverse-multiply random number generators (still unpublished... just sitting in a directory in my home computer).

Bit-reverse is single-cycle on GPUs (NVidia and AMD), and perfectly fixes the "multiplication only randomizes the top bits" problem.

Bit-reverse is unimplemented on x86 for some reason, but bswap64() is good enough. Since bswap64() and multiply64-bit are both implemented really fast on x86-64-bit, a multiply-bswap64-multiply generator probably is fastest for typical x86 code (since there are penalties for going between x86 64-bit registers and AVX 256-bit registers).

---------

The key is that multiplying by an odd number (bottom-bit == 1) results in a fully invertible (aka: no information loss) operation.

So multiply-bitreverse-multiply is a 1-to-1 bijection in the 64-bit integer space: all 64-bit integers have a singular, UNIQUE multiply-bitreverse-multiply analog. (with multiply-bitreverse-multiply(0) == 0 being the one edge case where things don't really workout. An XOR or ADD instruction might fix that problem...).

---------

> This is a great idea. I wonder if we could speed up LuaJIT even more by SIMD accelerating the GC's mark and/or sweep phases...

Mark and Sweep looks hard to SIMD-accelerate in my opinion. At least, harder than a bump-allocator. I'm not entirely sure how a SIMD-accelerated traversal of the heap is even supposed to look like (aka: simd-malloc() looks pretty hard).

If all allocs are prefix-sum'd across the SIMD-units (ex: malloc ({1, 4, 5, 1, 2, 3, 20, 10}) == return (memory + {0, 1, 5, 10, 11, 13, 14, 34, 44})... for a bump-allocator like strategy... its clear to me that such a mark/sweep allocator would have fragmentation issues. But I guess it would work...

Semispace collectors innately fix the fragmentation problem. So prefix-sum(size+header) allocators are just simple and obvious.

--------

On the "free" side of Mark/sweep... I think the Mark-and-sweep itself can be implemented in GPU-SIMD thanks to easy gather/scatter on GPUs.

However, because gather/scatter is missing (scatter is missing from AVX2), or slow (AVX512 doesn't seem to implement a very efficient vgather or vscatter), I'm not sure if SIMD on CPU-based Mark/Sweep would be a big advantage.

------------

Yup yup. Semispace GC or bust, IMO anyway for the SIMD-world. Maybe mark-compact (since mark-compact would also fix the fragmentation issue).

The mark-phase is just breadth-first-search, which seems like a doable SIMD-pattern with the right data-structure (breadth-first is easier to parallelize than depth-first)

Re: MIPS Becomes RISC-V

#110

Post by chx »

dfox wrote: post #72
projektfu wrote: post #52

Earlier quoted context omitted.

Isn't z/Architecture just emulated on top of POWER? That's been my impression for a while.

You probably mean "TIMI" which is the user-visible ISA of IBM's "midrange" systems (ie. AS/400 or System/i) which was from the start meant as virtual machine ISA that is then mostly AOT transpiled into whatever hardware ISA OS/400 or i5/OS runs on. z/Architecture (S/360, ESA/390, what have you...) is distinct from that and distinct from PowerPC. Modern POWER and z/Architecture CPUs and machines are somewhat similar w…

I learned Z80 assembly in 1987, x86 assembly somewhere '91-92 can't exactly remember but it was in '94 when I met IBM Assembler (yes they called Assembler language which is also confusing) and I was like "what is this sorcery where assembly has an instruction to insert into a tree".
Post reply on HN