Forum: Compiler & IDEs IAR 8051 Toolchain


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 Thomas Z. (usbman)


Angehängte Dateien:

Bewertung
2 lesenswert
nicht lesenswert
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

von Jim M. (turboj)


Bewertung
0 lesenswert
nicht lesenswert
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).

von Thomas Z. (usbman)


Bewertung
0 lesenswert
nicht lesenswert
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

von W.S. (Gast)


Bewertung
-5 lesenswert
nicht lesenswert
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.

von Thomas Z. (usbman)


Bewertung
5 lesenswert
nicht lesenswert
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

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
0 lesenswert
nicht lesenswert
Mich wundert es immer noch, warum ein gewisser W.S. es uns immer wieder 
beweisen muss, dass er von wirklich garnix ne Ahnung hat.

von Max M. (maxmicr)


Bewertung
0 lesenswert
nicht lesenswert
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
von Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)


Bewertung
0 lesenswert
nicht lesenswert
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
von Max M. (maxmicr)


Bewertung
0 lesenswert
nicht lesenswert
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.

von W.S. (Gast)


Bewertung
-6 lesenswert
nicht lesenswert
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.

von Thomas Z. (usbman)


Bewertung
1 lesenswert
nicht lesenswert
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?

von Thomas Z. (usbman)


Bewertung
1 lesenswert
nicht lesenswert
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

von S. R. (svenska)


Bewertung
5 lesenswert
nicht lesenswert
W.S. schrieb:
> "memcpy" ist auf vielen Mikrocontrollern herzlich unüblich

Falsch. Zum Rest deines Textes: Aus Falschem folgt Beliebiges.

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Peter D. (peda)


Bewertung
3 lesenswert
nicht lesenswert
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.

von W.S. (Gast)


Bewertung
-5 lesenswert
nicht lesenswert
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.

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
0 lesenswert
nicht lesenswert
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!

von Thomas Z. (usbman)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)


Bewertung
1 lesenswert
nicht lesenswert
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.

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]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [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.