llvm für avr

[stru_aus (Gast)]

huhu

betrifft eigentlich: alternativer compiler für avr

hat schon jemand mal diese compiler ausprobiert?
https://github.com/atduskgreg/llvm-avr
und
http://avr-llvm.sourceforge.net/

wer es nicht weiss: llvm ist ein neuerer compiler, siehe llvm.org
features: bessere fehlermeldungen, wesentlich schneller im compilieren 
als gcc. llvm ist quasi ein abstrakter compiler, der dann noch clang als 
frontend für c/c++ benutzt.

anscheinend haben sich zwei projekte entwickelt für llvm für avr - ganz 
toll :D

ich kenn mich mit llvm nicht wirklich aus, bekannter hat damit ein wenig 
gespielt und war einigermassen begeistert.

mfg stru_aus

[Dirk (Gast)]

Hi,

gibt es irgendwo auch eine komplette Installation so wie Winavr?

[Tim . (cpldcpu)]

Sieht aus, als wenn fleissig weiter an einem LLVM Backend für AVR 
gearbeitet wurde. Hat das schon einmal jemand hier getestet?

https://github.com/avr-llvm/llvm

[mathäus8 (Gast)]

stru_aus schrieb:
> ich kenn mich mit llvm nicht wirklich aus, bekannter hat damit ein wenig
> gespielt und war einigermassen begeistert.
>

Ist aber nicht unter einer Copyleft-Lizenz; warum sollte man, wenn es 
den GNU GCC gibt, einen weniger freien Compiler unterstützen?

[Nase (Gast)]

mathäus8 schrieb:
> stru_aus schrieb:
>> ich kenn mich mit llvm nicht wirklich aus, bekannter hat damit ein wenig
>> gespielt und war einigermassen begeistert.
>>
>
> Ist aber nicht unter einer Copyleft-Lizenz; warum sollte man, wenn es
> den GNU GCC gibt, einen weniger freien Compiler unterstützen?
Warum sollte man, wenn es den GCC gibt, nicht auch anderen Compilern 
eine Chance geben, die nicht gerade 20 Jahre Altlasten mitschleifen?

Mal ehrlich, GCC hat m.M.n. gerade nochmal die Kurve gekriegt und mit 
der Umstellung auf C++ den Anschluss erwischt. Nicht dass es an seinen 
Fähigkeiten lag - GCC erzeugt i.a. sehr guten Code - aber es war schon 
ein ziemlich gewachsener Haufen.

LLVM für AVR klingt aber schon interessant.

[Jörg W. (dl8dtl) (Moderator)]

mathäus8 schrieb:
> warum sollte man, wenn es den GNU GCC gibt, einen weniger freien
> Compiler unterstützen?

Die LLVM-Entwickler dürften ihre Lizenz durchaus als freier empfinden,
denn sie auferlegt ihnen weniger Zwänge als die GPL.

Fakt ist, dass LLVM dem GCC deutlich den Rang strittig gemacht hat, die
unbestrittene Nummer 1 der Opensource-Compiler zu sein (jetzt mal
nicht in so einer Nische wie dem AVR, sondern bei den Mainstream-CPUs).
Dass er weniger historischen Ballast mitzuschleifen hatte als GCC,
wurde ja schon genannt.  Seit es mit Clang noch ein Frontend gibt,
welches GCC-aufrufkompatibel ist, sodass man seinen Code 1:1 da
reinfüttern kann, wurde ziemlich schnell klar, dass beispielsweise
die Qualität der Warnungen von LLVM nochmal ein ganzes Stück besser
ist als die von GCC (manch bis dato unerkannter Bug trat dann plötzlich
zu Tage).

Wenn du genau hinschaust, dann wird Clang mittlerweile auch bei den
Entwicklern der Linux-Community durchaus gern als Prüfstein für ihren
Code benutzt, selbst wenn sie schätzungsweise aus politischen Gründen
ihre offiziellen Builds weiterhin mit GCC ausliefern werden.

