Hacker News Reader

Comment by cwzwarich | Hacker News Reader

If you're writing a good emulator, you're going to want it to generate machine code. Doesn't that interact poorly with Go?

View on HN

Not necessarily. Computers are so fast these days that real time simulation of a lot of these older systems in interpreted environments (a naive C instruction interpreter, or even Javascript, etc...) is perfectly feasible. The Apple ][ had a 1MHz clock, a CPU that took 2-10 cycles per instruction, and an 8kb framebuffer that refreshed at 60Hz. That's not a lot of work to emulate.

That depends on what your standard of accuracy is. http://arstechnica.com/gaming/2011/08/accuracy-takes-power-o...

That's a fair argument, but "accuracy" isn't really the right word. Because then you'd have to deal with the fact that the color gamut from a 1982 NTSC TV is different from your LCD. Similarly I've never seen a good simulation of interlace flicker (not an issue on the NES though -- it didn't interlace) on a LCD either. The impedance mismatch between a NES controller and a modern keyboard alone is much higher than that beteween a "naive" simulation and the one in that article.

And if you want to go down the "elaborate" road, there are even niftier projects out there like the Javascript transistor-level simulation of a 6502.

There's always room to spend cycles. But simulating a 1980's computer to the level of precision required by "correct user experience" is a straightforward engineering task these days that doesn't require anything more than "just plain code."

Actually, if you can compile Go modules at runtime, you could JIT that way. My IronBabel emulator "decompiled" the guest code to C# and then compiled that, for impressively high performance; you could do the same with Go, without the horrid compile times that I had. Combine that with some nice caching, and you're golden. But I don't know that Go has such a programatic compiler API.

You can, but Go doesn't really have a good way to link in the product at runtime. Maybe something like a Go version of GNU Lightning would be a fun project -- http://www.gnu.org/software/lightning/

You can't wrap Lightning itself, otherwise any possible gains you could expect are lost at the CGO transition.

> You can't wrap Lightning itself

What prevents wrapping lightning? (I'm not at all familiar with Lightning)

> any possible gains you could expect are lost at the CGO transition

I was under the impression that the CGO overhead was due to marshaling data -- could that not be avoided by representing the JIT'd code as unsafe.Pointer's and type annotations (akin to how reflect invokes reflect.Values)? Or is there a whole realm of stuff I'm missing?

EDIT:

Did a bit of digging; reflect.Value.Call internally uses reflect·call (defined in runtime[1]), which obviously uses the Go ABI. Since any JIT'd code we want to load will expect to be called with the C ABI, presumably, we're stuck with runtime·asmcgocall[2]. Combined with runtime·cgocall[3], it certainly is longer than a vanilla preamble in C, so there's definitely some significant overhead not related to, e.g., cgo.GoString. I don't have enough prowess to determine the actual performance impact, though :(

Could be a fun weekend project.

[1] http://code.google.com/p/go/source/browse/src/pkg/runtime/as...

[2] http://code.google.com/p/go/source/browse/src/pkg/runtime/as...

[3] http://code.google.com/p/go/source/browse/src/pkg/runtime/cg...

Interesting. It appears that cgocall has improved from the last time I went down this rabbit hole. Previously, it used a pthread_create to construct a C stack and context on each runtime.cgocall and then waited on a mutex for it to return. The overhead was enough to make me favor image/png Encode over libpng for smaller images.

Time to go profiling again! :)

Assuming that by 'good' you mean emulating a system which has pretty high demands on hardware when emulating (I guess ps2,gamecube,dreamcast and onwards) then yes it's very likely you will want to use dynamic recompiling (jit) to convert the emulated code from foreign machine code to native machine code and execute the native code for increased performance.

I assume this is possible with Go as it has the ability to call unsafe code?

How does that interact poorly with Go? I'm just curious.

Lots of optimized code in Go's standard library has fast paths in assembly which is linked into the final binary on a platform by platform basis. I this sense, it's probably easier than C to drop into assembly. Granted, Go's memory model is not going to enforce a whole lot so you better know what you're doing at this point.

Eh? Go doesn't have any capability to include inline assembly,

> "There is no facility in the Go programming language to support in-line assembler language code, and there are no plans to do so" http://stackoverflow.com/questions/2951028/is-it-possible-to...

Of course the C parts of Go's standard library have optimized assembly - using C's capability to do.

So Go is not easier in any way for dropping into assembly - in fact it's much harder, you can't do it in the language, at best you might be lucky if Go's library does some stuff like that for you.

I didn't say inline. I said linked. It's pretty easy to add.

You said "easier than C". How is linking to assembly code from Go any easier than linking to assembly code from C?

Just go see how it's done. Look for example at how `math.Exp` is declared:

http://golang.org/src/pkg/math/exp.go?s=368:395#L4

You'll notice that 'exp' is defined below, using Go.

However, 'Exp' is also defined in Assembly. For example, amd64:

http://golang.org/src/pkg/math/exp_amd64.s

This is all compatible with the `go` tool. You just drop in your Assembly, run `go build`, and the appropriate Assembly version is chosen based on your target architecture (or the Go code is used as a fallback if no Assembly for the target architecture exists).

I don't have much experience with inlining Assembly in C, but this is pretty damn easy.

That is so awesome, I'm willing to bet they plan on inlining quite a few functions in the future too... which means drastic speedups.

Easy? Sure. Easier than C? Nope. Sounds like it has the equivalent of a few make rules written for you (which is nice, make is a mess, but not really an advantage for go-the-language per se), but you could do exactly the same thing in C - and you can also inline assembly in your C source file.

> Sounds like it has the equivalent of a few make rules written for you

No. It sounds like the `go` tool is aware of how to compile different pieces of code for different architectures.

> but you could do exactly the same thing in C - and you can also inline assembly in your C source file.

Why does this make C easier? Does C automatically choose the correct target architecture for every piece of Assembly you write?

>Why does this make C easier?

It gives you more options. It makes it more practical to interleave C and assembly at a very granular level, whereas it sounds like you can only do it at the function level or coarser in go.

>Does C automatically choose the correct target architecture for every piece of Assembly you write?

No. I won't deny that go has a good build system, but I'm more interested in the language.

> Why does this make C easier?

Inlining some assembly where you need it - interacting with C variables, etc. - is definitely the most convenient thing.

Of course, if you don't want that, you can just put the assembly code in a separate function, also very easy to do with C.

> I don't have much experience with inlining Assembly in C, but this is pretty damn easy.

It's about the same as C. If you want to see really easy, take a look at how LuaJIT does it (DynASM).

It allows multiple platforms to be implemented w/o a series of macros.

Reply on news.ycombinator.com