4 ms·

I did use that, but it is orders of magnitude too slow (not to mention unavailable for the Go team at large).

by 4ad 10y ago

Hydraulix989 10y ago
Generally, compiler development is the intended use case of these emulators. I'm pretty unsympathetic when you say that; yeah, it's slow, it's an emulator, and using it is part of your job description. I wasn't aware the Go team at large all had or needed hardware for all targets? I've done Linux kernel dev without a SPARC, Alpha, etc. Google and first-class contributors to the ARM6 target (I'm sure a relatively small percentage of the Go community touches each individual, specific compiler target) should have no problem getting free or extremely-discounted licenses from ARM (and even test hardware) -- after all, it's in ARM's best interest to have lots of end users writing code that targets their platforms.
- 4ad 10y ago
  First of all, we do use emulators. Personally, as a Go compiler author I have written several emulators to develop (or debug) several Go ports, and I have used many emulators written by others, ranging from open source, to commercial, and even to secret emulators that have never left the hardware division department. Yes, as a compiler writer I deal with how painfully slow these emulators are. Usually it's not a problem. When it's a problem, the payout is usually large enough so that modifying the tests is a good idea. But all of this doesn't matter in general, we were discussing about the Go continuous integration builders. These tests run for every commit (and even before commit), for every change, from any contributor, and test everything. Emulators, even fast and inaccurate ones, and even most low-end hardware is simply too slow to allow for this. Funny you mention ARM and "discounted licenses", because we've been under negotiations for several years to get something like that from them, and even though the arm64 Go port was commissioned by ARM, we still didn't get it yet. I've been promised we'd get what we need, but the bureaucracy and lawyers and approvals simply make any endeavour like this take literally years, and what we will get in the end is something that can be used by a select few, not by any potential Go contributor. Yes, the Go project has access to all targets. It's all real hardware. It's a requirement for any new port. And every change is tested and must not break any target.
  - deleted 10y ago
    [deleted]

I did use that, but it is orders of magnitude too slow (not to mention unavailable for the Go team at large).

by 4ad 10y ago

I did use that, but it is orders of magnitude too slow (not to mention unavailable for the Go team at large).

Generally, compiler development is the intended use case of these emulators. I'm pretty unsympathetic when you say that; yeah, it's slow, it's an emulator, and using it is part of your job description. I wasn't aware the Go team at large all had or needed hardware for all targets? I've done Linux kernel dev without a SPARC, Alpha, etc. Google and first-class contributors to the ARM6 target (I'm sure a relatively small percentage of the Go community touches each individual, specific compiler target) should have no problem getting free or extremely-discounted licenses from ARM (and even test hardware) -- after all, it's in ARM's best interest to have lots of end users writing code that targets their platforms.

4ad 10y ago
First of all, we do use emulators. Personally, as a Go compiler author I have written several emulators to develop (or debug) several Go ports, and I have used many emulators written by others, ranging from open source, to commercial, and even to secret emulators that have never left the hardware division department. Yes, as a compiler writer I deal with how painfully slow these emulators are. Usually it's not a problem. When it's a problem, the payout is usually large enough so that modifying the tests is a good idea. But all of this doesn't matter in general, we were discussing about the Go continuous integration builders. These tests run for every commit (and even before commit), for every change, from any contributor, and test everything. Emulators, even fast and inaccurate ones, and even most low-end hardware is simply too slow to allow for this. Funny you mention ARM and "discounted licenses", because we've been under negotiations for several years to get something like that from them, and even though the arm64 Go port was commissioned by ARM, we still didn't get it yet. I've been promised we'd get what we need, but the bureaucracy and lawyers and approvals simply make any endeavour like this take literally years, and what we will get in the end is something that can be used by a select few, not by any potential Go contributor. Yes, the Go project has access to all targets. It's all real hardware. It's a requirement for any new port. And every change is tested and must not break any target.
- deleted 10y ago
  [deleted]