[Tim . (cpldcpu)]

Was nur mit LLVM-AVR?

[Beobachter (Gast)]

Vor allem hat sich GCC erst dann bewegt, als der LLVM merklich auf dem 
Radar aufgetaucht ist. Gerade beim Thema Fehlermeldungen. Beim GCC 
konnte man sinngemäß immer nur lesen, das sei zu kompliziert. LLVM hat 
es einfach gemacht.

Langfristig bin ich mir ziemlich sicher, wird LLVM dem GCC den Rang 
ablaufen, aus einem ganz einfachen Grund: LLVM hält die Einstiegshürde 
fürs Compiler-Hacking sehr, sehr tief.

[Andreas H. (ahz)]

Jörg W. schrieb:
> mathäus8 schrieb:
>> warum sollte man, wenn es den GNU GCC gibt, einen weniger freien
>> Compiler unterstützen?
>
> Die LLVM-Entwickler dürften ihre Lizenz durchaus als freier empfinden,
> denn sie auferlegt ihnen weniger Zwänge als die GPL.

Es gibt relativ eindeutige Aussagen von RMS, warum die GPL so ist, wie 
die GPL ist.

Und eigentlich ist das auch gar nicht so schlecht. Die GPL verhindert 
z.B., dass Code zurückgehalten wird, der dann durch proprietäre 
Änderungen zu einer Abhängigkeit vom Publisher führen würde.


Und nur für die Akten (weil das immer wieder falsch erzählt wird):
Du darfst GPL Software auch verkaufen. Auch für viiiiel Geld.

Wenn Du also ein Programm mit Modulen entwickelst, die unter GPL stehen, 
dann steht Dein Programm erst mal auch unter GPL.
Dann ist es durchaus ok es garnicht zu vertreiben (und dann musst Du die 
Quellen auch nicht rausgeben, weil nicht gepublished) oder z.B. $250K 
für das Programm zu verlangen.

Im zweiten Fall MUSST Du dann aber auch die kompletten Quellen verfügbar 
machen (das sagt ja z.B. die GPL).

Beim GCC (u.a.) kommt noch dazu, dass die erzeugten Programme NICHT 
automatisch unter GPL sind. DU legst die Lizenz fest. Darum haben ja die 
"notwendigen Helferlein", z.B. crt0 & runtime libs eine eigene Lizenz.


Was unter GPL aber NICHT geht sind diese ärgerlichen Aktionen, wo Leute 
erst Sachen mit freier (im Sinne von "abgreifbarer") Software 
entwickeln, dann als "Freeware" in-Field testen & verbessern und 
schließlich Geld dafür nehmen.
Und dass z.B. genau das NICHT geht find ich persönlich ziemlich gut^^
Dass man damit trotzdem über die Runden kommt zeigen ja z.B. RedHat etc. 
& AdaCore (die ja beide auch fleissig am GCC bauen).

Grüße
Andreas

[Jörg W. (dl8dtl) (Moderator)]

Andreas H. schrieb:
> Es gibt relativ eindeutige Aussagen von RMS, warum die GPL so ist, wie
> die GPL ist.

Klar.  Er ist auch religiös in dieser Richtung.  Er musste ja auch,
nachdem die Leute ein funktionierendes Linux einem nie so richtig
fertig werdendem Hurd vorzogen, den Term „GNU/Linux“ vehement ins
Feld führen.

Andere Leute sind es nicht – und das ist durchaus auch gut so.

Beides sind zwei sehr verschiedene Ansichten über das, was jeder so
als „frei“ empfindet; keine der beiden Ansichten sollte für sich den
Anspruch erheben, besser als die andere zu sein.

Allein die Tatsache, dass man überhaupt über sowas diskutieren muss:

> Beim GCC (u.a.) kommt noch dazu, dass die erzeugten Programme NICHT
> automatisch unter GPL sind.

zeigt, dass die GPL durchaus ihre Haken und Ösen hat.  Eigentlich
sollte das ja eine völlige Selbstverständlichkeit sein.

