Forum: PC-Programmierung Rust - ist das hier um zu bleiben?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von cppbert (Gast)


Lesenswert?

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

von rbx (Gast)


Lesenswert?

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?

von cppbert (Gast)


Lesenswert?

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?

von MaWin (Gast)


Lesenswert?

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.

von rbx (Gast)


Lesenswert?

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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Cppbert (Gast)


Lesenswert?

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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Ich denke, dass das seit der Übernahme durch Oracle praktisch nur noch 
für Datenbankserver genutzt wird.

von cppbert (Gast)


Lesenswert?

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 :)

von rbx (Gast)


Lesenswert?

ich habe mal testweise rustc in die Fedora33 Konsole eingegeben.
Ergebnis:
1
[rbx@fe1 ~]$ rustc
2
Usage: rustc [OPTIONS] INPUT
3
4
Options:
5
    -h, --help          Display this message
6
        --cfg SPEC      Configure the compilation environment
7
    -L [KIND=]PATH      Add a directory to the library search path. The
8
                        optional KIND can be one of dependency, crate, native,
9
                        framework, or all (the default).
10
    -l [KIND[:MODIFIERS]=]NAME[:RENAME]
11
                        Link the generated crate(s) to the specified native
12
                        library NAME. The optional KIND can be one of
13
                        static, framework, or dylib (the default).
14
                        Optional comma separated MODIFIERS
15
                        (bundle|verbatim|whole-archive|as-needed)
16
                        may be specified each with a prefix of either '+' to
17
                        enable or '-' to disable.
18
        --crate-type [bin|lib|rlib|dylib|cdylib|staticlib|proc-macro]
19
                        Comma separated list of types of crates
20
                        for the compiler to emit
21
        --crate-name NAME
22
                        Specify the name of the crate being built
23
        --edition 2015|2018|2021
24
                        Specify which edition of the compiler to use when
25
                        compiling code.
26
        --emit [asm|llvm-bc|llvm-ir|obj|metadata|link|dep-info|mir]
27
                        Comma separated list of types of output for the
28
                        compiler to emit
29
        --print [crate-name|file-names|sysroot|target-libdir|cfg|target-list|target-cpus|target-features|relocation-models|code-models|tls-models|target-spec-json|native-static-libs]
30
                        Compiler information to print on stdout
31
    -g                  Equivalent to -C debuginfo=2
32
    -O                  Equivalent to -C opt-level=2
33
    -o FILENAME         Write output to <filename>
34
        --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 ;)

von Cppbert (Gast)


Lesenswert?

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

von MaWin O. (mawin_original)


Lesenswert?

Alter, krass.
Geh mal zu einem Arzt, rbx.

Da stimmt doch was nicht. Oder du trollst. Und zwar schlecht.

von rbx (Gast)


Lesenswert?

Cppbert schrieb:
> warum postest du die ganze rustc
> Ausgabe?

Weil ich so darüber lachen musste.

von cppbert (Gast)


Lesenswert?

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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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. ;-)

: Bearbeitet durch Moderator
von Cppbert (Gast)


Lesenswert?

Jörg W. schrieb:
> Ist aber wohl auch mit Abstand der unwesentlichste Punkt überhaupt

Der Satz hat dich gerettet :)

von rbx (Gast)


Lesenswert?

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..

von Cppbert (Gast)


Lesenswert?

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?

von Wilhelm M. (wimalopaan)


Lesenswert?

rbx schrieb:
> naja, so grob: Rust ist eine Programmiersprache ohne Compiler/Linker -
> ist eigentlich auch neu.

Was möchtest Du uns damit sagen?

von MaWin O. (mawin_original)


Lesenswert?

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".

von Jedzia D. (Firma: Rast und Ruh) (jedzia)


Lesenswert?

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

von Jedzia D. (Firma: Rast und Ruh) (jedzia)


Lesenswert?

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 .... :)

von Jedzia D. (Firma: Rast und Ruh) (jedzia)


Lesenswert?

