Vielleicht habe ich nicht genug gesucht --- aber in der <stdlib.h> stehen ja "nur" Definitionen. Anders als z.B. in der <avr/pgmspace.h>, wo ich direkt den Assemblercode für Tabellenfunktionen finde, finde ich hier nichts. Wo steht denn nun der eigentliche Code für rand() u.a. --- bzw. wie werden die Zahlen ermittelt? Mittels schieben und EXOR?
(Meine Glaskugel meint, dass du von der avr-libc sprichst.) Nun ja, für manches brauchst du halt auch mal wirklich den Sourcecode der Bibliothek. Die Funktion steht dort in libc/stdlib/rand.c. Nein, das ist nicht irgendein simpler Hack, sondern ein LFSR (->gugel).
Sieht mir nicht nach LFSR aus, oder täusch ich mich da? Sieht eher wie Arithmetik im endlichen Körper Z mod (2^31-1)Z aus. Die 7^5 ist wohl ein zyklischer Erzeuger seiner Einheitengruppe.
Johann L. wrote: > Sieht mir nicht nach LFSR aus, oder täusch ich mich da? Wird zumindest irgendwo darüber behauptet. Allerdings bin ich kein Informatiker, ich kann auf Anhieb nicht einschätzen, was diese Implementierung nun genau darstellt. Den referenzierten ACM-Artikel habe ich hier: http://www.firstpr.com.au/dsp/rand31/p1192-park.pdf finden können, wen's interessiert.
ich bin irgendwie zu blöd zum Suchen ... wenn ich WinAVR installiere, wird ein gleichnamiger Ordner unter C: (o.a.) angelegt. Dort finde ich die math.c nicht. Wo ist sie??? Evtl. in eine Patch-Datei? Danke ....
math.c suchst du auch nicht, sondern rand.c, und die hat dir Johnann bereits gepostet. Nein, der Sourcecode der einzelnen Pakete wird bei WinAVR nicht automatisch mit installiert, den müsstest du dir schon im Netz selbst beschaffen. Andernfalls wäre das WinAVR-Paket wohl 3x so groß, wie es ohnehin schon ist...
Aber warum funktioniert dann bei mir die rand() Funktion tatellos? Irgendwo muss doch AVR-Studio die Datei hernehmen -- aus welchem Verzeichnis? Im Dissassambler sieht man auch entsprechende Assembler-Befehle.
Windows/Linux geht auch ohne Quelltext! es gibt eine Compilierte Version in der Lib, aber der Quelltext wird nicht gebraucht.
Woher nimmt denn dein Windoof die ganzen Funktionen zum Rumkritzeln auf dem Bildschirm? Liegen die etwa als Quelltext vor...? Genauso machts der GCC auch.
Jens wrote: > Aber warum funktioniert dann bei mir die rand() Funktion tatellos? > > Irgendwo muss doch AVR-Studio die Datei hernehmen -- aus welchem > Verzeichnis? > > Im Dissassambler sieht man auch entsprechende Assembler-Befehle. Alle diese Funktionen sind bereits vorkompiliert mit dem Paket mitgekommen, das du dir installiert hast. Sie liegen alle zusammen in einer Bibliothek, die beim endgültigen Erstellen des Programms zu deinem Maschinencode (der aus deinem Quellcode durch compilieren entstanden ist) hinzu-ge-linkt wird. Man nennt diese Bibliothek auch die Runtime-Library und sie wird standardmässig zu jedem C-Programm dazugelinkt.
Unsinn !!!! Tut mir leid, mit Windows und "irgendwo" ---- das ist alles Quatsch, kann nicht so sein. Sämtliche anderen Header Dateien, die ich verwende( inttypes.h, avr/io.h,<avr/interrupt.h>, <avr/pgmspace.h> erklären sich komplett von selbst: z.B.
1 | #define __LPM_enhanced__(addr) \
|
2 | (__extension__({ \
|
3 | uint16_t __addr16 = (uint16_t)(addr); \
|
4 | uint8_t __result; \
|
5 | __asm__ \
|
6 | ( \
|
7 | "lpm %0, Z" "\n\t" \
|
8 | : "=r" (__result) \
|
9 | : "z" (__addr16) \
|
10 | ); \
|
11 | __result; \
|
12 | }))
|
darunter irgendwann wird __LPM_enhanced__(addr) definiert
1 | #define __LPM(addr) __LPM_enhanced__(addr)
|
darunter dann entgültig die Zeile, die ich dann in mein Programm einsetze:
1 | #define pgm_read_byte_near(address_short) __LPM((uint16_t)(address_short))
|
ODER einfach auch sowas
1 | #define RXC1 7
|
2 | #define TXC1 6
|
3 | #define UDRE1 5
|
Ich schätze, das es zusammengefasste Dateien im WinAVR-Pfad sind. Leider finde ich auch keine hinweisenden includes in der <stdlib.h>. Ich schau aber noch mal nach
Jens wrote:
> Unsinn !
Gut. Wenn du's besser weißt, dann lass mich den Spruch des letzten
sächsischen Königs zitieren, als er abdanken musste: ,,Macht doch
eiern Dregg alleene!''
Na denn such mal schön weiter und glaub weiter deinen Blödsinn. Ich halt mich solange an die Funktion in /libc/stdlib/random.c.
Wartet nur, bis er merkt, dass er in den Header Dateien zwar defines findet, aber keine Funktionsrümpfe ;)
Simon K. wrote: > Wartet nur, bis er merkt, dass er in den Header Dateien zwar defines > findet, aber keine Funktionsrümpfe ;) Tja, Typdefinitionen, Makros und Deklarationen, sonst nicht viel. Und die genannte inttypes.h enthält ja auch so irrsinnig viele Funktionen... Es ist auch schon ein ganz schön starkes Stück, ausgerechnet Jörg des Unsinns im Zusammenhang mit WINAVR zu bezichtigen. Aber vielleicht macht Jens das ja immer so...
Johannes M. wrote: > Simon K. wrote: >> Wartet nur, bis er merkt, dass er in den Header Dateien zwar defines >> findet, aber keine Funktionsrümpfe ;) > Tja, Typdefinitionen, Makros und Deklarationen, sonst nicht viel. Und > die genannte inttypes.h enthält ja auch so irrsinnig viele Funktionen... > > Es ist auch schon ein ganz schön starkes Stück, ausgerechnet Jörg des > Unsinns im Zusammenhang mit WINAVR zu bezichtigen. Aber vielleicht macht > Jens das ja immer so... Ach ihr Winsler! Quellen sind eh nur was für Weicheier. Echte Kerle schauen direkt in den Binärcode der Bibliotheken. Wer Object- und Maschinencode nicht flüssig lesen kann, der ist es eh nicht wert, einen µC programmieren zu dürfen.
Johannes M. wrote: > Es ist auch schon ein ganz schön starkes Stück, ausgerechnet Jörg des > Unsinns im Zusammenhang mit WINAVR zu bezichtigen. Aber vielleicht macht > Jens das ja immer so... Genau das habe ich auch gedacht ;) Hehe. Fragt sich wer mehr Ahnung hat. Der Gast oder einer der Maintainer des WINAVR Pakets bzw. AVR-GCC/avr-libc Codes.
Johann L. wrote: > Echte Kerle schauen direkt in den Binärcode der Bibliotheken. Wer > Object- und Maschinencode nicht flüssig lesen kann, der ist es eh nicht > wert, einen µC programmieren zu dürfen. Klar, ich erledige auch meine ganze tägliche Korrespondenz in Binär. Mein Chef hat schon aufgehört, nachzufragen...;-) Simon K. wrote: > Genau das habe ich auch gedacht ;) Hehe. Fragt sich wer mehr Ahnung hat. > Der Gast oder einer der Maintainer des WINAVR Pakets bzw. > AVR-GCC/avr-libc Codes. Vor allem, wenn "der Gast" nicht mal ein Makro von einer Funktion unterscheiden kann...
Der Arme muss extrem frustriert von der Sucherei sein. Sein Beispiel mit __LPM_enhanced__(addr) hat ihn denken lassen, das die Library-Funktionen letztlich sämtlich in Preprozessor-Defines mit _asm_ verpackt sind. Und nun wollen ihm alle ihre Märchen von Libraries und DLLs und Linkern auftischen, an die sie schon seit 1980 glauben. Naja, Glauben ist ja letztlich das Gegenteil von Wissen. In Namen des Quellcodes, des Compilers und des Linkers Amen. Compiler unser im Rechner, getippt sei Dein Name auf der Kommandozeile Deine MemoryMap komme, Dein Kontrollfluss geschehe, wie im Rechner so auf Papier. Unser tägliches Objektfile gibt uns heute Und vergib uns unsere Syntaxfehler wie auch wir die Bugs vergeben, deinen Programmieren. Und optimiere nicht unseren Code weg sondern erlöse uns von den Designfehlern Denn Dein ist das berechnen und das Ergebnis und seine Korrektheit bis zum Shutdown. Amen
Johann L. wrote:
> Echte Kerle schauen direkt in den Binärcode der Bibliotheken.
Wozu Bibliotheken? Wird alles hinteinander weg in den Speicher
geschrieben. :-)
Zu Z80-Zeiten kannte man in der Tat ja noch eine Reihe an Binärcode
auswendig. Ist mir aber seither nicht mehr wirklich untergekommen.
Entschuldigt bitte das -- Unsinn usw. --- ich wollte keinem zu Nahe treten und niemanden beleidigen ... sorry .... ... war etwas im Stress und wollte halt schnell eine plausible Erklärung .... ... die Erklärung von Herrn Buchegger mit der Runtime-Library scheint mir einleuchtend, denn nach wie vor ... kann ich auf meinem Rechner keine rand.c oder math.c finden, nur die Headerdateien, wo meistens nur Definitionen bzw. Makros stehen, ab und zu ein Assembler-Code. Und wie geschrieben, die rand() Funktion funktioniert ja und liefert Zufallszahlen. Da ich jahrelang in Assembler programmiert habe, dachte ich eben, irgendwo den Code für rand() zu finden .....
Jens wrote: > Da ich jahrelang in Assembler programmiert habe, dachte ich eben, > irgendwo den Code für rand() zu finden ..... Den hatte Johann dir schon lange rausgepopelt: Beitrag "Re: rand() - in welcher Datei finde ich das Assembler-Programm?" (Anhang beachten!) Dazu gibt es in der Tat dann irgendwann auch ein Stück Assemblercode, nämlich das vom Compiler dafür generierte. Aber das guckt sich normalerweise niemand an, da es eben nicht das Quellprogramm ist. Die avr-libc ist ein eigenständiges Projekt und erzeugt ihre Releases jeweils als Sourcecode-Archive: https://savannah.nongnu.org/files/?group=avr-libc Dein WinAVR bringt davon jedoch eine Binärversion mit, da nicht davon ausgegangen wird, dass der Durchschnittsnutzer sich die Sachen alle selbst nochmal compilieren will, sodass es genügt, wenn der Sourcecode im Internet verfügbar ist.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.