So, jetzt aber back to topic.

Zitat aus dem README des oben genannten github-Projekts:

Note: The backend is currently in the process of being merged into LLVM
trunk, so development has halted until that is finished.

Ich vermute daher, dass wir künftig durchaus noch was davon sehen
werden.

Noch ein Zitat:

We would like to be able to compile any program that AVR-GCC can, have
comparable diagnostics, and on-par performance.

[Tim . (cpldcpu)]

Habe ein wenig mit dem oben verlinkten llvm-avr herumgespielt.

Achtung: Ein Build von LLVM-AVR dauert wirklich ewig. Am besten einen 
schnellen Rechner nutzen und darauf achten, dass evtl. multithreading 
optionen gesetzt sind.

Testprogramm:

#define uint8_t unsigned char
#define uint16_t unsigned short

int main(void) {

  for (uint16_t i=0; i<32000; i++) {
    *((volatile uint8_t *)0x10)=i>>2;
  }

  for (uint16_t i=0; i<32000; i++) {
    *((volatile uint8_t *)0x10)+=1;
  }

  return 0;
}

Output mit AVR-GCC:

> avr-gcc -Os hello.c -std=c99 -S

  .file  "hello.c"
__SP_H__ = 0x3e
__SP_L__ = 0x3d
__SREG__ = 0x3f
__tmp_reg__ = 0
__zero_reg__ = 1
  .section  .text.startup,"ax",@progbits
.global  main
  .type  main, @function
main:
/* prologue: function */
/* frame size = 0 */
/* stack size = 0 */
.L__stack_usage = 0
  ldi r24,0
  ldi r25,0
.L3:
  mov r18,r24
  mov r19,r25
  lsr r19
  ror r18
  lsr r19
  ror r18
  sts 16,r18
  adiw r24,1
  cp r24,__zero_reg__
  ldi r18,125
  cpc r25,r18
  brne .L3
  ldi r24,0
  ldi r25,lo8(125)
.L5:
  lds r18,16
  subi r18,lo8(-(1))
  sts 16,r18
  sbiw r24,1
  sbiw r24,0
  brne .L5
  ldi r24,0
  ldi r25,0
  ret
  .size  main, .-main
  .ident  "GCC: (GNU) 4.8.2"

Output mit clang/llc:

> clang -Os -emit-llvm hello.c -c -o hello.bc
> llc hello.bc -march=avr -o hello_llvm-avr.s

  .text
  .file  "hello.bc"
  .globl  main
  .p2align  1
  .type  main,@function
main:                                   ; @main
; BB#0:
  ldi  r30, 0
  ldi  r31, 0
  ldi  r24, 0
  ldi  r25, 125
LBB0_1:                                 ; =>This Inner Loop Header: Depth=1
  movw  r18, r30
  lsr  r19
  ror  r18
  lsr  r19
  ror  r18
  sts  16, r18
  adiw  r30, 1
  cp  r30, r24
  cpc  r31, r25
  brne  LBB0_1
; BB#2:                                 ; %.preheader.preheader
  ldi  r30, 0
  ldi  r31, 0
LBB0_3:                                 ; %.preheader
                                        ; =>This Inner Loop Header: Depth=1
  lds  r18, 16
  inc  r18
  sts  16, r18
  adiw  r30, 1
  cp  r30, r24
  cpc  r31, r25
  brne  LBB0_3
; BB#4:
  ldi  r22, 0
  ldi  r23, 0
  movw  r24, r22
  ret
.Lfunc_end0:
  .size  main, .Lfunc_end0-main

[Tim . (cpldcpu)]

Sieht auf der ersten Blick schon alles recht brauchbar aus. Das Projekt 
ist auch extrem aktiv. Frage mich nur, wann der erwähnt Merge in das 
Hauptprojekt abgeschlossen ist.

Noch nützlicher als ein AVR-LLVM Backend wäre allerdings eines für STM8 
:)

[Johann L. (gjlayde)]