Na ja. Manche Pakete sind halt auch einfach FERTIG!

... das Konzept mag dem ein oder anderen hier nicht geläufig sein.
Lasst es mich erklären: Das ist dann, wenn die Arbeit gut ist ... und 
abgeschlossen ist!:)))

(Ist natürlich ne Lüge, wie nachfolgende Beispiele und Argumente belegen 
werden ... von Api's echt jetze???)

https://crates.io/crates/wasi/0.11.0+wasi-snapshot-preview1
https://crates.io/crates/cfg-if/1.0.0
https://crates.io/crates/getrandom/0.2.8 shit ... die "data-science" 
schläft nicht, hehehee;)

von cppbert (Gast)


Lesenswert?

@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 :)

von cppbert (Gast)


Lesenswert?

https://blog.yoshuawuyts.com/rust-2023/

netter Vergleich aus dem Post
1
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.

von MaWin O. (mawin_original)


Lesenswert?

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.

von DPA (Gast)


Lesenswert?

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.

von cppbert (Gast)


Lesenswert?

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 :)

von cppbert (Gast)


Lesenswert?

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

von MaWin O. (mawin_original)


Lesenswert?

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

von c-hater (Gast)


Lesenswert?

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.

von MaWin O. (mawin_original)


Lesenswert?

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.

von Cppbert (Gast)


Lesenswert?

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

von Cppbert (Gast)


Lesenswert?

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 :)

von MaWin O. (mawin_original)


Lesenswert?

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.

von DPA (Gast)


Lesenswert?

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.

von MaWin O. (mawin_original)


Lesenswert?

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.

von Siggi A. (Gast)


Lesenswert?

Von
https://opensrcsec.com/open_source_security_announces_rust_gcc_funding
bis
https://gcc.gnu.org/pipermail/gcc-patches/2022-December/607959.html
hat es doch etwas gedauert..

Was fehlt jetzt noch um meinen geliebten attiny85 mit gccrs zu 
programmieren?

Wie lange muss man noch auf GCC v14 warten?

von MaWin O. (mawin_original)


Lesenswert?

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.

von Wilhelm M. (wimalopaan)


Lesenswert?

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

von cppbert (Gast)


Lesenswert?


von cppbert (Gast)


Lesenswert?

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

von MaWin O. (mawin_original)


Lesenswert?

Wilhelm M. schrieb:
> Die Version 1.66 hat nur avr-unknown-gnu-atmega328

Das ist nicht wahr.

von Wilhelm M. (wimalopaan)


Lesenswert?

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)

von MaWin O. (mawin_original)


Lesenswert?

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 MaWin O. (mawin_original)


Lesenswert?

Wilhelm M. schrieb:
> $ rustc --print target-list | grep avr

Ja, Wilhelm. Das heißt nicht, dass nur der 328er unterstützt wird.

von MaWin O. (mawin_original)


Lesenswert?

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.

von Wilhelm M. (wimalopaan)


Lesenswert?

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???

von MaWin O. (mawin_original)


Lesenswert?

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.

von Wilhelm M. (wimalopaan)


Lesenswert?

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.

von MaWin O. (mawin_original)


Lesenswert?

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.

von Wilhelm M. (wimalopaan)


Lesenswert?

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.

von MaWin O. (mawin_original)


Lesenswert?

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

von Wilhelm M. (wimalopaan)


Lesenswert?

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.

Beitrag #7293720 wurde von einem Moderator gelöscht.
von cppbert (Gast)


Lesenswert?

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

von cppbert (Gast)


Lesenswert?

Wilhelm M. schrieb:
> Jetzt erklär mal bitte, wie der Code dann auf einem tiny laufen soll.

war doch in meinem ersten Beispiel Post

https://github.com/eric-wood/rust-attiny85-example/blob/main/avr-attiny85.json

vergleich die beiden jsons

von Wilhelm M. (wimalopaan)


Lesenswert?

