Ich hab mir mal die Demo Version des EW8051 Compilers von IAR runtergeladen weil ich mir anschauen wollte wie groß die Unterschiede zu Keil sind. Dabei bin ich in der Dokumentation auf folgenden unscheinbaren Text gestoßen: "Many library functions declared in string.h (such as memcpy, memcmp, strcat etc.) cannot handle parameters which are located in different memory types. This might cause unexpected results." Hat jemand Erfahrung damit? Wenn ich das richtig interpretiere sind die Lib Funktionen damit unbrauchbar, da man nie sicher sein kann was den nun kopiert wird. Thomas
Das mit Big vs. little Endian einen Abschnitt davor hattest Du gesehen? Das ist in meinen Augen noch tödlicher. Die string.h Funktionen hatten wir größtenteils durch handoptimierten Assembler ersetzt, der ohnehin die Argumente jeweils in einem spezifischen Speicher erwartete (also Flash->XRAM oder IDATA->XRAM).
Jim M. schrieb: > Das mit Big vs. little Endian einen Abschnitt davor hattest Du gesehen? > Das ist in meinen Augen noch tödlicher. Ja das ist mir bewusst und habe ich denke ich im Griff. Bei einem Port nach SDCC muss man da ja auch aufpassen. Von Keil bin ich allerdings gewohnt dass ich mich um die Speicherklassen bei Libs nicht kümmern muss. Das würde eigendlich als selbstverständlich ansehen. Thomas
Thomas Z. schrieb: > Wenn ich das richtig interpretiere sind die > Lib Funktionen damit unbrauchbar Mich wundert es immer noch, wie die Leute dazu kommen, einfach all das Zeugs, was sie vom PC her gewohnt sind, ohne jegliches Nachdenken auch bei der Programmierung von kleinen Mikrocontrollern zu erwarten. Die Dinger sind oftmals eben nicht vom v.Neumann Typ, haben eben nicht RAM und ROM im Überfluß, haben dafür aber oftmals den Charme, einzelne Bits setzen und testen zu können (was mit "if (A & (1<<x)).." einfach so nicht nachbaubar ist) und so weiter. Aber dennoch wird so getan, als ob jeder Mikrocontroller nur ne verkleinerte Version des PC sei. W.S.
W.S. schrieb: > Mich wundert es immer noch, wie die Leute dazu kommen, einfach all das > Zeugs, was sie vom PC her gewohnt sind, ohne jegliches Nachdenken auch > bei der Programmierung von kleinen Mikrocontrollern zu erwarten. Mich wundert es immer noch, warum bestimmte Leute andern unterstellen dass sie nicht nachdenken. memcpy ist jetzt sicher auch auf Mikrocontrollern eine übliche Funktion von der man erwarten kann dass sie korrekt in der Lib implementiert ist. Wenn ich immer alles selbst machen muss brauche ich keinen C-Compiler dann mach das in ASM. Oder willst du mir sagen, dass du memcpy immer selbst implementierst? Thomas
Mich wundert es immer noch, warum ein gewisser W.S. es uns immer wieder beweisen muss, dass er von wirklich garnix ne Ahnung hat.
Warum sollte der IAR-Compiler wesentlich besser sein (bzw. gibt es Hinweise darauf, dass er es ist)? Den C51 von Keil gibt es schon ewig d.h. da würde ich annehmen, dass der sehr gut optimiert ist.
:
Bearbeitet durch User
Max M. schrieb: > Warum sollte der IAR-Compiler wesentlich besser sein (bzw. gibt es > Hinweise darauf, dass er es ist)? Den C51 von Keil gibt es schon ewig > d.h. da würde ich annehmen, dass der sehr gut optimiert ist. Z.B, weil IAR, wie auch SDCC im Gegensatz zu Keil versuchen, sich an C-Standards (und sogar an nach 1990 veröffentlichte Versionen) zu halten. Wobei wie wir oben sehen anscheinend manche Bibliotheksfunktionen bei IAR hiervon eine Ausnahme bilden.
:
Bearbeitet durch User
Achso, da gebe ich dir recht. Bei Keil muss man die Variablen ja immer am Anfang einer Funktion definieren. Aber hinsichtlich Performance / Codegröße vermute ich keine großen Unterschiede. Ich könnte das auch mal selber ausprobieren, z.B. mit so einem WCH551 USB 8051 uC.
Thomas Z. schrieb: > memcpy ist jetzt sicher auch auf Mikrocontrollern eine übliche Funktion > von der man erwarten kann dass sie korrekt in der Lib implementiert ist. > Wenn ich immer alles selbst machen muss brauche ich keinen C-Compiler > dann mach das in ASM. > Oder willst du mir sagen, dass du memcpy immer selbst implementierst? Gedankenlosigkeit hoch drei! "memcpy" ist auf vielen Mikrocontrollern herzlich unüblich, weil selbige (wie z.B. die 8051 oder PIC) eben keine v.Neumann Maschinen sind, sondern Harvard. _Das ist ein tiefgreifender Unterschied!_ Ergo kann es dort keine "übliche Funktion" sein, die "korrekt in der Lib" implementiert ist. Schon die Argumente müssen an die unterschiedlichen Adreßräume angepaßt sein, die Maschinenbefehle sind für die Zugriffe ebenfalls unterschiedlich - und ne allgemeine Funktion, die z.B. in den Flash kopiert, ist erst recht nicht drin - aus Hardware-Gründen. Ich hab's dir schon weiter oben geschrieben, daß die gewöhnliche PC-Denkweise von C-Programierern eben nicht gedankenlos auf µC übertragbar ist. Aber du scheinst meinen Beitrag nicht verstanden zu haben. W.S.
W.S. schrieb: > Aber du scheinst meinen Beitrag nicht verstanden zu haben. Nein das hab ich nicht. Dafür reicht mein Wissen einfach nicht. Danke dass du mich aufgeklärt hast. Warum glaubst du eigendlich dass memcpy ins flash kopieren können soll?
und noch was mit Keil und vermutlich auch mit SDCC (da hab ich weniger Erfahrung) kann ich problemlos von/zu data, idata,pdata und xdata kopieren. In meiner großen Naivität hab ich allerdings noch nie probiert in den code Speicher zu kopieren. Aus dem code Speicher nach z.b. data hab ich aber schon gemacht. Thomas
W.S. schrieb: > "memcpy" ist auf vielen Mikrocontrollern herzlich unüblich Falsch. Zum Rest deines Textes: Aus Falschem folgt Beliebiges.
W.S. schrieb: > Gedankenlosigkeit hoch drei! Jetzt hör doch mal auf immer über dich zu reden, das interessiert hier keinen. Dein geblubber zu memcpy zeugt nur wieder davon, dass du wirklich von überhaupt nichts auch nur ein Fünkchen Ahnung hast.
W.S. schrieb: > "memcpy" ist auf vielen Mikrocontrollern herzlich unüblich Woher hast Du denn diesen Quatsch? Natürlich sollte ein Compilerbauer sämtliche Standardlibs implementiert haben. Keil hat jedoch diese genialen "generic pointer" implementiert, d.h. ein Pointer besteht aus 2 Byte Adresse + 1 Byte Memorytyp. Memcpy besteht daher aus mehreren Unterfunktionen, wo je nach Typ die richtige ausgewählt wird. Man kann natürlich auch "memory specific pointer" verwenden (idata, xdata, code), dann kann der Compiler gleich die passende aufrufen und muß es nicht erst zur Laufzeit ermitteln. Ob das SDCC oder IAR auch können, weiß ich nicht. W.S. schrieb: > ne allgemeine Funktion, > die z.B. in den Flash kopiert, ist erst recht nicht drin Daß "code" nur Quelle von memcpy sein kann, sollte doch jedem klar sein.
Peter D. schrieb: > Memcpy besteht > daher aus mehreren Unterfunktionen, wo je nach Typ die richtige > ausgewählt wird. Ja _EBEN!_ genau das braucht man auf einem µC auch, weil das, was man in der Standard-Lib vom PC her kennt, prinzipiell auf sowas wie 8051 nicht gebrauchen kann. Wie oft muß ich das eigentlich sagen, bis den Leuten, die großmäulig daherkommen und nicht verstehen, daß es auf dem µC anders als auf dem PC und mit speziell angepaßtem Zeug zugeht, dies endlich klar wird? W.S.
W.S. schrieb: > Wie oft muß ich das eigentlich sagen, bis den Leuten, die großmäulig > daherkommen und nicht verstehen Wie oft denn noch: Red nicht immer von dir selbst! Fällt dir nicht langsam mal auf, dass du derjenige bist, der hier nur Mist schreibt und auch wirklich jedesmal Gegenwind bekommt? Mit anderen Postern kann man diskutieren von dur kommen nur absolutäre Aussagen, die aber nicht stimmen. Radio: Achtung ein Geisterfahrer ist auf der Autobahn! W.S.: EINER? Ich sehe hunderte Geisterfahrer!
W.S. schrieb: > Wie oft muß ich das eigentlich sagen, bis den Leuten, die großmäulig > daherkommen und nicht verstehen Was soll man da noch sagen.... Nein ich lass es jetzt.
Thomas Z. schrieb: > Was soll man da noch sagen Zu der Ignoranz und Einfältigkeit von W.S. fällt einem echt nix mehr ein.
Peter D. schrieb: > W.S. schrieb: >> "memcpy" ist auf vielen Mikrocontrollern herzlich unüblich > > Woher hast Du denn diesen Quatsch? > Natürlich sollte ein Compilerbauer sämtliche Standardlibs implementiert > haben. > Keil hat jedoch diese genialen "generic pointer" implementiert, d.h. ein > Pointer besteht aus 2 Byte Adresse + 1 Byte Memorytyp. Memcpy besteht > daher aus mehreren Unterfunktionen, wo je nach Typ die richtige > ausgewählt wird. Bei SDCC sieht es ähnlich aus, bei IAR anscheinend (nach dem Dokument mit dem der Thread begann) nicht. Das gibt es natürlich nicht nur bei 8051, sondern z.B. auch für Padauk in SDCC.
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.