Godson-3: A Scalable Multicore RISC Processor with x86 Emulation (2009) | Hacker News Reader

Godson-3: A Scalable Multicore RISC Processor with x86 Emulation (2009)

computer.org

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.

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.

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.

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

> 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.

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?

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

Found a mirror by putting the paper title on Google, for those who aren't IEEE subscribers: https://home.deib.polimi.it/sami/architetture/godson.pdf

Tangentially related, RISC-V's J Extension is under development for JIT acceleration, both for emulating other ISAs and running Java and the like.

Do you know where the working group for that lives? That extension always seemed questionable to me. Most of those extensions are pretty short lived and marketing driven on other ISAs. The Azul guys AFAIK didn't even put anything interesting like that into their user ISA; their secret sauce was in the MMU.

They had a custom user ISA instruction to make write or read barriers cheaper.

What was that other than read or write barriers that happened to be cheap?

Only that, but they did more user or between kernel and user level magic. See the paper The Pauseless GC Algorithm by Cliff Click, Gil Tene, and Michael Wolf at https://www.usenix.org/legacy/events/vee05/full_papers/p46-c... ; from the abstract:

> Azul Systems has built a custom system (CPU, chip, board, and OS) specifically to run garbage collected virtual machines. The custom CPU includes a read barrier instruction. The read barrier enables a highly concurrent (no stop-the-world phases), parallel and compacting GC algorithm.

From the paper, including some bits on the MMU you mentioned:

> Our read-barrier allows us to intercept and correct individual stale references, and avoids blocking the mutator to fix up entire pages. We also support a special GC protection mode to allow fast, non-kernel-mode trap handlers that can access protected pages.

> Having the read-barrier implemented in hardware greatly reduces costs. In our case the typical cost is roughly that of a single cycle ALU instruction.

> The hardware TLB supports an additional privilege level, the GC-mode, between the usual user- and kernel-modes.... Several of the fast user-mode traps start the trap handler in GC-mode instead of user-mode.

> The TLB is managed by the OS in the usual ways, with normal kernel-level TLB trap handlers being invoked when normal loads and stores fail an address translation. Setting the GC privilege mode bit is done by the JVM via calls into the OS. TLB violations on GC-protected pages generate fast user-level traps instead of OS level exceptions.

> The hardware supports a fast cooperative preemption mechanism via interrupts that are taken only on user-selected instructions, allowing us to rapidly stop individual threads only at safepoints. Variants of some common instructions (e.g., backwards branches, function entries) are flagged as safepoints and will check for a pending per-CPU safepoint interrupt. If a safepoint interrupt is pending the CPU will take an exception and the OS will call into a user-mode safepoint-trap handler.

Then read starting with section 3.3 Hardware Read Barrier for the details.

See also C4: The Continuously Concurrent Compacting Collector by Gil Tene, Balaji Iyengar, and Michael Wolf for how they moved this to x86 hardware: https://www.azul.com/files/c4_paper_acm1.pdf

this is a 10yr old paper

Yes. OP: Please add (2009) to title.

I would if I could, but HN will not allow me to edit the title at this point. Apparently there's a time period from the point in time at which an article is posted to which the title can be modified, but apparently we're past that point of time now... My humble apologies, I would change the title if I could...

Wasn't "x86 emulation" basically the WinChip's and Cyrix's strategy in the late '90s-early '00s? I don't remember that ending too well, unfortunately...

No, they were "real" x86 chips

you're probably thinking about Transmeta

Yep, my bad, it was Transmeta indeed

Which has returned from the dead as NVidia's ARM emulating Project Denver.

Denver started out as X86 but then were scared away by Intel legal and switched to ARMv8 with an architecture license from ARM.

WinChip (Centaur) did break x86 instructions into RISC-like ones in hardware - which is pretty much what AMD and intel have been doing since the mid-90's themselves.

No, they were real x86 cores. No emulation.

Itanium emulated x86 as well, and didn't go too well either.

Reply on news.ycombinator.com