cppbert schrieb:
> Wilhelm M. schrieb:
>> Jetzt erklär mal bitte, wie der Code dann auf einem tiny laufen soll.
>
> war doch in meinem ersten Beispiel Post
>
> https://github.com/eric-wood/rust-attiny85-example/blob/main/avr-attiny85.json
>
> vergleich die beiden jsons

Ja, schon klar.

Nur MaWin behauptete zum Target atmega328 folgendes:

MaWin O. schrieb:
> Soweit ich weiß alle.

Und das ist definitiv falsch.

von cppbert (Gast)


Lesenswert?

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?

von Wilhelm M. (wimalopaan)


Lesenswert?

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

von cppbert (Gast)


Lesenswert?

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

von cppbert (Gast)


Lesenswert?

Wilhelm M. schrieb:
> Das es nicht geht in Version 1.66, weiß ich ja bereits wie oben schon
> geschrieben:

ok, sorry das ging unter

von MaWin O. (mawin_original)


Lesenswert?

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.

von Wilhelm M. (wimalopaan)


Lesenswert?

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.

von MaWin O. (mawin_original)


Lesenswert?

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.

von Wilhelm M. (wimalopaan)


Lesenswert?

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.

von MaWin O. (mawin_original)


Lesenswert?

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.

von Wilhelm M. (wimalopaan)


Lesenswert?

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 ;-)

von MaWin O. (mawin_original)


Lesenswert?

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.

von cppbert (Gast)


Lesenswert?

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

von MaWin O. (mawin_original)


Lesenswert?

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.

von DPA (Gast)


Lesenswert?

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...

von MaWin O. (mawin_original)


Lesenswert?

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?

von cppbert (Gast)


Lesenswert?

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

von Daniel A. (daniel-a)


Lesenswert?

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.

von cppbert (Gast)


Lesenswert?


von cppbert (Gast)


Lesenswert?

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

von MaWin O. (mawin_original)


Lesenswert?

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.

von MaWin O. (mawin_original)


Lesenswert?

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.

von Daniel A. (daniel-a)


Lesenswert?

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!

von MaWin O. (mawin_original)


Lesenswert?

Daniel A. schrieb:
> Ich habe sogar Projekte, die eigentlich nur ein grosses Makefile sind.
> z.B. https://github.com/Daniel-Abrecht/dpa-image-builder

https://github.com/Daniel-Abrecht/dpa-image-builder/blob/master/makefile

Hm hm. Ja ja.
Sehr einfach zu lesen, dein Makefile.
Ich verstehe sofort, was es tut.

Dagegen ist ein Cargo.toml
https://github.com/avr-rust/template-bin/blob/master/Cargo.toml
und ein json
https://github.com/avr-rust/template-bin/blob/master/avr-atmega328p.json
ja geradezu Hexenwerk und schwer verständlich!

Bei Cargo kann man sogar in die Doku gucken und man bekommt alles sehr 
genau erklärt. Da lobe ich mir tatsächlich ein undokumentiertes 
Makefile. Da wird man noch gefordert!

von Wilhelm M. (wimalopaan)


Lesenswert?

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.

von MaWin O. (mawin_original)


Lesenswert?

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

von MaWin O. (mawin_original)


Lesenswert?

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?

von Wilhelm M. (wimalopaan)


Lesenswert?

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.

von Wilhelm M. (wimalopaan)


Lesenswert?

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 ...

von MaWin O. (mawin_original)


Lesenswert?

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.

von MaWin O. (mawin_original)


Lesenswert?

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.

von Wilhelm M. (wimalopaan)


Lesenswert?

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.

von MaWin O. (mawin_original)


Lesenswert?

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.

von Wilhelm M. (wimalopaan)


Lesenswert?

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.

von MaWin O. (mawin_original)


Lesenswert?

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.

von MaWin O. (mawin_original)


Lesenswert?

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.

von Wilhelm M. (wimalopaan)


Lesenswert?

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ß.

von MaWin O. (mawin_original)


Lesenswert?

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.

von Wilhelm M. (wimalopaan)


