wrong headline
MIPS Becomes RISC-V
161–170 of 225 posts
Re: MIPS Becomes RISC-V
#162Earlier quoted context omitted.
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.
It is not that way today but for a long time the entry-level Cisco IOS router was PowerPC based, while the highend was invariably MIPS. On the other hand both architectural choices had nothing to do with the architecture and everything to do with choice of usable SoCs for that particular application (with Motorola/Freescale/NXP's "m68k Cisco router/Sun2 on a chip" SoCs being somewhat ironic in this regard).
I wouldn't consider cisco to be a tech-forward company or look to them as the barometer to where the networking industry is headed.
Most of Broadcoms stuff is ARM based now, which is what most folks are putting in white label switches.
Re: MIPS Becomes RISC-V
#163Earlier 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…
> 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. We're doing a pretty good job on portability these days already. Well-written Unix applications in C/C++ will compile happily for any old ISA and run just the same. Safe high-level languages like JavaScrip…
> Well-written Unix applications in C/C++ will compile happily for any old ISA and run just the same. Safe high-level languages like JavaScript, Java, and Safe Rust are pretty much ISA-independent by definition, it's 'just' a matter of getting the compilers and runtimes ported across.
That sort of works, but duplicating the proper development environment in the end-user's computer would take a lot of space and would be complicated by the enormous variety of programming languages and environments. Linux distros manage this with a lot of effort. I'm imagining something like a universal intermediate representation that can be compiled quickly (because a lot of the early language-specific part of compilation will have already been done by whoever you get your packages from) and in a uniform way because there's a common intermediate representation format that all the compiled languages use.
Universal binaries might also be acceptable for commercial, closed-source applications where source distribution would not.
Re: MIPS Becomes RISC-V
#164This 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?
> 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?
Not really, I think the only thing they have going for them is that they probably have IP cores that would port easily and have history. However, places like SiFive [1] appear to have early mover advantage and are likely to be quicker to gain critical mass.
Re: MIPS Becomes RISC-V
#165This article from 2015 ("The Death of Moore’s Law Will Spur Innovation: As transistors stop shrinking, open-source hardware will have its day") is getting better and better with age. https://spectrum.ieee.org/semiconductors/design/the-death-of...
Just the opposite, really.
As the cost of continuing Moore's Law approaches infinity yes, it will cease to continue. But not before all but one foundry has been driven out of business.
And then that one remaining foundry will dominate the entire chip industry.
Also: they'll treat startups like dogshit unless they use automatic place-and-route. So chip startups will be reduced to glorified FPGA jockeys. Hard to differentiate when all you're allowed to do is sling Verilog.
Re: MIPS Becomes RISC-V
#166Earlier 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…
Isn't that basically what Android Runtime does?
I don't know much about Android specifically. Is it still heavily Java-based?
There are a lot of universal-binary candidates both current and historical. Javascript, Java, SPirV, LLVM intermediate representation are some of the current ones. So, this isn't a new idea, it's just that most of the software I use regularly is compiled specifically for x86-64. Maybe it would be better if that were a rare exception rather than the norm.
Re: MIPS Becomes RISC-V
#167There are a couple of vendors of multi-architecture CPUs where the native architecture is MIPSish and the other supported arches are MIPS, ARM, RISC-V & x86. Tachyum is one of them, here is another:
Re: MIPS Becomes RISC-V
#168Everyone'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 hear the RPi has nine different processor clusters, each with their own ISA.
Re: MIPS Becomes RISC-V
#169Earlier 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. > 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 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;
let lut = u8x16::new(0b0000, 0b1000, 0b0100, 0b1100, 0b0010, 0b1010, 0b0110, 0b1110, 0b0001, 0b1001, 0b0101, 0b1101, 0b0011, 0b1011, 0b0111, 0b1111);
let lo_reversed = lut.shuffle1_dyn(lo_nibbles);
let hi_reversed = lut.shuffle1_dyn(hi_nibbles);
let bytes_reversed = (lo_reversed let rev_bytes = u8x16::new(15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0);
return bytes_reversed.shuffle1_dyn(rev_bytes);
__ZN8arbolito7reverse17he044c5155cfe877bE:
push rbp
mov rbp, rsp
movdqa xmm1, xmmword ptr [rip + 557012]
movdqa xmm2, xmm0
pand xmm2, xmm1
psrlw xmm0, 4
pand xmm0, xmm1
movdqa xmm1, xmmword ptr [rip + 557003]
movdqa xmm3, xmm1
pshufb xmm3, xmm2
pshufb xmm1, xmm0
psllw xmm3, 4
pand xmm3, xmmword ptr [rip + 556992]
por xmm3, xmm1
pshufb xmm3, xmmword ptr [rip + 556995]
movdqa xmmword ptr [rdi], xmm3
pop rbp
ret
> The key is that multiplying by an odd number (bottom-bit == 1) results in a fully invertible (aka: no information loss) operation.
This is neat! How do you choose odd numbers so the final generated numbers are high quality?
Re: MIPS Becomes RISC-V
#170Everyone'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…
> I wish the barriers to using new architectures were lower.
Efforts like Bootstrappable Builds and Debian's rebootstrap aim to reduce the barriers for new architectures:
https://bootstrappable.org/ https://bootstrapping.miraheze.org/wiki/Main_Page https://wiki.debian.org/DebianBootstrap https://wiki.debian.org/HelmutGrohne/rebootstrap
For eg the Synopsis folks are bootstrapping a Debian ARC port right now using rebootstrap.
https://github.com/foss-for-synopsys-dwc-arc-processors/rebo...