Tim  . schrieb:
> Output mit AVR-GCC:
>   mov r18,r24
>   mov r19,r25
>
> Output mit clang/llc:
>   movw  r18, r30

Um sinvoll vergleichen zu können, sollte der gleiche Core / 
Instruktionssatz erlaubt sein, was in deinem Beispiel nicht der Fall 
ist:  du verbietest avr-gcc, MOVW zu verwenden, dem avr-llvm ist es 
hingegen erlaubt...

[Luxan (Gast)]

@Tim

Was testet das Testprogramm? Wäre es nicht besser eins zu nehmen, das 
etwas länger ist?

[Tim . (cpldcpu)]

Johann L. schrieb:
> Um sinvoll vergleichen zu können, sollte der gleiche Core /
> Instruktionssatz erlaubt sein, was in deinem Beispiel nicht der Fall
> ist:  du verbietest avr-gcc, MOVW zu verwenden, dem avr-llvm ist es
> hingegen erlaubt...

Stimmt. Die Standardeinstellungen der Compiler scheinen in der Wahl der 
Cores unterschiedlich zu sein. Bei gleiche Core-Wahl würde GCC noch zwei 
Befehle einsparen.

Luxan schrieb:
> Was testet das Testprogramm? Wäre es nicht besser eins zu nehmen, das
> etwas länger ist?

Leider ist es mir noch nicht gelungen das Frontend (clang) mit 
AVR-Anpassungen zu compilieren. Daher habe ich auf das Aufsetzen der 
gesamten Toolchain verzichtet. Komplexeren Code konnte ich daher nicht 
testen. Die Beispiele oben nutzen das standard front end.

[Philipp Klaus K. (pkk)]

Tim  . schrieb:
> Noch nützlicher als ein AVR-LLVM Backend wäre allerdings eines für STM8
> :)

Das ginge nicht so einfach. LLVM (und GCC) brauchen eigentlich möglichst 
viele, möglichst gleichartige Register, um guten Code zu erzeugen.
SDCC dagegen kommt viel besser mit Architekturen mit wenigen, sehr 
unterschiedlichen Registern zurecht.

Im Prinzip wäre es natürlich möglich, SDCC mit LLBm zu kombinieren. Also 
das Frontend vom LLVM und ein paar high-level-Optimierungen aus LLVM zu 
verwenden, und dann LLVM IR nach SDCC iCode zu übersetzen. Dann hätte 
man das Frontend von SDCC durch Teile von LLVm ersetzt.

Philipp

[Johann L. (gjlayde)]

Tim  . schrieb:
> Die Beispiele oben nutzen das standard front end.

Ist das der Grund, warum int 32 Bits hat?  Oder hab ich mich da versehen 
("return 0" setzt R22-R25 auf 0).

> Johann L. schrieb:
>> Um sinvoll vergleichen zu können, sollte der gleiche Core /
>> Instruktionssatz erlaubt sein, was in deinem Beispiel nicht der Fall
>> ist:  du verbietest avr-gcc, MOVW zu verwenden, dem avr-llvm ist es
>> hingegen erlaubt...
>
> Stimmt. Die Standardeinstellungen der Compiler scheinen in der Wahl der
> Cores unterschiedlich zu sein. Bei gleiche Core-Wahl würde GCC noch zwei
> Befehle einsparen.

Und bei einer aktuellen GCC-Version noch mehr :-)

Aber momentan scheint eh jeder den avr-llvm zu bevorzugen; neue Besen 
kehren eben gut...

[Tim . (cpldcpu)]

Philipp Klaus K. schrieb:
> Im Prinzip wäre es natürlich möglich, SDCC mit LLBm zu kombinieren. Also
> das Frontend vom LLVM und ein paar high-level-Optimierungen aus LLVM zu
> verwenden, und dann LLVM IR nach SDCC iCode zu übersetzen. Dann hätte
> man das Frontend von SDCC durch Teile von LLVm ersetzt.