Lesenswert?

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.

: Bearbeitet durch User
von Links (nicht Rechts) (Gast)


Lesenswert?

Vielleicht erhellen diese Links die Sachlage etwas:

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

https://book.avr-rust.com/003.1-the-avr-unknown-gnu-atmega328-target.html

https://book.avr-rust.com/005.1-the-target-specification-json-file.html

Unten im letzten Link steht z.B.
"Adapting a target specification JSON to another AVR variant is trivial.

Options that must be updated to target individual microcontroller 
variants:

    cpu - set to the lower-case model name of the desired AVR variant
    pre-link-args - the correct -mmcu option, always equal to the cpu, 
must be updated"

von MaWin O. (mawin_original)


Lesenswert?

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.

von Wilhelm M. (wimalopaan)


Lesenswert?

Links (nicht Rechts) schrieb:
> Vielleicht erhellen diese Links die Sachlage etwas:

Ist bekannt: nicht anderes habe ich oben geschrieben

von Wilhelm M. (wimalopaan)


Lesenswert?

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

von cppbert (Gast)


Lesenswert?

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

von Wilhelm M. (wimalopaan)


Lesenswert?

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

von Wilhelm M. (wimalopaan)


Lesenswert?

cppbert schrieb:
> du bekommst das nicht als target

Doch, ein Target für avr gibt es eben in Version 1.66

von MaWin O. (mawin_original)


Lesenswert?

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.

von cppbert (Gast)


Lesenswert?

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

von Links (nicht Rechts) (Gast)


Lesenswert?

cppbert schrieb:
> hier steht das alles drin:
> https://book.avr-rust.com/001-introduction.html

Aus https://book.avr-rust.com/002-installing-the-compiler.html ganz 
unten

"NOTE: Compiling Rust/LLVM can be very memory intensive. You may find 
compilation abruptly stopping on machines with less than ~10GB of RAM 
due to the operating system out-of-memory killer stopping it."

Auch wenn wir das Jahr 2022 schreiben. Das klingt nicht gerade nach 
KISS.

von cppbert (Gast)


Lesenswert?

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

von MaWin O. (mawin_original)


Lesenswert?

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.

von Nano (Gast)


Lesenswert?

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.

von MaWin O. (mawin_original)


Lesenswert?

Nano schrieb:
> Dabei hätte es genügt einfach sachlich zu bleiben.

Einem Troll gegenüber sachlich bleiben?
Nein, danke.

von Links (nicht Rechts) (Gast)


Lesenswert?

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.

von MaWin O. (mawin_original)


Lesenswert?

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?

von Links (nicht Rechts) (Gast)


Lesenswert?

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".

von MaWin O. (mawin_original)


Lesenswert?

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.

von Nano (Gast)


Lesenswert?

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.

von MaWin O. (mawin_original)


Lesenswert?

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.

von Jedzia D. (Firma: Rast und Ruh) (jedzia)


Lesenswert?

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)

von Jedzia D. (Firma: Rast und Ruh) (jedzia)


Lesenswert?

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

von MaWin O. (mawin_original)


Lesenswert?

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.

von cppbert (Gast)


Lesenswert?

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

von cppbert (Gast)


Lesenswert?

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

von cppbert (Gast)


Lesenswert?

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

von MaWin O. (mawin_original)


Lesenswert?

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.

von MaWin O. (mawin_original)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Oliver R. (Gast)


Lesenswert?

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.

von MaWin O. (mawin_original)


Lesenswert?

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.

von Oliver R. (Gast)


Lesenswert?

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.

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

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.

: Bearbeitet durch User
von cppbert (Gast)


Lesenswert?

