Hacker News Reader

Comment by monocasa | Hacker News Reader

I really like the underlying approach. For those that can't read it (scihub is having issues with the doi) they ran qemu targeting x86->mips, and then added new mips instructions to get around what was taking a long time to emulate, x86 flag generation on arthmetic ops, an x86 like FPU and VU, and additional addressing modes.

What they came up with really reminds me of the inside of a modern x86 core that sort of looks RISC-esque after the decoder, they're just doing the decode in software. It's a really interesting halfway point between a traditional x86 core and transmeta's that way.

View on HN

Yep, it can be used pretty much anywhere, it's just Intel will never disclose all the intricacies how instructions are broken into uOps.

But, regarding Godson, Zhaoxin, Hygon, Kaixian and 10 more other...

I can only give another poke to Chinese government bodies behind the "Chinese x86" program for continuing wasting state money for two decades straight, trying to make Chinese x86 clones.

There is a following sentiment that is widely spread in industry bodies that "Chinese chips can't run Windows, thus they are not as good as American ones." That's a complete nonsense to anybody moderately technically literate, but this premise lets those guys keep soliciting government money.

I think with the huge amount of legacy code out there, and Moore's law hitting a wall so emulating an x86 at the same speed of an in hardware x86 core might be an impossibility, there's space for interesting native x86 designs. I imagine we'll see a lot of interesting work in that space here in the west in a couple years when the x86_64 patents start expiring, China just has a leg up with their "we only enforce IP when it helps us" attitude.

I wouldn't be surprised if someone sticks a x86 decoder onto a RISCV core sort of like the PowerPC 615 did.

There are a lot of spots where x86 still makes sense for embedded. A lot of the ARM SoCs are wimpy for I/O, plenty of devices have poor vendor driver support outside x86, and there's many software tasks that are easier on Windows than an arbitrary ARM/Linux stack.

We don't need Threadripper performance there, but we do need cheap, predictable, and not subject to supply whims. If you're a Chinese firm on a 10-year time horizon, "supply whims" includes making sure you've got domestic production.

There are some interesting articles here: http://emulators.com/nx_toc.htm, where Darek Mihocka advocates a similar approach; however pushing for emulation rather than JIT.

The Modcomp computer, 1970+, had a dynamically programmed instruction set capability using a programmable ROM. It was targeted at applications written for other systems, and for realtime problems that benefited by an instruction set crafted for a specific problem.

Somewhat like the Xerox Alto, which basically had an entire OS in microcode to provide CPU functionality.

I've heard the argument from a few chip designers that the main thing the user microprogrammable machines got you was a Harvard architecture. You got most of your wins by pushing complex ideas into ucode where each step fetched from the ucode ROM instead of the main memory bus. That's why on pretty much every microcoded machine you see a memcpy instruction. It's the most obvious win for getting the ifetches out of the way of your data throughput.

Once we started adding instruction caches, that big win started to not be as big. Ultimately it's the caches that killed off that machine, and the ucode interpreters you saw on the Smalltalk and Lisp machines.

One idea I would like to make it's way from ucode that hasn't yet though is being able to define interrupt boundaries for the real time tasks you allude to.

> x86 flag generation on arthmetic ops, an x86 like FPU and VU, and additional addressing modes.

I've figured this was a good way forward for a while, glad to see someone with the knowledge and access to a fab make it a reality :) I'm hoping that someone proposes a similar extension for RISC-V

Edit: Well I guess there's a J extension for JIT acceleration in development, guess I should have finished reading the comments before replying lol

JIT != emulation.

I've been watching the RISC-V J extension but it seems to be a blank space, a placeholder hoping that someone has a good idea for accelerating JITs. I don't even know what that would mean.

To be fair, the Godson-3 that this thread is about emulates via a JIT.

For starters, you need a mechanism to notify other cores that their instructions have changed. That may mean requiring coherent icaches, or maybe some more explicit but simpler mechanism.

If you don't go with coherent I-D caches, is that really cheaper than IPIs?

Reply on news.ycombinator.com