Naja, das entspricht doch genau dem Konzept von LLVM? Ein STM8 Backend 
würde den intermediate code zu STM8 code compilieren. Wäre es wirklich 
effizienter, wenn das Backend Details des ursprünglichen C-Codes 
"kennt"? Clang/LLVM ist doch eigentlich der Beweis für das Gegenteil.

Ein Vorteil ist, dass man mit dem gleichen Backend auch Frontends für 
andere Programmiersprachen nutzen könnte. z.B. gibt es basierend auf 
AVR-LLVM bereits einen Rust-Compiler:

https://github.com/avr-rust/rust/

[Tim . (cpldcpu)]

Johann L. schrieb:
> Tim  . schrieb:
>> Die Beispiele oben nutzen das standard front end.
>
> Ist das der Grund, warum int 32 Bits hat?  Oder hab ich mich da versehen
> ("return 0" setzt R22-R25 auf 0).

Yep. Der Returntyp hätte natürlich uint16_t sein sollen. Habe ich 
übersehen.

Johann L. schrieb:
> Und bei einer aktuellen GCC-Version noch mehr :-)

2 bytes, s.u. :)

>
> Aber momentan scheint eh jeder den avr-llvm zu bevorzugen; neue Besen
> kehren eben gut...

Warum? So viel funktioniert noch nicht. Bin gerade fleissig am 
Bug-sammeln. Bei einem ASM/C mix läuft es noch nicht wirklich rund.

[Tim . (cpldcpu)]

Habe inzwischen AVR-LLVM komplett mit frontend kompiliert. (Über Debian 
Jessie im VM, ein aktuelles Mint war leiter zu alt und hat bei den 
Dependencies herumgezickt.)

Unten ein besserer Vergleich des Codes von oben.

GCC 4.9.3 entfernt ein unnötiges Compare im Vergleich zu GCC 4.8.1 (-2 
bytes).

Interessanterweise erzeugt LLVM für die erste Schleife besseren Code, 
während GCC bei der zweiten SChleife besser ist. GCC invertiert den 
Schleifenzähler und spart dadurch ein Compare ein.

LLVM aktueller Build:

> clang -Os -c -S --target=avr hello.c -o hello_llvm_t85.s -mmcu=attiny85

  .text
  .file  "hello.c"
  .globl  main
  .p2align  1
  .type  main,@function
main:                                   ; @main
; BB#0:                                 ; %entry
  ldi  r30, 0
  ldi  r31, 0
  ldi  r24, 0
  ldi  r25, 125
LBB0_1:                                 ; %for.body
                                        ; =>This Inner Loop Header: Depth=1
  movw  r18, r30
  lsr  r19
  ror  r18
  lsr  r19
  ror  r18
  sts  16, r18
  adiw  r30, 1
  cp  r30, r24
  cpc  r31, r25
  brlo  LBB0_1
; BB#2:                                 ; %for.body6.preheader
  ldi  r30, 0
  ldi  r31, 0
LBB0_3:                                 ; %for.body6
                                        ; =>This Inner Loop Header: Depth=1
  lds  r18, 16
  inc  r18
  sts  16, r18
  adiw  r30, 1
  cp  r30, r24
  cpc  r31, r25
  brlo  LBB0_3
; BB#4:                                 ; %for.cond.cleanup5
  ldi  r24, 0
  ldi  r25, 0
  ret
.Lfunc_end0:
  .size  main, .Lfunc_end0-main

GCC 4.8.1

> avr-gcc -Os -c -S hello.c -std=c99 -o hello_gcc_t85.s -mmcu=attiny85

  .file  "hello.c"
__SP_H__ = 0x3e
__SP_L__ = 0x3d
__SREG__ = 0x3f
__tmp_reg__ = 0
__zero_reg__ = 1
  .section  .text.startup,"ax",@progbits
.global  main
  .type  main, @function
main:
/* prologue: function */
/* frame size = 0 */
/* stack size = 0 */
.L__stack_usage = 0
  ldi r24,0
  ldi r25,0