https://www.heise.de/hintergrund/Interview-Soenke-Huster-ueber-Luecken-im-WLAN-Stack-des-Linux-Kernels-7447684.html
1
ct: C gilt als relativ unsichere Programmiersprache. Künftig soll es möglich sein, Kernel-Komponenten stattdessen in Rust zu schreiben. Hätte das deine Sicherheitslücken verhindert?
2
3
Huster: Sehr wahrscheinlich wären diese Lücken nicht aufgetreten, hätte man die Module in Rust geschrieben. Gerade die Geschichte, dass man Speicher überschreiben kann. Der Rust-Compiler hätte verhindert, dass die Kernel-Entwickler diesen Fehler überhaupt einbauen. Aber es gibt natürlich auch Fehler, die durch keine Programmiersprache der Welt verhindert werden.

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 :)

von Kaj (Gast)


Lesenswert?

cppbert schrieb:
> "Aber es gibt natürlich auch Fehler, die durch keine Programmiersprache
> der Welt verhindert werden."
Das ist richtig. Dazu gehört zum Beispiel das überprüfen der Länge.
https://www.heise.de/news/Rust-bis-zu-2500-Projekte-durch-Bibliothek-Hyper-fuer-DoS-verwundbar-7451019.html
1
Allerdings ist es bei Hyper möglich, das Problem mit kleinen Paketen 
2
auszunutzen. Wenn die Funktion to_bytes mehr als einen Chunk an Daten 
3
erwartet, erzeugt sie einen Vektor, der der Länge des zu lesenden Bodys 
4
entspricht. Die Länge des Vektors bestimmt sich dabei über den Content-
5
Length-Header, dessen Wert Angreifer einfach so hoch setzen können, dass 
6
der Prozess beim Erzeugen des Vektors abstürzt. Da HTTP-Server oft Daten 
7
aus nicht vertrauenswürdigen Quellen empfangen, ist eine solche Attacke 
8
vorstellbar.
Auch die beste Sprache schützt nicht (immer) vor Schludrigkeit.

von cppbert (Gast)


Lesenswert?

Kaj schrieb:
> Auch die beste Sprache schützt nicht (immer) vor Schludrigkeit.

100% ACK

von MaWin (Gast)


Lesenswert?

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.

von Cppbert (Gast)


Lesenswert?


von Cppbert (Gast)


Lesenswert?

Cppbert schrieb:
> Mehr Rust in Chrome

Laut Wikipedia hat das Chromium Projekt ca. 35 Mio Zeilen code, mit 
einem großen Anteil C++

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Kaj (Gast)


Lesenswert?

Da fühlt sich jemand auf den Schlips getreten :D

Sichere Programmiersprachen: Bjarne Stroustrup reagiert auf 
NSA-Empfehlung
https://www.golem.de/news/sichere-programmiersprachen-bjarne-stroustrup-reagiert-auf-nsa-empfehlung-2301-171374.html

von Lothar (Gast)


Lesenswert?

Rust bietet zumindest (noch) keine Lösung für das kritischste Embedded 
C/C++ Problem:

Is rust guaranteed to detect stack overflows?

https://users.rust-lang.org/t/is-rust-guaranteed-to-detect-stack-overflows/52593/1

Rust code segfaults with stack overflow

https://github.com/rust-lang/rust/issues/79935

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Oliver R. (Gast)


Lesenswert?

Es gibt zumindest Ideen dazu.

https://github.com/knurling-rs/flip-link

von Lothar (Gast)


Lesenswert?

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.

von Cyblord -. (cyblord)


Lesenswert?

Kaj schrieb:
> Da fühlt sich jemand auf den Schlips getreten :D
>
> Sichere Programmiersprachen: Bjarne Stroustrup reagiert auf
> NSA-Empfehlung
> 
https://www.golem.de/news/sichere-programmiersprachen-bjarne-stroustrup-reagiert-auf-nsa-empfehlung-2301-171374.html

Ja sicher. Was weiß der Idiot schon.  Nur Rust Fanboys kennen die 
Wahrheit. In ihrem Leben zwar noch nie was geleistet, aber über einen 
der bedeutendsten Köpfe im Bereich Programmiersprachen herziehen.

: Bearbeitet durch User
von MaWin (Gast)


Lesenswert?

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?

Antwort schreiben

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

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.