4 ms·

Well Apple stopped supporting 10.8, so why should Go continue to support it? ARM6 support is a lot of work, actually, as IIUC a lot of stuff that the chip does

by enneff 10y ago

Well Apple stopped supporting 10.8, so why should Go continue to support it? ARM6 support is a lot of work, actually, as IIUC a lot of stuff that the chip doesn't support needs to be done in software, and we don't have a reliable platform for testing against ARM6.

Hydraulix989 10y ago
I guess I am a bit more upset about ARM6. How were you testing before? Have you considered using an emulator? Even Linux still supports ARM6.
- enneff 10y ago
  I don't remember the details of our testing platform, it's been a while since I've been involved in ARM6 builders. I do remember that we used to test against emulators but they diverged significantly enough from the real hardware that we stopped using them.
- 4ad 10y ago
  You can't test properly against emulators like QEMU. Emulators are written to be fast, not accurate (although in absolute terms they are pretty slow), e.g. they execute correct code quickly, but they don't fail to run incorrect code the same way real hardware would do. For example, when I wrote the arm64 Go port, I quickly discovered that the emulator would not cause a trap on unaligned memory access! Incorrect code executed just fine on the emulator. Even worse, I found several other bugs in a span of few days. In the end, I ended up writing my own arm64 emulator before hardware became available. I finished the port on real hardware. Of course, in principle an emulator could do perfect emulation, but in practice testing Go on an emulator would mean testing and maintaining an emulator as well. Apart from all that, running the Go test suite in a reasonable time requires a reasonable fast (e.g. server class) computer. Emulators just don't make the cut. And neither do small/old ARM systems. We could reduce the scope of the tests for embedded platforms, but then somebody would have to step in and work on and maintain those platforms. People always complain when the minimum hardware requirements for ARM are increased, but never offer to step in and help... Personally, I am interested in Go on embedded systems, but I don't have the time to maintain this as well.
  - Hydraulix989 10y ago
    Coming from the silicon chip validation world, I mean the actual definition of "emulator," not the abused version of the word that actually means "simulator." Sorry, I thought it would have been more obvious in this context -- it wasn't clear that by "even Linux still supports ARM6," I meant even the Linux OS kernel supports the architecture, not that QEMU for Linux supports it for running guest OSes. EDIT: The official one from ARM was the one I was thinking of: https://en.wikipedia.org/wiki/ARMulator https://en.wikipedia.org/wiki/ARMulator
    - 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).
      - 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.
4ad 10y ago
> Well Apple stopped supporting 10.8, so why should Go continue to support it? I don't know, but Microsoft stopped supporting Windows XP many years ago, and it's still supported by Go. (Not that I care about Go on Darwin 10.8; just making an observation...)
- Hydraulix989 10y ago
  Right, it's a weak argument. Apple tends to pull the plug rather quickly, as well, but that's tangential.