.L3:
  movw r18,r24
  lsr r19
  ror r18
  lsr r19
  ror r18
  sts 16,r18
  adiw r24,1
  cp r24,__zero_reg__
  ldi r18,125
  cpc r25,r18
  brne .L3
  ldi r24,0
  ldi r25,lo8(125)
.L5:
  lds r18,16
  subi r18,lo8(-(1))
  sts 16,r18
  sbiw r24,1
  sbiw r24,0
  brne .L5
  ldi r24,0
  ldi r25,0
  ret
  .size  main, .-main
  .ident  "GCC: (GNU) 4.8.1"

GCC 4.93

> avr-gcc -Os -c -S hello.c -std=c99 -o hello_gcc_t85.s -mmcu=attiny85

  .file  "hello.c"
__SP_H__ = 0x3e
__SP_L__ = 0x3d
__SREG__ = 0x3f
__tmp_reg__ = 0
__zero_reg__ = 1
  .section  .text.startup,"ax",@progbits
.global  main
  .type  main, @function
main:
/* prologue: function */
/* frame size = 0 */
/* stack size = 0 */
.L__stack_usage = 0
  ldi r24,0
  ldi r25,0
.L2:
  movw r18,r24
  lsr r19
  ror r18
  lsr r19
  ror r18
  sts 16,r18
  adiw r24,1
  cp r24,__zero_reg__
  ldi r18,125
  cpc r25,r18
  brne .L2
  ldi r24,0
  ldi r25,lo8(125)
.L3:
  lds r18,16
  subi r18,lo8(-(1))
  sts 16,r18
  sbiw r24,1
  brne .L3
  ldi r24,0
  ldi r25,0
  ret
  .size  main, .-main
  .ident  "GCC: (AVR_8_bit_GNU_Toolchain_3.5.1_1671) 4.9.2"

[Jörg W. (dl8dtl) (Moderator)]

Johann L. schrieb:
> Aber momentan scheint eh jeder den avr-llvm zu bevorzugen

„Jeder“?  Im Moment sehe ich hier gerade mal einen, der es überhaupt
mal testet …

[Gilles R. (roodemol)]

Bei LLVM und Clang tut sich recht viel und das AVR Backend ist 
mittlerweile im Trunk gelandet. Aus diesem Grund habe ich mich jetzt 
auch ein wenig mit dem Thema auseinandergesetzt. Da man noch keine 
fertigen Binärpakete herunterladen kann, hier mal eine kleine Anleitung 
wie ich das ganze auf meinem Rechner (Debian Jessie) übersetzt habe.
* Die CMake Version auf meinem Rechner war zu alt, deshalb habe ich die 
Version aus den Backports installiert:

apt-get -t jessie-backports install

Vorher muss man allerdings noch sources.list Datei mit dieser Zeile 
ergänzen:

deb http://ftp.debian.org/debian jessie-backports main

Genauere Details findet man hier: 
https://backports.debian.org/Instructions/
* Jetzt kann man den Sourcecode auschecken:

svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm-avr
cd llvm-avr/tools/
svn co http://llvm.org/svn/llvm-project/cfe/trunk clang
cd ../projects/
svn co http://llvm.org/svn/llvm-project/compiler-rt/trunk compiler-rt
cd ..
mkdir build

* In CMakeLists.txt fehlt noch die AVR Plattform, also einfach die Datei 
mit einem Texteditor öffnen und ergänzen, z.B nur für AVR ohne 
Debugcode:

