MaWin schrieb:> Ihr interpretiert da ganz einfach viel zu viel rein.
Nein, ich wollte damit auch nicht ausdrücken das du dich falsch verhälst
- manchmal vielleicht ein Ticken zu bissig
du machst genau das warum ich hier mitlesen - die interessierten
informieren
und das ist gut
Cppbert schrieb:> Es ist völlig unrelevant für die Qualitäten einer Sprache oder> Betriebsystem wie sich dessen subjektiv wahrgenommene Community verhält,> kein erfahrener Entwickler lässt sich davon in irgendeiner Form> beeinflussen
Das ist die Theorie.
Ich finde z.B. spannend, wie wohl Rust auf Solaris läuft. Habe aber im
Moment aber keinen Rechner frei zum testen frei.
VM finde ich nicht so hilfreich. Ich will mir ja direkt die
Software/Hardware-Situation ansehen.
nightly Build wird für webassembly empfohlen, sollte also grundsätzlich
funktionieren.
Standaloneversionen überzeugen mich bisher noch nicht. Wie soll das auch
sinnvoll gehen?
rbx schrieb:> Ich finde z.B. spannend, wie wohl Rust auf Solaris läuft.
was meinst du - ob das kompilieren geht oder wie die schnell die
Applikation läuft, oder...?, sollte sich nicht von einem C/C++ Code
unterscheiden - so lange die Stdandard-Lib-Unterschiede nicht zu gross
sind
Wird ja wenn dann vom LLVM kompiliert und der wird auch beim Clang unter
der Haube verwendet, gibt es Rust für Solaris oder Clang für Solaris?
rbx schrieb:> nightly Build wird für webassembly empfohlen
Wo hast du diese wirre Information denn wieder aufgeschnappt?
https://rustwasm.github.io/book/game-of-life/setup.html> The Rust and WebAssembly experience is riding the Rust release trains> to stable! That means we don't require any experimental feature> flags. However, we do require Rust 1.30 or newer.
cppbert schrieb:> gibt es Rust für Solaris oder Clang für Solaris?
du schaust dir offenbar gar nicht die Links von Jörg an? Naja, und wer
Daniel ist, ist dir auch nicht so recht klar, und dass es professionelle
Leute sind, die nach der Zukunft von Rust gefragt hatten scheinbar auch
nicht. Ts..
Das mit Solaris war auch nur ein Hinweis auf Community-Problemchen.
Viele professionelle Hansel müssen sowieso das Zeug nehmen/bearbeiten,
was sie vorgesetzt kriegen, oder nachplappern, was die Bwl-Abteilung
haben will. Nochmal Ts..
MaWin schrieb:> Wo hast du diese wirre Information denn wieder aufgeschnappt?
Das hatte ich mich auch gefragt, bzw. fragen müssen, ich kenne nämlich
die offiziellen Beschreibungen bei Rust oder bei Mozilla.
Es könnte was mit Arch zu tun gehabt haben, aber ganz sicher bin ich mir
nicht.
https://aur.archlinux.org/packages/rust-nightly-bin
rbx schrieb:
(Solaris)
> VM finde ich nicht so hilfreich. Ich will mir ja direkt die> Software/Hardware-Situation ansehen.
Wobei für einen Compiler eine VM schon erstmal genügen sollte.
Ich habe hier zwar noch eine Solaris-Kiste, aber die ist hornalt
(SunFire V210). War mal gedacht als Big-endian-Testmaschine, habe ich
jetzt aber schon lange nicht mehr eingeschaltet, dient eigentlich nur
noch als Fachboden im Rack. ;-) Ob auf dem alten Solaris ein moderner
Compiler noch lauffähig ist, wage ich zu bezweifeln.
rbx schrieb:> Das mit Solaris war auch nur ein Hinweis auf Community-Problemchen
Solaris interessiert mich nicht mehr seit der Support bei meinen Kunden
dafuer begraben wurde, ich glaube Solaris ist jetzt auch nicht mehr so
relevant bei uns, im asiatischen Raum ist es wohl noch stärker
verbreitet, aber ich hab schon lange keinen Kontakt mehr, Linux löst die
Systeme alle langsam ab
Jörg W. schrieb:> Ich denke, dass das seit der Übernahme durch Oracle praktisch nur> noch> für Datenbankserver genutzt wird.
Ich sehe das System auch als Nearly-Dead an, FreeDOS und ReactOS haben
wenigstens noch einen Spass-Faktor - Solaris nervt nur noch seit Oracle
das Projekt gegen die Wand fährt
und ich vestehe sowiso nicht warum jetzt FreeDOS oder ein sterbendes
Solaris plötzlich irgendwie relevant ist - ja OK FreeDOS lässt sich mit
GCC-IA16 bauen aber das ist ein GCC Fork der von einer Person gepflegt
wird und noch leider Jahre weg ist von einer Mainline Intergration (und
es war einfach nur ein riesen Glück das jemand einen echten 16bit
bauenden GCC probiert hat) und für Systeme auf dem der LLVM funktioniert
ist Rust definitiv nicht unmöglich - sobald die GCC-Rust Leute (was noch
ein paar Jahre dauern wird) fertig sind geht dann Rust auch für alle GCC
Platformen - also wieso sprechen wir über sowas?
Für alte oder Legacy Projekte werde ich wie immer C/C++ oder das
notwendige nutzen, mit Freude - aber ich würde schon gerne sehen das ich
die nächsten 20 Jahren noch erlebe das sich vielleicht etwas
günstigeres/einfacheres/fähigeres durchsetzt - und wenn nicht mach ich
eben bis zu meinem Ableben C/C++ - so wie schon die letzten 30 Jahre :)
--out-dir DIR Write output to compiler-chosen filename in <dir>
35
--explain OPT Provide a detailed explanation of an error message
36
--test Build a test harness
37
--target TARGET Target triple for which the code is compiled
38
-A, --allow LINT Set lint allowed
39
-W, --warn LINT Set lint warnings
40
--force-warn LINT
41
Set lint force-warn
42
-D, --deny LINT Set lint denied
43
-F, --forbid LINT Set lint forbidden
44
--cap-lints LEVEL
45
Set the most restrictive lint level. More restrictive
46
lints are capped at this level
47
-C, --codegen OPT[=VALUE]
48
Set a codegen option
49
-V, --version Print version info and exit
50
-v, --verbose Use verbose output
51
52
Additional help:
53
-C help Print codegen options
54
-W help Print 'lint' options and default settings
55
--help -v Print the full set of options rustc accepts
56
57
[rbx@fe1 ~]$
..
1
rustc --version
2
rustc 1.56.1 (Fedora 1.56.1-1.fc33)
3
[rbx@fe1 ~]$
Ich hatte ja gewisse Bedenken hinsichtlich des Speicherplatzes..
naja, so grob: Rust ist eine Programmiersprache ohne Compiler/Linker -
ist eigentlich auch neu.
64 Bit-Linker habe ich auf Windows nicht. Der von D ist wohl auch 32 Bit
- kann ich gerade nicht gucken, schreibe ja auf Fedora.
Watcom habe ich als 32 Bit, und möchte mir diese Installation auch nicht
mit der 64Bit-Variante vermurksen
Möglicherweise müsste man sich den Linker selber basteln? Dann hatte ich
mal in Solaris-Buch geschaut, ob es da etwas erhellendes zum Thema
Linker gibt: eigentlich nichts.
Aktuell auf der Haben-Seite: zumindest python ist standardmäßig drin.
Wäre vielleicht was für ein Supertyp oder wie hieß der nochmal?
LLVM wäre eine gute Option. Wieviel Speicherplatz braucht das, und wie
kriegt man die Installation auf Userspace hin? Der Installer, den ich
hatte, rief sofort nach Adminrechten.
LLVM könnte für Solaris auch eine Option (bezüglich Rust) sein.
Die Relevanz? Es ist doch schon irgendwie traurig, das mit OpenSolaris.
Vielleicht bräuchte es noch eine OpenSolaris Foundation, oder ähnliches.
Die Features wollte ich eigentlich nicht abtippen, kann ich aber doch
mal machen.
- Support for multiple hardware architectures, including both SPARC and
32-bit and 64-bit x86based systems. OpenSolaris also performs well in
many industry benchmarks.
- High scalabitity. OpenSolaris runs on both single processor maschines
and multiprocessor systems with hundrets of CPUs and terrabytes of RAM
- Innovative file systems and volume manager support. Solaris uses a
Virtual File System (VFS) layer so that different file systems can be
plugged in on top of it relatively easely. In addition to the standard
Unix File System (UFS), OpenSolaris includes the Solaris Volume Manager
(SVM) and the new ZFS.
- Networking features, including a kernel-level, high performance TCP/IP
stack, IPv6 support, IPsec, Network Auto-Magic (NWAM) for automatic
detection and configuration of network interfaces, and IP Network
Multipathing (IPMP for fault tolerance and load balancing.
- Complex ressource management, including processor pools, physical
memory controls, and fair share scheduler.
- Sophisticated security, including role-based access control (RBAC),
configurable privileges, and trusted extensions.
- Rich observability and debugging support, including myriad system
monitor tools, the Modular Debugger (MDB), and the dynamic tracing
facility (DTrace).
- Predictive self-healing features in the form of the Fault Management
Architecture (FMA) and Service Management Facility (SMF). They work
together to detect hardware and software faults an take appropriate
action.
- Multiple forms of virtualization. In addition to the
operating-system-level virtualization of Solaris Zones, OpenSolaris
offers support for xVM Hypervisor, Logical Domains (LDoms), and
VirtualBox, and runs in VMware and other virtualization frameworks.
- Sophisticated 64bit fully preemptable kernel. The OpenSolaris kernel
is also modular - device drivers can be installed without requiring a
system boot, and features can be configured without compiling the
kernel. The virtual memory subsystems uses demand paging for greater
performance and less memory usage. The process scheduling systems
support multiple scheduling classes, including timeshare, real time,
interactive, fair share, and fixed priority.
- Full POSIX compliance with a rich application programming API,
including support for 64-bit applications.
- Integrated AMP stack (Apache, MySQL, PHP) for running web services.
------------------
Und dann noch (das war aber so 2006-2007)
"The Sun Studio compilers have better performance in many cases then do
the GCC compilers"
..und jetzt ist mein Kaffee kalt ;)
Deiner ganzer Post ist künstlich Fett (warum postest du die ganze rustc
Ausgabe?) und dann noch Solaris Feature Werbung, der Rest ist fast wie
immer halbwissen Technik blabla ohne jeglichen Hintergrund, kannst du
auch anstaendig oder schreibst du einfach immer jeden Gedanken auf der
so durch deinen Kopf schwirrt
rbx schrieb:>> warum postest du die ganze rustc>> Ausgabe?>> Weil ich so darüber lachen musste.
beim gcc, MinGW, Clang, Turbo C, Microsoft C, Microsoft cl, open-watcom,
D Kompiler sieht das doch teilweise noch viel wilder aus? d.h. bei alle
gängigen Kompilern der Früh und Neuzeit
ich glaube dir fehlt sehr viel Erfahrung und du fröhnst hier nur völlig
unreflektiert dein Technik-Interesse ohne echten Background - oder
besser gesagt so lesen sich deine Post sehr häufig - und da du recht
stupide einfach so weiter postest hat das schon echte Troll-Qualität
cppbert schrieb:> beim gcc, MinGW, Clang, Turbo C, Microsoft C, Microsoft cl, open-watcom,> D Kompiler sieht das doch teilweise noch viel wilder aus?
Naja, nicht ganz.
1
$ cc
2
cc: error: no input files
Warum man gleich unaufgefordert (statt mit -h oder --help oder so) eine
mehrseitige Hilfe bringen muss, nun, mag Geschmackssache sein. Ist aber
wohl auch mit Abstand der unwesentlichste Punkt überhaupt, darüber kann
man sich beschweren, wenn es sonst keine Themen mehr gibt. ;-)
cppbert schrieb:> und da du recht> stupide einfach so weiter postest
Machst du doch auch. Du hast noch nicht mal den Witz verstanden, warum
ich so lachen musste, Und so postest munter und zusammenhangbefreit
drauflos, wo wohl noch größerer Ausgaben rauskommen.
Und darauf baust du dann deine Persönlichkeitstheorie auf.
Ich bin zwar kein Arzt, aber..
rbx schrieb:> Du hast noch nicht mal den Witz verstanden, warum ich so lachen musste
Dann erkläre den Witz doch mal, ich dachte du meinst den Umfang der Help
Ausgabe, oder meinst du ein spezifisches Detail das mir in der halben
Seite Text nicht aufgefallen ist? Oder belustigt dich das default
Verhalten die Hilfe gleich zu zeigen?
Wilhelm M. schrieb:> Was möchtest Du uns damit sagen?
Seine allumfassende Unkenntnis.
Die hat er ja nun mehrfach hier bewiesen.
Wollen wir rbx nicht einfach ignorieren?
Mir wird das jedenfalls zu dumm. Je öfter man ihm antwortet, desto
länger, wirrer und sinnloser werden seine "Beiträge".
Kurze Nachfrage, 🐧 DPA 🐧
Hast du deinen Arsch eigentlich hochbekommen und geforked?
Also zum Nullkostenpreis den (nicht vorhandenen) Schaden vermieden?
Ich schliesse mich übrigens Jörg W. (dl8dtl) an: Ist nur für Datenbanken
relevant ... also macht euch keinen Kopf und konzentriert euch lieber
auf die Feiertage. Beweis, das 1.66 Enum update.
Echt wahr! (:P)
ref:
https://www.heise.de/news/Programmiersprache-Rust-1-66-erweitert-Enumerations-und-entfernt-Abhaengigkeiten-7398888.html
MaWin O. schrieb:> Seine allumfassende Unkenntnis.> Die hat er ja nun mehrfach hier bewiesen.
Also ich war 2017 schon von meinen ersten Gehversuchen mit meinem
"Rust-Blinky" auf dem STM32F103 begeistert.
Lass ihm doch Zeit!:)
tuschel Und er hat ja recht! ... es nervt echt, diese langweiligen
Leute von der Rust Community: mipsel32 ... braucht keine Sau! Hat ne
Woche gedauert, bis wir OpenSSL hinbekommen haben um auf der guten alten
Schindmähre zu reiten, MaWin*g* ... siehe github.
P.S.: Das war kein Zuspruch zu OpenSSL, sondern zum buildsystem. Die
Leute bei Ersterem haben gewiss mehr Animositäten zu beachten .... :)
@Jedzia D.
Bist du ein Clone von rbx, du schreibst auch irgendwie fast genau wie er
- so ein bisschen Fakten, bissel Emotionen, Somway Off-Topics aber
irgendwie related - wilde Mischung
oder bin ich schon so alt das mir dieser Whatsapp/Tiktok
Kommunikationsstyle einfach nicht vertraut genug ist :)
Take for example memory safety in systems programming languages. Using fuzzers and sanitizers you may be able to easily address 80% of bugs. But the remaining 20% of bugs will take some effort to find. And even when you do; code changes over time, which means that you'll be unlikely to ever afford to stop looking for these types of bugs.
2
3
Compare that with the borrow checker, which guarantees there will never be any memory safety bugs: meaning you can catagorically eliminate the concern alltogether. The 80/20 rule is often used to indicate that "80% of effort is good enough". But I think it's important to realize that sometimes achieving 100% of a solution can provide a value-add which far outweighs all incremental steps that come before it.
cppbert schrieb:> The 80/20 rule is often used to indicate that "80% of effort is good> enough". But I think it's important to realize that sometimes achieving> 100% of a solution can provide a value-add which far outweighs all> incremental steps that come before it.
Ja, das sehe ich ganz genau so.
Und der Grund ist ganz einfach: Es reicht ein einziger memory safety bug
aus, um das gesamte System zu Fall zu bringen. Ein Totalschaden,
sozusagen. Das ist bereits der worst-case, der nicht schlimmer wird, nur
weil es noch 10 weitere memory safety bugs in der Software gibt.
Ich habe schon lange kein Programm mehr abstürzen sehen. Mal ehrlich,
den zeitlichen Mehraufwand ist es nicht wert, sich mit dem checker herum
zu schlagen. Erfahrene Entwickler wie ich wissen, was sie tun.
DPA schrieb:> Ich habe schon lange kein Programm mehr abstürzen sehen. Mal> ehrlich,> den zeitlichen Mehraufwand ist es nicht wert, sich mit dem checker herum> zu schlagen. Erfahrene Entwickler wie ich wissen, was sie tun.
ich arbeite hin und wieder an einem +3 Mio Zeilen Projekt mit >40
Entwicklern
- wie viel Kontrolle hast du über deine Projekte?
Es geht nicht nur um Abstürze - es geht auch um die Folgefehler die sich
durch Speicherfehlern ergeben und die passieren oft einfach nur wenn du
auch mal durch den Code läufst - Security-Problem kommen nicht durch
abstürzende Software - und wenn deine Software nicht Secure sein muss
oder nicht so viele Leute dran arbeiten kann es einfach sein das in
deiner Domäne die Rust Features Null Bedeutung haben
Ich verdiene mein Geld häufig damit große Systeme aufzuräumen/tief
fehlerfrei zu bekommen - noch keine Software ob klein oder groß hat
einen ASAN oder TSAN ohne Findings überstanden - keiner der Fehler hat
direkt Menschen töten können, aber entfernt wurden trotzdem alle
Ich schreibe Rust fast genau so problemlos wie C++ - warum sollte ich
auf den Schutz verzichten - oder besser sogar dagegen argumentieren :)
Kein C/C++ Entwickler wechselt zu Rust nur weil seine Software ständig
abstürzt - das ist nicht der Antrieb, und das Problem hat wirklich
niemand - es ist u.a. die 100% Speichersicherheit at Kompiletime - von
Anfang bis zum Tod des Projektes
DPA schrieb:> Ich habe schon lange kein Programm mehr abstürzen sehen
Da sieht man mal wieder, dass du gar nicht weißt, wovon du sprichst.
Rust verhindert den Absturz eines defekten Programms auch nicht immer.
Aber es verhindert, dass ein solcher Fehler ausgenutzt werden kann.
> Erfahrene Entwickler wie ich wissen, was sie tun.
Ja genau.
Das wird uns seit 30 Jahren erzählt. Und die Anzahl der Security-Bugs
wurden nie weniger. Selbst mit Checker-Tools wurde die Anzahl nicht
reduziert.
Es ist also Bullshit.
Doch weißt du, was die Anzahl der Bugs (in Android) schlussendlich dann
doch reduziert - oder besser gesagt stand heute auf Null gebracht -
hat?
Rate mal.
https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html
MaWin O. schrieb:> Doch weißt du, was die Anzahl der Bugs (in Android) schlussendlich dann> doch reduziert
Das ist objektiv wahr.
> - oder besser gesagt stand heute auf Null gebracht -
Das allerdings nicht. War auch nicht im Moment deines Postings wahr.
Wird auch nirgendwo in deinem Link
https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html
behauptet. Das hast du selbst frei erfunden.
c-hater schrieb:> Das allerdings nicht. War auch nicht im Moment deines Postings wahr.> Wird auch nirgendwo in deinem Link>> https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html>> behauptet. Das hast du selbst frei erfunden.
Ach. Gut.
Da ist es ja einfach, das Gegenteil zu beweisen:
Zitat:
> Security impact>> To date, there have been zero memory safety vulnerabilities discovered in> Android’s Rust code.
Muss dir aber nicht peinlich sein. Du wolltest ja nur stänkern. Das sei
dir gegönnt.
c-hater schrieb:> behauptet. Das hast du selbst frei erfunden.
In dem Text steht das im Rust Code bisher keine security flaws
aufgetaucht sind
Aber trotzdem wuerde ich den Blog Post an sich jetzt auch nicht als
Beweis akzeptieren, aber Google, selbst die Sanitizer Entwickler und
stark im Fuzzy Bereich scheinen schon fuer den System Bereich von Rust
überzeugt zu sein, das kann man auch nicht einfach ignorieren
Cppbert schrieb:> Aber trotzdem wuerde ich den Blog Post an sich jetzt auch nicht als> Beweis akzeptieren
Hab mich blöd ausgedrückt, ich meinte nur das der Blog Post jetzt nicht
so geeignet ist Ungeläubige zu überzeugen :)
Cppbert schrieb:> Hab mich blöd ausgedrückt, ich meinte nur das der Blog Post jetzt nicht> so geeignet ist Ungeläubige zu überzeugen :)
Ich finde schon.
Er sagt:
Über mehr als eine Dekade haben wir ständig Security-Bugs und auch
Checker helfen wenig bis gar nichts.
Doch dann setzen wir Rust ein und die Anzahl der Security-Bugs reduziert
sich plötzlich auf Null.
Das, finde ich, ist schon ein einfach verständliches Argument.
Auch für Anfänger und Ungläubige.
Und ja, mir ist klar, dass auch Rust in Zukunft Securityprobleme haben
wird. Das steht ja auch im Artikel. Aber es wird sehr sehr sehr sehr
viel weniger sein, als mit allen anderen existierenden Techniken.
MaWin O. schrieb:> Doch dann setzen wir Rust ein und die Anzahl der Security-Bugs reduziert> sich plötzlich auf Null.
Memory safety bugs != security bugs.
Security bugs sind Probleme, die von anderen auf eine Art und Weise
ausgenutzt werden können, die problematisch ist, z.B. weil man dann
Dinge tun kann, die nicht vorgesehen waren. Auch so Sachen wie XSS,
fehlende Berechtigungschecks, die üblichen deserialisierungsbugs in
Java, etc. fallen darunter.
Und nicht nur sind security bugs oft keine memory safety, memory safety
bugs müssen nicht immer security bugs sein.
So wird mir z.B. ein Speicherfehler in meinem lokalen Minesweeper Game
sicher keine Sicherheitsrelevanten Probleme bereiten.
DPA schrieb:> ...
Ja. Blah.
Du kannst die Begriffe so lange verdrehen, wie du es willst.
Aus dem Kontext ist ganz offensichtlich klar, was ich gesagt habe.
Du lenkst ab.
Ich habe mich auf das bezogen, was der Artikel aussagt.
Und das ist halt:
> Früher ganz viel -> Jetzt Null> Wegen Rust.
Das ist Fakt.
Und das ist leider eindeutig. Egal, wie du es nennst.
Siggi A. schrieb:> Was fehlt jetzt noch um meinen geliebten attiny85 mit gccrs zu> programmieren?
Warum mit gccrs?
Das kannst du heute mit dem offiziellen Nightly-Release von rustc tun.
MaWin O. schrieb:> Siggi A. schrieb:>> Was fehlt jetzt noch um meinen geliebten attiny85 mit gccrs zu>> programmieren?>> Warum mit gccrs?> Das kannst du heute mit dem offiziellen Nightly-Release von rustc tun.
Die Version 1.66 hat nur avr-unknown-gnu-atmega328
cppbert schrieb:> hab ein Beispiel für deinen geliebten attiny85 gefunden - keine Ahnung> ob das qualitativ hochwertig ist
Es scheint in Teil auf dem avr-gcc zu basieren oder wenigstens wird
dessen Linker verwendet - könnte sein das es nicht ganz so
out-of-the-box funktioniert wie es gewünscht ist, aber AVR ist glaube
ich auch erst vor ein paar Monaten zu Rust gekommen
@Siggi A.
Wäre schön wenn du deine Erfahrungen damit hier einbringen könntest
MaWin O. schrieb:> Wilhelm M. schrieb:>> Die Version 1.66 hat nur avr-unknown-gnu-atmega328>> Das ist nicht wahr.
$ rustc --print target-list | grep avr
avr-unknown-gnu-atmega328
$ rustc --version
rustc 1.66.0 (69f9c33d7 2022-12-12) (Arch Linux rust 1:1.66.0-1)
cppbert schrieb:> s scheint in Teil auf dem avr-gcc zu basieren oder wenigstens wird> dessen Linker verwendet
Es "basiert" nicht auf avr-gcc.
Es wird nur der Linker verwendet. Wie bei jeder anderer Rust-Plattform
auch. Rust hat keinen eigenen Linker.
Derzeit wird für die startup-Routinen auch noch avr-libc verwendet.
> könnte sein das es nicht ganz so> out-of-the-box funktioniert wie es gewünscht ist,
Doch. Es funktioniert out of the box. Einfach so.
Probiere es doch einfach mal aus.
Rust-Nightly installieren und das tun, was im Readme eines AVR-Beispiels
steht:
https://github.com/avr-rust/template-bin.git
(Das ruduino-crate würde ich allerdings nicht empfehlen. Da gibts mit
avr-device und avr-hal besseres)
> aber AVR ist glaube> ich auch erst vor ein paar Monaten zu Rust gekommen
Das ist nicht wahr. Es ist schon seit Jahren drin.
Es war allerdings ein paar Monate lang wegen eines LLVM-Bugs defekt.
Das wurde vor ein paar Monaten behoben.
Von avr-device werden derzeit diese Chips unterstützt:
https://docs.rs/avr-device/0.4.0/avr_device/
avr-device is ein PAC. (Peripheral Access Crate). Das ist die Schicht
unter der HAL. Im PAC wird die vorhandene Hardware/Peripherie
beschrieben.
MaWin O. schrieb:> Wilhelm M. schrieb:>> $ rustc --print target-list | grep avr>> Ja, Wilhelm. Das heißt nicht, dass nur der 328er unterstützt wird.
Dann ist die Ausgabe aber sehr verwirrend ;-)
Und welche werden bei dem Target avr-unknown-gnu-atmega328
unterstützt???
Wilhelm M. schrieb:> Und welche werden bei dem Target avr-unknown-gnu-atmega328> unterstützt???
Soweit ich weiß alle. Die unterscheiden sich ja kaum auf CPU-Ebene.
Es kommt eher darauf an, was das von dir verwendete PAC unterstützt. Und
da habe ich den Link oben geliefert.
MaWin O. schrieb:> Wilhelm M. schrieb:>> Und welche werden bei dem Target avr-unknown-gnu-atmega328>> unterstützt???>> Soweit ich weiß alle. Die unterscheiden sich ja kaum auf CPU-Ebene.
Doch schon. Die Megas haben Instruktionen, die die Tinys nicht haben.
Dann werden falsche Op-Codes generiert für die Tinys, bzw. die ganz
neuen AVR werden nicht optimal genutzt.
Wilhelm M. schrieb:> Dann werden falsche Op-Codes generiert für die Tinys
Das sagst du jetzt einfach so, obwohl du es nie ausprobiert hast?
Unfassbar.
Wie gesagt, beim avr-device PAC gibt es eine Liste von unterstützten
Devices.
Schaue dir das und das Template-crate an.
MaWin O. schrieb:> Wilhelm M. schrieb:>> Dann werden falsche Op-Codes generiert für die Tinys>> Das sagst du jetzt einfach so, obwohl du es nie ausprobiert hast?> Unfassbar.
Ich glaube erst einmal nur der Ausgabe von rustc, sonst nichts. Und wenn
dort das Target mega328 steht, dann glaube ich das auch. Sonst nichts.
Wenn das target mega328 was auch bedeutet, das tiny, tiny0, tiny1,
mega0, mega0 und mega1, xmega unetrstützt werden ist das evtl. schön.
Allerdings frage ich mich dann, wie rustc dann die notwendige
Unterscheidung für den Core hin bekommt.
Aber das kannst Du sicher ganz einfach erklären.
MaWin O. schrieb:> Wilhelm M. schrieb:>> Allerdings frage ich mich dann, wie rustc dann die notwendige>> Unterscheidung für den Core hin bekommt.>> Wie wäre es, wenn du dir das template endlich einmal anschaust? Schaffst> du das?>> https://github.com/avr-rust/template-bin/blob/master/avr-atmega328p.json
Habe ich geschafft ;-)
Und dort steht ja gerade -mmcu=atmega328p.
Jetzt erklär mal bitte, wie der Code dann auf einem tiny laufen soll.
Wilhelm M. schrieb:> Allerdings frage ich mich dann, wie rustc dann die notwendige> Unterscheidung für den Core hin bekommt.
das grenzt man noch weiter ein - aber ja ich geben dir recht das hat
mich auch zuerst verwirrt - aber die von vielen hier gezeigte "das ist
dann bestimmt irgendwie ein Fehler" Mentalität kann ich echt nicht
nachvollziehen - das machen so viele hier
Wilhelm M. schrieb:> Nur MaWin behauptete zum Target atmega328 folgendes:>> MaWin O. schrieb:>> Soweit ich weiß alle.>> Und das ist definitiv falsch.
willst du jetzt wissen ob es geht oder mit MaWin das
Er-hat-recht-du-hast-recht-Spiel-spielen?
cppbert schrieb:> Wilhelm M. schrieb:>> Nur MaWin behauptete zum Target atmega328 folgendes:>>>> MaWin O. schrieb:>>> Soweit ich weiß alle.>>>> Und das ist definitiv falsch.>> willst du jetzt wissen ob es geht oder mit MaWin das> Er-hat-recht-du-hast-recht-Spiel-spielen?
Das es nicht geht in Version 1.66, weiß ich ja bereits wie oben schon
geschrieben:
$ rustc --target=avr-unknown-gnu-attiny85
error: Error loading target specification: Could not find specification
for target "avr-unknown-gnu-attiny85". Run `rustc --print target-list`
for a list of built-in targets
MaWins Sätzen sind manchmal ein wenig zu schroff - aber er kommt immer
recht schnell wieder auf den Punkt das man was erreichen/wissen will und
hat zu 95% recht - viele andere hier spielen dann Wer-hat-recht Kette
durch - um jede 5% Recht haben - das ist es nicht wert
Wilhelm M. schrieb:> Und das ist definitiv falsch.
Weil du das sagst?
Hast du beim avr-gcc auch einen separaten Compiler für jedes Target,
oder machst du das per -mmcu?
Du bist ein Laberkopp.
MaWin O. schrieb:> Wilhelm M. schrieb:>> Und das ist definitiv falsch.>> Weil du das sagst?
Nö, weil Atmel das so designed hat.
>> Hast du beim avr-gcc auch einen separaten Compiler für jedes Target,> oder machst du das per -mmcu?
Genau. Und die Option -mmcu hat rustc nicht, deswegen verwendet man dort
--target. Und ein target für attiny85 gibt es in Version 1.66 eben
nicht. S.a. mein Beitrag oben.
Wilhelm M. schrieb:> Nö, weil Atmel das so designed hat.
Atmel???
> Genau. Und die Option -mmcu hat rustc nicht, deswegen verwendet man dort> --target.
Nein, tut man nicht.
Würdest du dir endlich mal das Beispiel anschauen? Hm? Wie wäre das?
Du machst dich hier einfach nur zur Kartoffel.
MaWin O. schrieb:> Wilhelm M. schrieb:>> Nö, weil Atmel das so designed hat.>> Atmel???>>> Genau. Und die Option -mmcu hat rustc nicht, deswegen verwendet man dort>> --target.>> Nein, tut man nicht.> Würdest du dir endlich mal das Beispiel anschauen? Hm? Wie wäre das?
Es ist doch nur eine Zeile, oder?
$ rustc bla.rs --target=???
Nenne mir einfach den passenden String für ??? oder den gesamten
rustc-Aufruf für das target attiny85 in Version 1.66.
Wilhelm M. schrieb:> Es ist doch nur eine Zeile, oder?>> $ rustc bla.rs --target=???>> Nenne mir einfach den passenden String für ??? oder den gesamten> rustc-Aufruf für das target attiny85 in Version 1.66.
Niemand ruft rustc direkt auf. Auf keiner Plattform.
Deshalb kann ich dir auswendig den Aufruf auch nicht nennen.
Alle Leute, inclusive des Beispiels (!) nutzen Cargo mit einem
entsprechenden json (bei AVR) zur Konfiguration des Targets.
Was Cargo daraus für rustc macht, weiß ich nicht.
MaWin O. schrieb:> Wilhelm M. schrieb:>> Es ist doch nur eine Zeile, oder?>>>> $ rustc bla.rs --target=???>>>> Nenne mir einfach den passenden String für ??? oder den gesamten>> rustc-Aufruf für das target attiny85 in Version 1.66.>> Niemand ruft rustc direkt auf. Auf keiner Plattform.> Deshalb kann ich dir auswendig den Aufruf auch nicht nennen.>> Alle Leute, inclusive des Beispiels (!) nutzen Cargo mit einem> entsprechenden json (bei AVR) zur Konfiguration des Targets.>> Was Cargo daraus für rustc macht, weiß ich nicht.
Aaaach soo ;-)
Wilhelm M. schrieb:>> Was Cargo daraus für rustc macht, weiß ich nicht.>> Aaaach soo ;-)
Ja. Jetzt hast du die 5% gefunden, die cppbert meint.
Glückwunsch.
Am der ursprünglichen Tatsache der unterstützten Chips ändert das aber
rein gar nichts.
Und wenn du dir das Beispiel endlich einmal anschauen und ausprobieren
würdest, dann könntest du selbst ganz einfach herausfinden, wie der
rustc-Aufruf ist.
Aber das willst du ja gar nicht.
MaWin O. schrieb:> Aber das willst du ja gar nicht.
ich glaube er will schon, aber ist es eben anders gewohnt - manche
machen in einem neuen System erstmal genau das was sie kennen und wenn
es dann nicht klappt steigt die Verwirrung - ist eben so, aber auch
nicht wirklich schlimm
cppbert schrieb:> ist eben so, aber auch nicht wirklich schlimm
Es ist schlimm, weil hier zum X-ten Male mit Links vorgekaut wurde, wie
es richtig geht.
Das ist einfach nur unverschämt den Forenteilnehmern gegenüber.
Bei einem simplen Makefile wüsste man sofort, was da abgeht. Aber die
für rust zu schreiben, ist zwar möglich, aber halt leider nicht mehr so
einfach / praktikabel. Aber wer will schon wissen, wie das zeug
funktioniert? Ist ja jetzt so viel einfacher, wo cargo alles für einen
macht, irgendwie...
DPA schrieb:> Bei einem simplen Makefile wüsste man sofort, was da abgeht.
Was ist bei dem Cargo.toml und dem json aus dem Beispiel-Template nicht
einfach zu verstehen?
Werde doch einmal konkret, bitte. Was wäre in einem Makefile besser zu
sehen und zu verstehen?
> ist ja jetzt so viel einfacher, wo cargo alles für einen> macht, irgendwie...
Ja, es ist viel einfacher.
Aber warum benutzt du make? Mit deiner Argumentation solltest du den gcc
selbst per Hand aufrufen und kein böses Buildsystem (wie make) nutzen.
Das make verkompliziert nur den simplen gcc-Aufruf! Regeln, Rezepte,
Variablen, Abhängigkeiten. Alles das braucht man gar nicht, wenn man gcc
direkt aufruft! Wozu also dieses komplizierte make-System?
DPA schrieb:> Bei einem simplen Makefile wüsste man sofort
aber auch nur die welche häufig mit Makefiles arbeiten und Makefiles
sind echt nicht so schön wenn es grosse Multi-Platform-Projekte mit
vielen Dependencies usw sind - das wissen alle aus langer Erfahrung :)
ein bisschen (drastischer) Umstellen darf erlaubt sein sonst kann man ja
gar nichts machen
MaWin O. schrieb:> DPA schrieb:>> Bei einem simplen Makefile wüsste man sofort, was da abgeht.>> Was ist bei dem Cargo.toml und dem json aus dem Beispiel-Template nicht> einfach zu verstehen?
Du hast selbst gesagt, du weisst nicht, wie der rustc Aufruf bei dem
ding oben am Schluss aussieht. In einem Makefile steht ziemlich genau
das drin. Zum bauen von X, führe Y aus. Das ist viel transparenter.
Daniel A. schrieb:> In einem Makefile steht ziemlich genau> das drin. Zum bauen von X, führe Y aus. Das ist viel transparenter.
das weiß jeder hier - auch MaWin - Cargo ist eben ein wenig anders als
make - mehr kann man da nicht diskutieren
cppbert schrieb:> aber auch nur die welche häufig mit Makefiles arbeiten und Makefiles> sind echt nicht so schön wenn es grosse Multi-Platform-Projekte mit> vielen Dependencies usw sind - das wissen alle aus langer Erfahrung :)>> ein bisschen (drastischer) Umstellen darf erlaubt sein sonst kann man ja> gar nichts machen
Genau so sieht es nämlich aus.
In Makefiles ist so gut wie nichts standardisiert.
Wo man da das Target umstellt, hat sich jeder Entwickler selbst
ausgedacht und selbst neu erfunden.
Bei Cargo ist das alles immer gleich.
Cargo-Projekte können zwar auch komplex werden. Wenn man z.B. ein
build.rs verwendet. Aber selbst dann ist es einfacher als make, weil die
Stellen wo man anfangen muss zu schauen immer gleich sind.
Bei Makefiles hat sich das hingegen jeder Entwickler neu ausgedacht.
Daniel A. schrieb:> Du hast selbst gesagt, du weisst nicht, wie der rustc Aufruf bei dem> ding oben am Schluss aussieht.
Weil ich es nicht brauche.
Weil so gut wie niemand es braucht. Auch du nicht.
Und genau deshalb schaue ich es auch nicht nach. Das ist nutzloses
Wissen.
> In einem Makefile steht ziemlich genau> das drin. Zum bauen von X, führe Y aus. Das ist viel transparenter.
Ich glaube du hast noch nie ein Makefile aus der realen Welt gesehen.
Ich habe sogar Projekte, die eigentlich nur ein grosses Makefile sind.
z.B. https://github.com/Daniel-Abrecht/dpa-image-builder
Ok, es gibt noch Sachen die Makefiles generieren, z.B. Automake, und
dass will man dann wirklich nicht unbedingt lesen. Aber ein normales,
simples, handgeschriebenes Makefile, ist wie ein wundervolles Kunstwerk.
Maximale Einfachheit und Transparenz, ohne Einschränkungen. Das
platonische Ideal der eines Build Tools!
MaWin O. schrieb:> cppbert schrieb:>> ist eben so, aber auch nicht wirklich schlimm>> Es ist schlimm, weil hier zum X-ten Male mit Links vorgekaut wurde, wie> es richtig geht.>> Das ist einfach nur unverschämt den Forenteilnehmern gegenüber.
Es ging sehr konkret um diese Frage:
Beitrag "Re: Rust - ist das hier um zu bleiben?"
Und Deine Antwort darauf:
MaWin O. schrieb:> Wilhelm M. schrieb:>> $ rustc --print target-list | grep avr>> Ja, Wilhelm. Das heißt nicht, dass nur der 328er unterstützt wird.
Es nicht um cargo mit einer geeigneten target-definition, wie Du siehst.
Sondern es ging um rustc und die damit ausgelieferte target-definition
ausschließlich für den m328.
Und dann noch diese Deine Antwort:
MaWin O. schrieb:> Wilhelm M. schrieb:>> Und welche werden bei dem Target avr-unknown-gnu-atmega328>> unterstützt???>> Soweit ich weiß alle. Die unterscheiden sich ja kaum auf CPU-Ebene.> Es kommt eher darauf an, was das von dir verwendete PAC unterstützt. Und> da habe ich den Link oben geliefert.
Und das ist eben irreführend bzw. falsch.
Wilhelm M. schrieb:> Es nicht um cargo mit einer geeigneten target-definition, wie Du siehst.
Ja. Dann machst du es halt falsch.
So einfach ist das.
Nutze Cargo, wie jeder vernünftige Mensch, oder finde halt selbst raus,
wie der rustc-Aufruf sein muss.
Ich kann es dir nicht sagen und es spielt auch überhaupt keine Rolle,
wie der rustc-Aufruf genau aussieht.
Ich werde das jetzt nicht für dich recherchieren, weil es sinnlos ist.
Hier ist die bereits gepostete Doku, die du bestimmt wieder nicht lesen
wirst:
https://book.avr-rust.com/005.1-the-target-specification-json-file.html
Wilhelm M. schrieb:>> Soweit ich weiß alle. Die unterscheiden sich ja kaum auf CPU-Ebene.>> Es kommt eher darauf an, was das von dir verwendete PAC unterstützt. Und>> da habe ich den Link oben geliefert.>> Und das ist eben irreführend bzw. falsch.
Was ist daran falsch?
MaWin O. schrieb:> Wilhelm M. schrieb:>>> Soweit ich weiß alle.>>>> Und das ist eben irreführend bzw. falsch.>> Was ist daran falsch?
Habe ich Dir oben doch schon erklärt: der Core der AVRs ist
unterschiedlich. Daher passt das m328 target nicht auf einen anderen µC
z.B. tiny oder DA, DB, DD.
MaWin O. schrieb:> Ja. Dann machst du es halt falsch.
Nö.
Die richtige Antwort wäre gewesen, die korrekte Target-Definition für
rustc zu erzeugen. Aber Du kennst Dich eben mit rustc nicht aus ...
Wilhelm M. schrieb:> Habe ich Dir oben doch schon erklärt: der Core der AVRs ist> unterschiedlich. Daher passt das m328 target nicht auf einen anderen µC> z.B. tiny oder DA, DB, DD.
Ich habe auch nie behauptet, dass ein für m328 kompiliertes
Rust-Programm auf einem Tiny lauffähig wäre.
Lies doch bitte die Doku. Dort steht, wie man das Target angibt:
https://book.avr-rust.com/005.1-the-target-specification-json-file.html
Oder gucke dir das Tiny-Beispiel an.
Was falsch ist, ist lediglich deine Aussage, dass der Rustcompiler nur
das m328-Target unterstützt.
Wilhelm M. schrieb:> Aber Du kennst Dich eben mit rustc nicht aus ...
So wirds sein. Genau.
Danke für diese Erkenntnis.
Zum Glück hast du mir das als Rust-Experte einmal erklärt.
Es ist unfassbar, wie stur man sein kann, lieber Wilhelm.
MaWin O. schrieb:> Wilhelm M. schrieb:>> Habe ich Dir oben doch schon erklärt: der Core der AVRs ist>> unterschiedlich. Daher passt das m328 target nicht auf einen anderen µC>> z.B. tiny oder DA, DB, DD.>> Ich habe auch nie behauptet, dass ein für m328 kompiliertes> Rust-Programm auf einem Tiny lauffähig wäre.
Hier nochmal zum Nachlesen:
Wilhelm M. schrieb:> MaWin O. schrieb:>> Wilhelm M. schrieb:>>> Und welche werden bei dem Target avr-unknown-gnu-atmega328>>> unterstützt???>>>> Soweit ich weiß alle. Die unterscheiden sich ja kaum auf CPU-Ebene.>> Es kommt eher darauf an, was das von dir verwendete PAC unterstützt. Und>> da habe ich den Link oben geliefert.
Auf die Frage, welche AVRs beim dem Target m328 unterstützt werden, kam
also Deine Antwort: "Soweit ich weiß alle".
Dann solltest Du mal erklären, wie das gemeint war.
Wilhelm M. schrieb:> Auf die Frage, welche AVRs beim dem Target m328 unterstützt werden, kam> also Deine Antwort: "Soweit ich weiß alle".
Nein. Die Frage, welche AVRs das m328-Target unterstützt ist doch wohl
trivial: Es unterstützt den m328.
Ich dachte das wäre auch dir klar.
Ich hätte es nicht für möglich gehalten, dass du tatsächlich fragst,
welche Controller das m328-Target unterstützt. Aber so kann man sich
irren. Also noch einmal für dich: Ja, das m328-Target unterstützt nur
den m328-Controller. Wer hätte das gedacht.
Aber das spielt zum Glück alles gar keine Rolle, denn es ging die ganze
Zeit um den AVR-Rust-Compiler. Und dieser unterstützt nun eben auch mehr
Targets als nur den m328. Und zwar - soweit ich weiß - alle, weil die
sich eben kaum unterscheiden. Und weil das zu 99% eine LLVM-Sache ist.
Du hast behauptet, dass er nur das m328-Target und damit nur den
m328-Controller unterstützt. Und das ist eben ganz einfach falsch.
MaWin O. schrieb:> Aber das spielt zum Glück alles gar keine Rolle, denn es ging die ganze> Zeit um den AVR-Rust-Compiler. Und dieser unterstützt nun eben auch mehr> Targets als nur den m328. Und zwar - soweit ich weiß - alle, weil die> sich eben kaum unterscheiden. Und weil das zu 99% eine LLVM-Sache ist.
Dann die nä. Frage: das llvm-avr backend ist noch experimental, oder?
Ich bin nicht ganz up-to-date, aber das letzte mal, als ich
clang/clang++ für AVR ausprobiert habe ((vor)letztes Jahr?) kam da
jedenfalls grottenschlechter Code raus.
Wilhelm M. schrieb:> Dann die nä. Frage: das llvm-avr backend ist noch experimental, oder?
Auch diese Frage wurde bereits hier beantwortet:
AVR-Rust gibts im Nightly-Zweig.
> Ich bin nicht ganz up-to-date, aber das letzte mal, als ich> clang/clang++ für AVR ausprobiert habe ((vor)letztes Jahr?)
Probiere es doch zur Abwechslung einfach einmal aus.
> kam da jedenfalls grottenschlechter Code raus.
"Grottenschlecht" ist er nicht.
Aber ja, einige der AVR-spezifischen Optimierungen, die der avr-gcc im
backend macht, macht der llvm noch nicht.
MaWin O. schrieb:> Aber ja, einige der AVR-spezifischen Optimierungen, die der avr-gcc im> backend macht, macht der llvm noch nicht.
Viele davon sind bei Rust aber auch gar nicht nötig.
Es gibt z.B. keine int-Promotion in Rust. Ein u8 ist ein u8. Da braucht
das Backend gar nichts zu optimieren, weil Rust ein u8 nicht auf i16
promoviert, wie C das auf AVR tut.
Deshalb kann es auch keine dem entsprechenden unnötigen Instruktionen
geben, die dann wieder umständlich im Backend herausoptimiert werden
müssen.
MaWin O. schrieb:> Auch diese Frage wurde bereits hier beantwortet:> AVR-Rust gibts im Nightly-Zweig.
Du hast mich nicht verstanden.
Zur Info: mein rustc version 1.66 unterstützt avr (aber eben nur den
m328, wie wir eben festgestellt haben, einfach mangels
target-definition).
rustc basiert auf llvm mit dem llvm-avr backend, und das ist
experimentell immer noch, soweit ich weiß.
Wilhelm M. schrieb:> Zur Info: mein rustc version 1.66 unterstützt avr (aber eben nur den> m328, wie wir eben festgestellt haben
Du hast es echt immer noch nicht verstanden?
Dein rustc unterstützt auch andere Targets!
> rustc basiert auf llvm mit dem llvm-avr backend, und das ist> experimentell immer noch, soweit ich weiß.MaWin O. schrieb:> Auch diese Frage wurde bereits hier beantwortet:> AVR-Rust gibts im Nightly-Zweig.
MaWin O. schrieb:> Wilhelm M. schrieb:>> Zur Info: mein rustc version 1.66 unterstützt avr (aber eben nur den>> m328, wie wir eben festgestellt haben>> Du hast es echt immer noch nicht verstanden?> Dein rustc unterstützt auch andere Targets!
Aber sicher habe ich Dich verstanden ;-)
Der rustc unterstützt nur dann andere Targets, wenn man ihm andere
target-definitionen gibt. Aber andere als für den m328 sind in Version
1.66 einfach nicht dabei. Das ist dieselbe Mechanik, wie beim avr-gcc
auch.
Wilhelm M. schrieb:> Der rustc unterstützt nur dann andere Targets, wenn man ihm andere> target-definitionen gibt. Aber andere als für den m328 sind in Version> 1.66 einfach nicht dabei.
Das ist doch grob irreführender Quatsch.
Du musst in der json-Datei deine CPU eintragen. Fertig. Das wars. Mehr
ist nicht zu tun.
Das ist es, worüber so hier einen riesigen Aufriss machst.
Du machst dich hier absolut lächerlich.
MaWin O. schrieb:> Wilhelm M. schrieb:>> Der rustc unterstützt nur dann andere Targets, wenn man ihm andere>> target-definitionen gibt. Aber andere als für den m328 sind in Version>> 1.66 einfach nicht dabei.>> Das ist doch grob irreführender Quatsch.
Nö.
$ rustc --print target-list | grep avr
avr-unknown-gnu-atmega328
Wilhelm M. schrieb:> $ rustc --print target-list | grep avr> avr-unknown-gnu-atmega328
du bekommst das nicht als target - egal wie oft du das forderst - es
wird über das Json eingestellt und niemals mit --print target-list
kommen, das steht doch in der Doku
btw: ist das alles eh nur in Nighlty und ich glaube du arbeitest mit
Release
cppbert schrieb:> btw: ist das alles eh nur in Nighlty und ich glaube du arbeitest mit> Release
Ja, auch das habe ich ganz oben schon gesagt: Version 1.66
Wilhelm M. schrieb:> Doch, ein Target für avr gibt es eben in Version 1.66
Wenn du es einmal ausprobiert hättest, hättest du auch gemerkt, dass es
mit stable nicht funktioniert und du nightly brauchst, wie hier schon
etliche Male gesagt.
Aber du bis ja vollkommen beratungsresistent.
hier steht das alles drin:
https://book.avr-rust.com/001-introduction.html
das man Nightly braucht (und nicht Stable), wie man ein
nicht-unknown-gnu-atmega328 supported (mit json)
was man alles installieren muss und kleine Beispiele
ich würde das auch gerne kurz Durchspielen aber will jetzt nicht
unbedingt ohne not (hab kein AVR auf dem Tisch) die gcc-avr Sachen auf
meinem Windows installieren
Links (nicht Rechts) schrieb:> Auch wenn wir das Jahr 2022 schreiben. Das klingt nicht gerade nach> KISS.
gut das AVR Zeug ist definitiv noch nicht Super-Mainstream und OOM
bekomme ich auch mit Qt 6.4 wenn ich alles mit gcc und allen Kernen baue
in einer VM mit 8GB RAM
Links (nicht Rechts) schrieb:> Auch wenn wir das Jahr 2022 schreiben. Das klingt nicht gerade nach> KISS.
Wann hast du das letzte Mal ein C++-Programm mit dem GCC auf einem
Mehrkernrechner compiliert? 10 GB sind auch dafür zu wenig.
Cargo nutzt standardmäßig alle Kerne, die zur Verfügung stehen.
MaWin O. schrieb:> Wilhelm M. schrieb:>> Der rustc unterstützt nur dann andere Targets, wenn man ihm andere>> target-definitionen gibt. Aber andere als für den m328 sind in Version>> 1.66 einfach nicht dabei.>> Das ist doch grob irreführender Quatsch.> Du musst in der json-Datei deine CPU eintragen. Fertig. Das wars. Mehr> ist nicht zu tun.> Das ist es, worüber so hier einen riesigen Aufriss machst.>> Du machst dich hier absolut lächerlich.
Hier ist er wieder, der MaWin, der nicht ohne persönliche Angriffe
auskommt.
Dabei hätte es genügt einfach sachlich zu bleiben.
MaWin O. schrieb:> Wann hast du das letzte Mal ein C++-Programm mit dem GCC auf einem> Mehrkernrechner compiliert?
C++ finde ich auch reichlich überfrachtet und ich würde bei C++ auch
nicht an KISS denken. Aber AVRs programmiert man auch eher in C oder
Forth. Mir ist dabei schon klar, dass Rust nicht hpts. für AVRs
entwickelt wurde.
Links (nicht Rechts) schrieb:> Mir ist dabei schon klar, dass Rust nicht hpts. für AVRs> entwickelt wurde.
Das ist Unsinn.
Was hat das mit dem Speicher zu tun, den du auf der Buildmaschine zur
Verfügung haben musst?
In den letzten Beiträgen ging es u.a. um die Programmierung von einem
ATtiny85 mit 8K Flash und wenn man einen PC mit mehr als 10 GB RAM
braucht, um den zu programmieren, ist das sprichwörtlich "mit Kanonen
auf Spatzen schießen".
Links (nicht Rechts) schrieb:> In den letzten Beiträgen ging es u.a. um die Programmierung von einem> ATtiny85 mit 8K Flash und wenn man einen PC mit mehr als 10 GB RAM> braucht, um den zu programmieren, ist das sprichwörtlich "mit Kanonen> auf Spatzen schießen".
Das kommt halt ganz auf dein Programm an, was du schreibst.
Genau, wie es bei C++ ist.
Wenn du hunderte Sources nutzt/schreibst, dann wollen die eben auch
compiliert werden.
Das hat gar nichts mit AVR zu tun.
MaWin O. schrieb:> Nano schrieb:>> Dabei hätte es genügt einfach sachlich zu bleiben.>> Einem Troll gegenüber sachlich bleiben?> Nein, danke.
Wilhelm M. war im Gegensatz zu dir sachlich. Sein Beitrag lässt nicht
darauf schließen, dass er ein Troll wäre.
Nano schrieb:> Wilhelm M. war im Gegensatz zu dir sachlich. Sein Beitrag lässt nicht> darauf schließen, dass er ein Troll wäre.
haha.
Genau.
Lustig.
Ein sachlicher Troll.
cppbert schrieb:> Bist du ein Clone von rbx, du schreibst auch irgendwie fast genau wie er> - so ein bisschen Fakten, bissel Emotionen, Somway Off-Topics aber> irgendwie related - wilde Mischung>> oder bin ich schon so alt das mir dieser Whatsapp/Tiktok> Kommunikationsstyle einfach nicht vertraut genug ist :)
Jetzt nicht, dass mich das nicht interessieren würde, oder dass ich mich
wegen dem Alter nicht geschmeichelt fühlen würde:)
Trotzdem: Was soll der Scheiss? Wenn dir Einer wegen der Form anstössig
abgeht und du komplett den Inhalt ignorierst ist das dein Ding.
Versteh ich aber. Das ist die Oberflächlichkeit womit der "kennste ...
kennste?" ganze Stadien füllt.
Whatsapp/Tiktok: Absolute Jungfrau in dieser Beziehung, also laber
keinen Flatterschiss und lassen wir den off-topic Quatsch.
Ich habe einen Aspekt von Rust untermauert und einen Grund, wieso es
"hier bleibt" mit Beispielen untermauert.
rbx kenn ich übrigens genau so wenig wie dich Frechdachs:)
P.S.: Meine merkwürdigen Meta-Scherze und schlechte Witze muss ja
niemand verstehen oder lieben. Einfach die Fassung bewahren und nicht
zuschlagen. Man kann es durchaus überleben.
P.S.S.: Wenn ich mal MaWin "zu jubel", weil ich der gleichen Meinung bin
dann näss dich bitte nicht gleich ein. Das passt ja kaum zu deinem doch
so hohen Alter, also von der geistigen Reife. Von der biologischen
schon, hmm... (Muss ich dazu schreiben dass das ein Scherz war und nicht
ernst gemeint?:P)
MaWin O. schrieb:> Das kommt halt ganz auf dein Programm an, was du schreibst.
Und es kommt bei dem Unterton der Diskussion da oben ja wohl auch darauf
an, WER das Programm schreibt.
Leute, Leute. Wer keine KANONEN zur Verfügung hat, der MUSS halt das
nehmen, was er zur Verfügung hat. Rumheulen und Träumen bringt da gar
nichts. Man nimmt halt ein Makefile oder gar gleich den Assembler (weil
derjenige es muss ... oder nicht anders kann?) anstatt MBED oder
Monstren wie PlatformIO, oder alle Cores doppelt mit
Link-Time-Optimization zu bemühen.
Refrain: Zwangsweise. Oder weil es nicht anders geht. Oder weil es
wirtschaftlicher ist. Oder weil wir das so schlank eingeplant haben?
Sucht euch was aus ... :P
Die oben genannten Anforderungen(10GB) sind ja wohl eher ein Scherz für
sogar 10 Jahre alte Entwicklungsarbeitsplätze (und natürlich Subjektiv,
eine Hausnummer).
Ich will jetzt auch nicht sagen, dass manche Lösung so einfach ist wie:
"cargo build --jobs 1", aber bitte bitte bitte: RTFM!
So einfach abtun sollte man das natürlich nicht.
"Compiler using over 20GiB memory #82406":
https://github.com/rust-lang/rust/issues/82406
Mit so hilfreichen Tips wie z.B.:
> lto = "off"
die nicht nur mir beim dieser LLVM-mässigen compilerverwahrlosenden
Speicherverschwendung als Aufruf zur Selbsthilfe in den Sinn kommen.
(Das war jetzt teilweise ernst gemeint!:O))
Ist ein Feature! Nich von mir, von LLVM:P
Jedzia D. schrieb:> die nicht nur mir beim dieser LLVM-mässigen compilerverwahrlosenden> Speicherverschwendung
bekommst du Geld zurück für jedes nicht verwendete Byte deines RAMs?
Wie bereits gesagt: Die Speicherlast ist keine Eigenschaft von Rust,
sondern eine Eigenschaft jedes modernen optimierenden Compilers. Also
offtopic.
Jedzia D. schrieb:> Wenn ich mal MaWin "zu jubel", weil ich der gleichen Meinung bin> dann näss dich bitte nicht gleich ein.
Ich finde das MaWin hier gute arbeit leistet - auch wenn er leider oft
gegen Windmühlen kämpfen muss
Jedzia D. schrieb:> Die oben genannten Anforderungen(10GB) sind ja wohl eher ein Scherz für> sogar 10 Jahre alte Entwicklungsarbeitsplätze (und natürlich Subjektiv,> eine Hausnummer).
blöderweise lässt sich so ein Text auf einer Homepage auch schnell mal
uminterpretieren in ein "Rust braucht immer mind 10GB RAM zum
kompilieren"
aber du hast ganz Recht, viele wissen gar nicht mehr wie viel so ein
kompilieren heute an Resourcen braucht, und die ganzen Defaults die Rust
mit rein bringt LTO etc. sind natürlich auch nicht ganz ohne - aber auch
gewollt
rustc ist immer noch (nur) der Referenz-Kompiler und nicht mehr, hier
geht es um die Sprache und diese erzwingt nicht per se übetriebene
Nutzung von Resourcen - wird sich alles in der Zukunft zeigen, mal
schauen wie sich da der gccrs schlagen wird
cppbert schrieb:> aber du hast ganz Recht, viele wissen gar nicht mehr wie viel so ein> kompilieren heute an Resourcen braucht
sorry, eher ein Parallel-Bauen mit vielen Kernen
cppbert schrieb:> und die ganzen Defaults die Rust> mit rein bringt LTO etc.
Cargo default ist lto=off
;)
Die 10 GB (oder mehr, je nach Programm) sind worst case, wenn man es
darauf anlegt.
> hier> geht es um die Sprache und diese erzwingt nicht per se übetriebene> Nutzung von Resourcen
Das ist grundsätzlich richtig.
Man kann auch Cargo so betreiben, dass es wenig(er) RAM braucht.
Vor allem lto=off und single-core-Betrieb werden hier massiv helfen.
Natürlich auf Kosten der Codequalität und Compilezeit.
Aber ich denke auch, dass Rust als Sprache ansich deutlich höhere
Anforderungen an die Hardware stellt, als z.B. C.
- Die ganzen statischen Prüfungen, die Rust verlangt, müssen vom
Compiler durchgeführt werden.
- Die Rust-Syntax ist nicht (wie C) auf einfachste Codegenerierung
ausgelegt. In den verschiedenen IRs der Rust-Compilierung kommen massive
Codemengen zusammen, die dann von den Optimierungsstufen
zusammengeschrumpft werden müssen. Das Vorhandensein dieser
Optimierungen ist eine Annahme, die man beim Sprachdesign getroffen hat.
Und das kostet Ressourcen bei der Compilierung.
Aber solange das sich im vernünftigen Rahmen der verfügbaren Hardware
bewegt, dann halte ich das für eine sehr gute Abwägung.
Es ist absolut vernünftig die Ressourcen, die zur Verfügung stehen, auch
zu nutzen, um in einer modernen Sprache gute Programme zu compilieren.
Wenn du nur 10% deines RAMs nutzt, verbessert das rein gar nichts.
Wenn du aber 50% deines RAMs nutzt um damit besseren Code zu generieren
oder eine bessere Sprache zu ermöglichen, dann verbessert das ganz
erheblich was.
Meine 2ct.
cppbert schrieb:> wird sich alles in der Zukunft zeigen, mal> schauen wie sich da der gccrs schlagen wird
Achja, und gccrs. Der wird im ersten Schritt noch keinen Borrow-Checker
haben. Alleine deshalb wird gccrs schon wahrscheinlich schlanker und
schneller sein.
Natürlich auf Kosten der Memory-Safety.
Es wird gerade ein neuer Borrow-Checker entwickelt, den man dann sowohl
in rustc als auch in gccrs gedenkt einzusetzen.
Der Vergleich zwischen rustc und gccrs wird aber immer spannend bleiben.
Daraus wird sich hoffentlich ein Rennen um den besten Compiler
entwickeln.
Links (nicht Rechts) schrieb:> In den letzten Beiträgen ging es u.a. um die Programmierung von einem> ATtiny85 mit 8K Flash und wenn man einen PC mit mehr als 10 GB RAM> braucht
Den PC mit mehr als 10 GB RAM brauchst du, um den Compiler zu
compilieren, nicht das bissel Programm für den ATtiny.
Das ist mit dem AVR-GCC sicher etwas weniger, mit dem AVR-Clang wird
sich das nicht so grundlegend unterscheiden.
Ich habe hier u.a. ein altes MacBook und ein Linux Notebook mit 4GB RAM.
Darauf habe ich bisher alles kompilieren können, Embedded-Projekte
ohnehin, aber auch GUI Anwendungen. Dass grosse Projekte auf diesen
alten Kisten Probleme machen, will ich aber natürlich nicht
ausschliessen.
Was eher auf alten Rechnern mit vergleichsweise kleinen Festplatten/SSDs
problematisch sein kann, ist die Grösse des target-Ordners. Da können
schnell einige GB zusammenkommen.
Oliver R. schrieb:> Ich habe hier u.a. ein altes MacBook und ein Linux Notebook mit 4GB RAM.> Darauf habe ich bisher alles kompilieren können, Embedded-Projekte> ohnehin, aber auch GUI Anwendungen.
Aha. Ich habe hier einen Raspberry Pi mit 4GB und darauf kompiliere ich
regelmäßig alle meine Rust-Programme. Gar kein Problem.
Vielleicht wird es aber auch mal Zeit diese historischen MacBooks und
Linux-Notebooks über Bord zu werden, oder halt darauf Software aus der
damaligen Zeit zu betreiben.
Auf einem Commodore 64 konnte man auch kein Windows 95 installieren.
Der zeitliche Abstand dürfte in etwa der gleiche sein.
Oliver R. schrieb:> Was eher auf alten Rechnern mit vergleichsweise kleinen Festplatten/SSDs> problematisch sein kann, ist die Grösse des target-Ordners. Da können> schnell einige GB zusammenkommen.
Naja. Geht so.
1
$ du -sh target/
2
1.8G target/
3
du -sh .embuild/
4
1.3G .embuild/
Das ist jetzt eines meiner Embedded-Projekte für ESP32.
Das sollte auch auf einem Rechner der ersten SSD-Generationen passen,
wenn man das denn will.
Beim target-Ordner sollte man halt wissen, dass die Builds darin
versioniert sind. Wenn also z.B. Features geändert oder die Toolchain
aktualisiert wird, dann wird ein komplett neuer Build angelegt.
Das auch durchaus positiv zu sehen, weil dann schnell zwischen
verschiedenen Versionen hin- und hergeschaltet werden kann ohne alles
neu kompilieren zu müssen.
Wenn man also nicht gelegentlich mal ein "cargo clean" macht, kann der
Ordner entsprechend anwachsen.
Wilhelm M. schrieb:> cppbert schrieb:>> du bekommst das nicht als target>> Doch, ein Target für avr gibt es eben in Version 1.66
Die angezeigte Target-Liste zeigt alle bekannten Targets, aber nicht die
unterstützten.
1
rustup target add avr-unknown-gnu-atmega328
beendet mit einem Fehler (rustc stable), da braucht's wohl die nightly
als Basis.
"avr-unknown-gnu-atmega328" ist offensichtlich ein Misnomer; das Target
sollte einfach avr-unknown-gnu oder avr-unknown-none heißen. Tut es
aber nicht; vermutlich hatten die Entwickler noch nen ATmega238 irgendwo
rumfliegen...
rustc basiert ja auf llvm, d.h. es ist llvm + Rust-Frontend. llvm /
clang wiederum übernehmen viele Optionen von [avr-]gcc wie -o, -O*,
-mmcu= etc.
Für ein Frontend wie Rust ist es erst mal egal, ob eine Architektur MUL
oder DIV unterstützt oder nicht. Es erzeugt Zwischencode für MUL und
DIV etc., der dann irgendwann zu Assembly gelowert wird -- und dann muss
man natürlich wissen, ob MUL oder Lib-Call, wie teuer MUL ist etc. Und
dieses Lowering erfolgt eben nicht im (Rust-)Frontend. Das einzige, was
Rust wissen müsste, ist wie man mit Inline Assembly umgeht, ganz konkret
mit Constraints, die ja Target-abhängig sind.
Teile der GNU-Tools wie AVR-LibC sind in mehreren Einzelteilen (Crates)
verfügbar, die lax in etwa Libraries entsprechen. Es gibt nen Crate für
avr-libc Funktionen, nen Crate für SFR-Definitionen (avrd), nen Crate
für PROGMEM, nen Crate für ... you name it.
Für jedes Puzzleteil muss man wissen, ob man es braucht oder nicht und
in welcher Version, die man dann im .toml einträgt.
Momentan scheint's da nen ziemlichen Wildwuchs zu geben, auf crate.io
nach "avr" zu suchen bringt mehrere Seiten von Crates, wobei da auch
andere Bedeutungen von "AVR" bei sind.
Ein "offiziellen" AVR Support wie realisiert durch AVR-LibC scheint's
nicht zu geben, wie gesagt muss man alles zusammensuchen. Und weil llvm
nichts wie GCC's Spec-Files unterstützt, muss jede Kleineigkeit an
Target-Optionen im Compiler selbst realsiert sein, so wie es bei avr-gcc
bis v4.9 der Fall war.
zu
"Aber es gibt natürlich auch Fehler, die durch keine Programmiersprache
der Welt verhindert werden."
das ist den Rust-Designern und den Anwendern klar - nur damit hier
niemand Zeit damit verschwenden muss ein
also-doch-nicht-100%-Sicher-Kommentar einzustreuen :)
cppbert schrieb:> das ist den Rust-Designern und den Anwendern klar - nur damit hier> niemand Zeit damit verschwenden muss ein> also-doch-nicht-100%-Sicher-Kommentar einzustreuen :)
Das ist den Rust-Entwicklern sehr klar
https://blog.rust-lang.org/2023/01/10/cve-2022-46176.html
Vor Logikfehlern kann eine Sprache nur in einem gewissen Rahmen
schützen.
Aber auch da ist Rust besser als typunsichere Sprachen, weil sich solche
Logikzusammenhänge oft als Typzusammenhänge formulieren lassen. Somit
haben Bibliotheksentwickler die Möglichkeit eine Falschverwendung der
APIs zu beschränken.
Cppbert schrieb:> Cppbert schrieb:>> Mehr Rust in Chrome>> Laut Wikipedia hat das Chromium Projekt ca. 35 Mio Zeilen code, mit> einem großen Anteil C++
"This will enable us to include Rust code in the Chrome binary within
the next year."
Das sind ja offenbar überhaupt erstmal die Voraussetzungen, dort Rust zu
benutzen. Da ist es ja irgendwie logisch, dass das aktuell noch gar
nicht dabei ist.
Lothar schrieb:> Rust bietet zumindest (noch) keine Lösung für das kritischste Embedded> C/C++ Problem:
Wobei "embedded" natürlich eine gaaanz breite Palette ist.
Auch da gibt es Hardware, die memory protection kann. Wenn die Hardware
das aber nicht kann, wäre der Preis, dass die Software vor jeder
Stackoperation selbst erstmal gucken müsste, ob da jetzt eine Kollision
entstehen kann. Gerade auf den Plattformen, die keine hardware memory
protection haben (weil sie so klein sind) will man diesen Preis ohnehin
eher nicht bezahlen.
Jörg W. schrieb:> Auch da gibt es Hardware, die memory protection kann.
Auch eine MPU nützt wenig, wenn der Stack nach unten wächst. Da müsste
dann wohl eine leere Readonly Page zwischen Heap und Stack.
> Gerade auf den Plattformen, die keine hardware memory> protection haben (weil sie so klein sind) will man diesen Preis ohnehin> eher nicht bezahlen.
Zunächst Mal wäre der Aufwand für einen Compiler doch gar nicht so
gross, den Platzbedarf für Register, Rücksprungadresse, lokale Variablen
beim Funktionsaufruf zu berechnen. Und dann automatisch vor
Funktionsaufruf eine Prüfung des Stackpointer zu erzeugen. Das ist eine
Subtraktion und ein Compare, kein Aufwand.
Bei rekursiven Funktionen in C zähle ich immer die Tiefe manuell mit,
nur so kann nichts daneben gehe.
Und bei "kleinen Platformen" wie z.B. dem 8051 läuft der Stack nach
oben, da braucht es keine MPU, einfach nur Prüfung 0xFF - SP >
Platzbedarf. Interrupt Handler müssen gar nicht geprüft werden, da
Registerbänke.
Announcing Rust 1.67.0
https://blog.rust-lang.org/2023/01/26/Rust-1.67.0.html
Dieses Mal mehr unsichtbare Arbeiten unter der Haube.
Aber auch wichtige Dinge wie die Beschleunigung von einer Variante der
Inter-Thread-Communikation. (Was nicht heißt, dass diese vorher langsam
war).
Lothar schrieb:> Rust bietet zumindest (noch) keine Lösung für das kritischste Embedded> C/C++ Problem:
Warum sollte Stack-overflow das kritischste Embedded-Problem sein?
Gibt es da auch Belege für?
Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.
Wichtige Regeln - erst lesen, dann posten!
Groß- und Kleinschreibung verwenden
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang
Announcement: there is an English version of this forum on 
Thread beobachten
Seitenaufteilung abschalten