- enneff 10y ago
  Microsoft puts more effort into keeping things working than Apple does. Go works on XP as a result of the work Microsoft has done, not the Go project. Apple change subtle things in each OS X release making it onerous to support the older ones.
  - 4ad 10y ago
    This is not true, Go "keeps working" on Windows because on Windows Go is ABI compliant and uses stable interfaces. In particular, on Windows Go interacts with the system through kernel32.dll and uses the standard Windows ABI. Same is true for Solaris, where Go interacts with the system only through libc.so.1, and uses the System V ABI for the calling convention and thread-local storage. On Linux the system call interface is stable (unlike Windows and Solaris), so on Linux Go "keeps working" too (albeit I will note that we don't use an ABI-compliant method for determining the current time...). Darwin is just like Windows and Solaris, and unlike Linux. The system call interface is not stable, but unlike Windows and Solaris we use it anyway, and the method we use for thread-local storage is unportable and system-dependent. However, Darwin still has a stable interface through its own libc, and there's an ABI-compatible method to do thread-local storage as well. If Go would use the standard system interfaces on Darwin (like it does on Windows and Solaris), Go would just "keep working" on Darwin too and would not require changes each time a new macOS release is made. It is true that Microsoft is very committed to forward and backwards compatibility, but only for its stable and documented interfaces (which Go uses), undocumented interfaces break all the time; Darwin's forward and backwards compatibility guarantees might not be as strong as Microsoft's over large periods of time, but they are still pretty good as long as you use the supported interfaces.

by enneff 10y ago

Hydraulix989 10y ago

I guess I am a bit more upset about ARM6. How were you testing before? Have you considered using an emulator? Even Linux still supports ARM6.

enneff 10y ago
I don't remember the details of our testing platform, it's been a while since I've been involved in ARM6 builders. I do remember that we used to test against emulators but they diverged significantly enough from the real hardware that we stopped using them.
4ad 10y ago
You can't test properly against emulators like QEMU. Emulators are written to be fast, not accurate (although in absolute terms they are pretty slow), e.g. they execute correct code quickly, but they don't fail to run incorrect code the same way real hardware would do. For example, when I wrote the arm64 Go port, I quickly discovered that the emulator would not cause a trap on unaligned memory access! Incorrect code executed just fine on the emulator. Even worse, I found several other bugs in a span of few days. In the end, I ended up writing my own arm64 emulator before hardware became available. I finished the port on real hardware. Of course, in principle an emulator could do perfect emulation, but in practice testing Go on an emulator would mean testing and maintaining an emulator as well. Apart from all that, running the Go test suite in a reasonable time requires a reasonable fast (e.g. server class) computer. Emulators just don't make the cut. And neither do small/old ARM systems. We could reduce the scope of the tests for embedded platforms, but then somebody would have to step in and work on and maintain those platforms. People always complain when the minimum hardware requirements for ARM are increased, but never offer to step in and help... Personally, I am interested in Go on embedded systems, but I don't have the time to maintain this as well.
- Hydraulix989 10y ago
  Coming from the silicon chip validation world, I mean the actual definition of "emulator," not the abused version of the word that actually means "simulator." Sorry, I thought it would have been more obvious in this context -- it wasn't clear that by "even Linux still supports ARM6," I meant even the Linux OS kernel supports the architecture, not that QEMU for Linux supports it for running guest OSes. EDIT: The official one from ARM was the one I was thinking of: https://en.wikipedia.org/wiki/ARMulator https://en.wikipedia.org/wiki/ARMulator
  - 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).
    - 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.

4ad 10y ago

> Well Apple stopped supporting 10.8, so why should Go continue to support it? I don't know, but Microsoft stopped supporting Windows XP many years ago, and it's still supported by Go. (Not that I care about Go on Darwin 10.8; just making an observation...)

Hydraulix989 10y ago
Right, it's a weak argument. Apple tends to pull the plug rather quickly, as well, but that's tangential.
enneff 10y ago
Microsoft puts more effort into keeping things working than Apple does. Go works on XP as a result of the work Microsoft has done, not the Go project. Apple change subtle things in each OS X release making it onerous to support the older ones.
- 4ad 10y ago
  This is not true, Go "keeps working" on Windows because on Windows Go is ABI compliant and uses stable interfaces. In particular, on Windows Go interacts with the system through kernel32.dll and uses the standard Windows ABI. Same is true for Solaris, where Go interacts with the system only through libc.so.1, and uses the System V ABI for the calling convention and thread-local storage. On Linux the system call interface is stable (unlike Windows and Solaris), so on Linux Go "keeps working" too (albeit I will note that we don't use an ABI-compliant method for determining the current time...). Darwin is just like Windows and Solaris, and unlike Linux. The system call interface is not stable, but unlike Windows and Solaris we use it anyway, and the method we use for thread-local storage is unportable and system-dependent. However, Darwin still has a stable interface through its own libc, and there's an ABI-compatible method to do thread-local storage as well. If Go would use the standard system interfaces on Darwin (like it does on Windows and Solaris), Go would just "keep working" on Darwin too and would not require changes each time a new macOS release is made. It is true that Microsoft is very committed to forward and backwards compatibility, but only for its stable and documented interfaces (which Go uses), undocumented interfaces break all the time; Darwin's forward and backwards compatibility guarantees might not be as strong as Microsoft's over large periods of time, but they are still pretty good as long as you use the supported interfaces.