Go-Compiler für MSP430

[Jakob (Gast)]

Hallo,

ich versuche einen sehr eingeschränkten Go-Compiler für den MSP430 zu 
bauen.
Es funktioniert noch fast gar nichts außer Variablenzuweisungen und 
Schleifen.
Damit lassen sich aber schon mal LEDs zum Leuchten bringen:

package main

import msp430 "msp430.io/g2553"

func main() {
  // Wachhund abstellen
  msp430.WDTCTL = msp430.WDTPW | msp430.WDTHOLD
  
  // LED an P1.0
  msp430.P1DIR |= 0x01
  msp430.P1OUT |= 0x01
}

Wer damit etwas spielen (mehr ist z.Z. nicht drin) will,
kann sich hier die passende Version runterladen:

Linux: https://ugo-compiler.de/bin/linux/amd64/ugo
macOS: https://ugo-compiler.de/bin/darwin/amd64/ugo
OpenBSD: https://ugo-compiler.de/bin/openbsd/amd64/ugo
Windows: https://ugo-compiler.de/bin/windows/amd64/ugo

[Paul penetrant panisch (Gast)]

Jakob schrieb:
> Wer damit etwas spielen (mehr ist z.Z. nicht drin) will,
> kann sich hier die passende Version runterladen:
>
> Linux: https://ugo-compiler.de/bin/linux/amd64/ugo
> macOS: https://ugo-compiler.de/bin/darwin/amd64/ugo
> OpenBSD: https://ugo-compiler.de/bin/openbsd/amd64/ugo
> Windows: https://ugo-compiler.de/bin/windows/amd64/ugo

Uih, 8.7 Downloadpaket, scheint sehr gut dokumentiert zu sein ….

Scherz beiseite, warum soll ich bei so einem unnützen Kram nicht 
befürchten, einen Trojaner einzufangen!

[Blume (Gast)]

Was man auch vermisst ist eher ein Link auf ein Git Repro samt Anleitung 
wie man den Compiler selber bauen kann.

[Tom T. (tomth)]

Ist Go nicht sehr, sehr speicherintensiv? Eine x86 Hello World hat ja 
schlappe 900 KB.

[Jakob (Gast)]

@Tom,

die vom offiziellen Go-Compiler erzeugten Binärdateien sind so groß, 
weil sie die Laufzeitbibliothek (und ggf. Debuginformationen ) 
enthalten:
https://golang.org/doc/faq#Why_is_my_trivial_program_such_a_large_binary

Der abgespeckte Compiler hingegen liefert keine Laufzeitbibliothek mit. 
Das hat den Vorteil, dass die Binärdateien deutlich kleiner sind, aber 
auch den Nachteil, dass Konstrukte, die eine Laufzeitbibliothek 
erfordern würden, nicht erlaubt sind (z.B. new, append usw.).

Zum Vergleich: Die Binärdatei des auf der Webseite angegebenen 
LED-Beispiels ist 72B groß (mit Alpha-Version ohne jegliche 
Optimierungen).

Wer mit dem MSP noch nichts gemacht hat, kann sich hier eine 
Minimalanleitung angucken:
http://ugo-compiler.de/fuer-anfaenger.html

[Alan (Gast)]

Es wirklich ein hervorragendes Marketing, wenn man sieht, was der 
Weltschnüffeler No. 1 den Leuten so alles untergejubelt.

[Εrnst B. (ernst)]

Mal ganz blöd gefragt:

Für den GCC gibt es ein Go-Frontend und ein MSP430 Backend.

Lassen die sich nicht miteinander verheiraten, so dass nur noch 
Bibliotheken fehlen?

[Christopher J. (christopher_j23)]

Εrnst B. schrieb:
> Für den GCC gibt es ein Go-Frontend und ein MSP430 Backend.
>
> Lassen die sich nicht miteinander verheiraten, so dass nur noch
> Bibliotheken fehlen?

Meines Wissens nach ist der GCC nicht so modular aufgebaut, dass das 
ginge. Bei Clang/LLVM wäre das vielleicht der Fall, da man dort LLVM als 
"High-Level Assembler" hat, d.h. jeder Compiler der LLVM als Unterbau 
benutzt erzeugt eine "Intermediate Representation" (LLVM-IR). Für C/C++ 
macht das Clang und für Rust eben rustc. Darüber hinaus gibt es noch 
unzählige andere Frontends, wie D, Julia, etc. Alle erzeugen LLVM-IR, 
auf welche dann noch plattformspezifische Optimierungen angewandt werden 
und am Ende das fertige Binary herausfällt.

Das größere Problem an der Ausführung von "High-Level"-Sprachen wie Go 
auf Mikrocontrollern ist aber die Runtime, die eben nicht einfach so vom 
Himmel fällt und durchaus relativ groß ist und darüber hinaus noch der 
fehlende OS-Unterbau, auf welchen sich manche Funktionen der 
Standard-Library stützen.

Es gibt bereits eine Go-Implementierung die auf Mikrocontroller abziehlt 
und die ebenfalls LLVM als Backend nutzt. Bisher werden nur ARM und AVR 
explizit unterstützt aber da es ja für MSP430 ein LLVM-Backend gibt, 
könntest du das theoretisch zusammenfrickeln ;)
Hier der Link: https://tinygo.org/