...
set(LLVM_ALL_TARGETS
  AArch64
  AMDGPU
  ARM
  AVR
  BPF
  Hexagon
...

* Damit sind die Vorbereitungen abgeschlossen und man kann die Makefiles 
erzeugen:

cd build
cmake -G "Unix Makefiles" -DLLVM_TARGETS_TO_BUILD="AVR" -DCMAKE_BUILD_TYPE=Release ../

und übersetzen:

make

Nach ein paar Tassen Kaffee sollte man bin Unterverzeichnis das Resultat 
der Arbeit finden.

[Kaj (Gast)]

LLVM 4.0 unterstützt AVR-Microcontroller und Koroutinen
https://www.golem.de/news/compiler-baukasten-llvm-4-0-unterstuetzt-avr-microcontroller-und-koroutinen-1703-126715.html

[Andreas (Gast)]

@GillesR hast du mal probiert, ob der CLANG konstante variablen in den 
Flash packt? Muss man da auch mit sowas wie PROGMEM arbeiten?

Gruß Andreas

[Gilles R. (roodemol)]

Das kann ich leider nicht beantworten. Es gibt einen Bugreport um 
verschiedene Address-Spaces, z.B. mit __flash, zu nutzen: 
https://bugs.llvm.org/show_bug.cgi?id=31568
Genutzt habe ich das allerdings noch nie.

[Wilhelm M. (wimalopaan)]

Andreas schrieb:
> Muss man da auch mit sowas wie PROGMEM arbeiten?

Der address_space(1) wird ins flash gepackt:

const int x __attribute__((address_space(1))) = 3;

[O S S Hans (Gast)]

Andreas H. schrieb:
> Wenn Du also ein Programm mit Modulen entwickelst, die unter GPL stehen,
> dann steht Dein Programm erst mal auch unter GPL.
> Dann ist es durchaus ok es garnicht zu vertreiben (und dann musst Du die
> Quellen auch nicht rausgeben, weil nicht gepublished) oder z.B. $250K
> für das Programm zu verlangen.
>
> Im zweiten Fall MUSST Du dann aber auch die kompletten Quellen verfügbar
> machen (das sagt ja z.B. die GPL).

Wie Microchip mit seinen XC Compilern toll veranschaulicht.

Wo ist deren Quellcode?

[Johann L. (gjlayde)]

O S S Hans schrieb:
> Andreas H. schrieb:
>> Im zweiten Fall MUSST Du dann aber auch die kompletten Quellen verfügbar
>> machen (das sagt ja z.B. die GPL).
>
> Wie Microchip mit seinen XC Compilern toll veranschaulicht.
>
> Wo ist deren Quellcode?

Prinzipiell wäre es auch in Ordnung, die Quellen auf Anfrage zu liefern, 
etwa auf dem Postweg per DVD.  Muss nicht mal kostenlos sein, man darf 
es zum Selbstkostenpreis (DVD + Porto) machen.  Und es muss in einem 
üblichen, elektronishc lesbaren Format / Medium gespeichert sein, also 
nicht auf Steintafel oder Kernspeicher.

I.d.R. ist es jedoch für beide Seiten bequemer, die Quellen auf einer 
Webseite zu veröffentlichen.  Ist aber keine Bedingung.

Und natürlich besteht die Verpflichtung, die Quellen zu liefern nur 
gegenüber jemand, der auf rechtmäßigem Weg die Binaries von dir erhalten 
hat.

Wenn also A im Auftrag von B GPL-Software entwickelt, B z.B. dafür 
bezahlt und die Binaries erhält, dann hat B Anspruch darauf, dass A ihm 
die Quellen zum Selbstkostenpreis zur Verfügung stellt (wobei es keine 
Rolle spielt, wieviel und ob und was B für die Entwicklung bezahlt hat 
oder nicht).

Wenn C die Binaries bei A oder B mopst, hat er keinen Anspruch auf die 
Quellen.  Und wenn B die Binaries an C weitergibt, ist er auch 
verpflichtet, C die Quellen zu geben.  C hat aber keinen Anspruch 
gegenüber A.  Zumindest versteh ich die GPL so, lass mich da aber gerne 
eines Besseren belehren.

Und ich hab mir MicroChip GCC-Quellen irgendwann mal angesehen.  Weiß 
aber nicht mehr, für welche Architektur das war (Pic32?) weil ich das 
Gesehene direkt wieder verdrängt habe um nicht dauerhaft Schaden zu 
nehmen.