3 ms·

> So clearly there is some "huge" feature that is really holding things back from running on a resource-constrained microcontroller in a stripped-down runtime.

> So clearly there is some "huge" feature that is really holding things back from running on a resource-constrained microcontroller in a stripped-down runtime. What is it? Garbage collection and goroutines. You could probably strip back the implementations a bit but you can't get rid of gc - there is no explicit way of freeing memory. Possibly you could ban the go keyword and run on a single thread, although you'd have to deal with parts of the stdlib that use it.

logicallee 8y ago
>Garbage collection and goroutines Do you think the specification is "correct" for a compiled language suitable for embedding? The word "garbage" is in the specification a single time, in the introduction which says "garbage-collected". I can't see any constrained implementation details thereafter - see for yourself at where I might have missed it: https://golang.org/ref/spec https://golang.org/ref/spec The gouroutine section (under the Go keyword) is three paragraphs: "A "go" statement starts the execution of a function call as an independent concurrent thread of control, or goroutine, within the same address space." and "The function value and parameters are evaluated as usual in the calling goroutine, but unlike with a regular call, program execution does not wait for the invoked function to complete. Instead, the function begins executing independently in a new goroutine. When the function terminates, its goroutine also terminates. If the function has any return values, they are discarded when the function completes. " This does not seem to require the typical accoutrements of the Go compiler. If this is the complete verbiage specifying the behavior of a Goroutine, I could imagine a compliant implementation being lighter-weight than the official Go compiler. Returning to the idea of GC: the word "memory" appears in the standard 4 times: once mentioning initialization of variables; once on the section on slices ("The built-in functions append and copy assist in common slice operations. For both functions, the result is independent of whether the memory referenced by the arguments overlaps. "); and twice in the last section on system considerations, including light MAY language in "Computer architectures may require memory addresses to be aligned; that is, for addresses of a variable to be a multiple of a factor, the variable's type's alignment. The function Alignof takes an expression denoting a variable of any type and returns the alignment of the (type of the) variable in bytes." and finally under Size and Alignment guarantees, which makes no reference to GC. If this document is the complete specification, then it seems that the implementer has very wide leeway for how to implement the details of memory management via garbage collection. There doesn't seem to be much language limited behavior. What do you think? (In this comment I consider "Go" the language as anything that complies with the Go specification.)
pjmlp 8y ago
Java and Oberon fit easily in a ARM Cortex M, which some embedded companies are happily selling, there is no reason why a Go implementation could not exist as well.
- piotrkubisa 8y ago
  It looks like Go implementation exists for ARM Cortex M (based on transpiling Go to C): https://github.com/ziutek/emgo/blob/master/README.md https://github.com/ziutek/emgo/blob/master/README.md https://github.com/ziutek/emgo/issues/14#issuecomment-398670787 https://github.com/ziutek/emgo/issues/14#issuecomment-398670... https://ziutek.github.io/2018/03/30/go_on_very_small_hardware.html https://ziutek.github.io/2018/03/30/go_on_very_small_hardwar...
  - pjmlp 8y ago
    There is also GERT, but it is for ARMv7a like iMX6 Quad SOC and not updated since one year.

logicallee 8y ago

>Garbage collection and goroutines Do you think the specification is "correct" for a compiled language suitable for embedding? The word "garbage" is in the specification a single time, in the introduction which says "garbage-collected". I can't see any constrained implementation details thereafter - see for yourself at where I might have missed it: https://golang.org/ref/spec https://golang.org/ref/spec The gouroutine section (under the Go keyword) is three paragraphs: "A "go" statement starts the execution of a function call as an independent concurrent thread of control, or goroutine, within the same address space." and "The function value and parameters are evaluated as usual in the calling goroutine, but unlike with a regular call, program execution does not wait for the invoked function to complete. Instead, the function begins executing independently in a new goroutine. When the function terminates, its goroutine also terminates. If the function has any return values, they are discarded when the function completes. " This does not seem to require the typical accoutrements of the Go compiler. If this is the complete verbiage specifying the behavior of a Goroutine, I could imagine a compliant implementation being lighter-weight than the official Go compiler. Returning to the idea of GC: the word "memory" appears in the standard 4 times: once mentioning initialization of variables; once on the section on slices ("The built-in functions append and copy assist in common slice operations. For both functions, the result is independent of whether the memory referenced by the arguments overlaps. "); and twice in the last section on system considerations, including light MAY language in "Computer architectures may require memory addresses to be aligned; that is, for addresses of a variable to be a multiple of a factor, the variable's type's alignment. The function Alignof takes an expression denoting a variable of any type and returns the alignment of the (type of the) variable in bytes." and finally under Size and Alignment guarantees, which makes no reference to GC. If this document is the complete specification, then it seems that the implementer has very wide leeway for how to implement the details of memory management via garbage collection. There doesn't seem to be much language limited behavior. What do you think? (In this comment I consider "Go" the language as anything that complies with the Go specification.)

pjmlp 8y ago

Java and Oberon fit easily in a ARM Cortex M, which some embedded companies are happily selling, there is no reason why a Go implementation could not exist as well.

piotrkubisa 8y ago
It looks like Go implementation exists for ARM Cortex M (based on transpiling Go to C): https://github.com/ziutek/emgo/blob/master/README.md https://github.com/ziutek/emgo/blob/master/README.md https://github.com/ziutek/emgo/issues/14#issuecomment-398670787 https://github.com/ziutek/emgo/issues/14#issuecomment-398670... https://ziutek.github.io/2018/03/30/go_on_very_small_hardware.html https://ziutek.github.io/2018/03/30/go_on_very_small_hardwar...
- pjmlp 8y ago
  There is also GERT, but it is for ARMv7a like iMX6 Quad SOC and not updated since one year.