C Fragen nerven!!

Hallo Fritz 7,

kannst Du mir erklären, warum dich "C Fragen nerven"?
Was ist schlecht an C?
Ich denke sogar, dass C immer wichtiger werden wird, da die neuen Atmels 
bereits so leistungsstark sind, dass man umfangreichere und interessante 
Projekte gar nicht mehr mit Assembler anfangen sollte. Ausserdem ist der 
AVR Core doch so entwickelt worden, dass gerad C-Befehle hervorragned 
umgesetzt werden können.
Wieso also genervt?

Gruß Oliver

Puhh... das weis ich jetz auch nich mehr so genau was ich mir damals 
überlegt habe.

Fritz7

Hi Fritz7,

sehr witzig :-) Aber ich muss sagen, Deine Antwort gefällt mir.

Gruß Oliver

Oliver hat recht,

es wurde sogar festgestellt, dass der Code, welcher aus einem guten 
Complierer zeugt wird, effektiv kürzer ist, als wenn man das Projekt in 
Assembler schreibt. Das gilt besonders für die AVR's und bereits ab 
einer Programmgröße von 1kB.

Was ist ein guter Compiler?
Sag bitte nicht IAR, den kann sich doch wirklich kaum einer leisten!

Gruß Axel

höh?? wie kann denn c code kleiner sein als asm? wenn man richtig
assembler kann dann hat man immer nen kleineren code als mit c. ist nur
eine frage des könnens. und leider können viele assembler nicht richtig
gut, da es eben verdammt komplex sein kann.

@Tobias - das verstehe ich jetzt auch nicht. Moechte nur einen
C-Compiler sehen der an die Effizienz von Assembler herankommt.

Verstehe auch nicht was sich Reini dabei gedacht hat?


Gruss,

Ole.

Hi

die meisten Hobby-ASM Programmierer erreichen nicht das Level eine
C-Compilers wenn die Programme etwas komplexer werden. Der C-Compiler
erzeugt zwar bei kleinen Programmen recht viel Overhead wenn die
Alghorithmen aber komplexer werden erzeugt er besseren Code. Natürlich
kann ein gewifter ASM-Programmierer hier noch manches optimieren aber
nicht jeder ist so gewift wie die Entwickler des Compilers.

Das man mit C schneller zum Ziel kommt (Wenns mehr als an ein paar
Ports wackeln ist) steht wohl auser Frage.

Matthias

die ansichten über c und assembler sind verschieden. ich bin auch dafür,
u.u. 2 verschiedene zweige aufzumachen (1-asm 2-c) das hat nichts damit
zu tun was beser ist, aber asm progger und auch c-progger finden
schneller was sie suchen.
persönlich bin ich auch asm fan, da weiss ich wie lange der yc brauch
füe diverse sachen, bei der fehlersuiche ist es natürlich nicht mehr so
schön.
aber wenn jemand kommt mit: die letzten atmels sind so
leistungsstark.... dann können wir unsere rechner wieder mit dos (ist
eh stabiler) füttern und mit 8080 laufen lassen. die heutige zeit ist
grauenhaft. je schneller die technik, desto lahmer die
programmiersprache. in 10 jahren werden alle nur noch basic
programmieren, wenn die ersten nano prozessoren aufm, markt sind, und
effektiv so schnell wie mein sr1 oder auch ein 130xe ;).
jedem seine programmiersprache. auch unter linux würde ich lieber in
asm proggen, aber der aufwand ist füe das meiste zu hoch. wenn man
jedoch extrem intensiv arbeitet, dann lohnt es sich schoin, seine
eigenen libs in asm zu schreiben.
ein gutes beispiel füe einen guten c-compiler (leider nicht füe yc) ist
der icc. da haben sich intels leute einfach den heimvorteil gesichert,
und die interne des intels zu nutze gemacht. der icc erzeugt gegenüber
herkömmlichen c-compilern teiweise bis zu 40% schnelleren code (auf
intels, aber teilweise auch auf amd (die besseren proc))
komplexe dinge dafür ist c besser, will man die laufzeit im
überblickbehalten oder ist freak, dann ist asm schon nicht schlecht.
ein gutes bsp. dafür sind (wieder im bereich dose) die demos. 128
byte-demos (die allerdings das betriebssystem ausnutzen) die dinge
leisten, die unglaublich sind. auch gab es mal ne demogroup (sie
existiert noch, aber ich kenne weder namen noch demotitel) die hat in
einem bild ein progeramm codiert, was eigentlich zigfach mehr speicher
in anspruch genommen hätte. sowas geht meiner meinung nach nur in asm.
genug gelabert. testet aus was schneller, kleiner ist und entscheidet
euch dann (in c proggen und dann abschauen, was der compiler draus
macht, fleissig lernen und dann ist asm die nr. 1 ;) )

ciao

jo da stimm ich zu. c ist bei sehr grossen komplexen programmen besser.
aber auf den normalen atmels schreibt man selten so extrem komplexe
programme. und wenn schon dann kann man ja immernoch c und asm mischen.
ist auch noch ne intersannte programmiertechnik. oder man compiliert
das programm zu asm und optimiert dann den output (was natürlich extrem
aufwändig ist aber auch nötig sein kann)

@jens:
die demogroups gibts immer noch. allerdings ist da heute die gängige
variante die 64kb windows datei. aber schau dir ruhig mal welche an, da
hauts dich echt von den socken was mit 64kb alles möglich ist!

@ tobias

ich weis, da steckt viel drin, nur ich kann sie mir nicht anschauen,
das einzigste window das bei mir läuft ist x-windows ;). mit winex hab
ich es noch nicht zunm laufen gebracht, und unter linux gibts nicht
soviel. die besten sind immer noch die polen, die ausm 8bit-atari
rausgeholt haben was gar nicht geht.
ok. das gehört nicht hierher.

jeder sollte das tun was er kann (nur nicht basic ;) nicht ernst
gemeint)
nur die fragen sollten entweder in separaten rubriken laufen oder im
titel schon stehen haben C ASM oder Basic. dann brauch keiner die
fragen lesen, der nicht c asm ... lesen will.

soweit und viel spass beim tüfteln

@andreas, sind das gute demos? wo kann man die sich runterziehen? thnx

hallo, hallo ... und was ist mit bascom-avr-basic ????
kostengünstig und ein super support!
beispieldatei für einen autonomen legobot im anhag

noch eine anmerkung zum "glaubenskrieg" asm, c, basic usw.
eigentlich entscheidet die zu programmierende hardware und die damit
programmtechnisch zu lösende aufgabe über die einzusetzende
programmiersprache ! nicht der "glaube" an eine sprache !!!
wenn eine progammieraufgabe keine zeitkritischen aspekte hat und
genügend programmspeicher vorhanden ist, warum soll ich dann keine
"hochsprache" einsetzen ?. zumal gerade anfänger mit einer
hochsprache
wesentlich erfolgreicher ihre projekte realisieren können. als beispiel
sei hier nur die "config" - anweisung von bascom-avr erwähnt. zu
schreiben " config timer0 = timer , prescale = 1024 " ist
doch für einen anfänger wesentlich einfacher, als sich mit igendwelchen
" sbi - anweisungen oder maskierungen " in den einzelnen
avr-registern auseinanderzusetzen !!!. ich programmiere schon einige
jahre in asm, pl1, fortran, c / c++ und basic, angefangen vom 8080,
8085, 6502, z80 usw. usw.
also weiter viel spass beim sammeln neuer erkenntnisse! peter

Glaubt denen kein Wort,

asm ist die einzige Programmiersprache. Alles andere ist die Abkehr vom
richtigen Pfad :-)

Gruß Oliver

Hallo Leute,
warum diskutiert Ihr eigentlich immer über so ein blödes Thema ???
Habt Ihr nichts anderes zu tun ???
Lasst doch die asm proggers machen was sie wollen. Man kann denen
sowieso nicht klar machen, dass sie sich viel zu viel Arbeit machen.
Ohne die vernünftigen Hochsprachen würden wir immer noch mit der Keule
schwingen. Bald wird es so was sowieso nicht mehr geben, und dann
herrscht endlich Ruhe.

Gruß Mattias

Mir is eigentlich auch egal wer mit was programmiert,

Aber bitte ! Splitet das Forum auf in die C / ASM Sparten wenns sein
muß auch noch Basic das wäre sehr sinnvoll.

Das wäre alles andere als Sinnvoll, da man bei einem Mikrocontroller
schon wissen sollte, was nach einem Compilerlauf hinten rausfällt!

Gruß,
Patrick...

Hi,

aber eine Klassifizierungsmöglichkeit für jeden einzelnen Beitrag wäre
schon  praktisch.  Aber bitte nur, wenn man die dann auch als
Suchkriterium nutzen kann!

Gruss,
Oli

"Lasst doch die asm proggers machen was sie wollen. Man kann denen
sowieso nicht klar machen, dass sie sich viel zu viel Arbeit machen.
Ohne die vernünftigen Hochsprachen würden wir immer noch mit der Keule
schwingen. Bald wird es so was sowieso nicht mehr geben, und dann
herrscht endlich Ruhe."

Das ist absolut falsch, was Optimierungen angeht.

Generell sollte man erstmal auf der algorithmischen Ebene optimieren,
das ganze in C verwirklichen und dann evtl. weiter darn feilen bis
wirklich nichts mehr zu verbessern ist. Dann disassembliert man das
ganze und schaut, ob sich der Compiler evtl. etwas dumm angestellt hat,
oder ob es vielleicht subtilere Optimierungen gibt, die einem auf der
C-Ebene nicht auffallen. Beispiel: floating-point Operationen und
Integer-Operationen. Der Compiler hat keine Intelligenz, um den Code
beispielsweise so umzustricken, dass auf die float-Operationen
Integer-Operationen folgen, und so die CPU weiterarbeitet während die
FPU das Ergebnis ermittelt.

Auf den heutigen PCs erreicht man viele Optimierungen meist dadurch,
dass man die Speicherarchitektur versteht, sprich: wie der Cache
funktioniert, wie die MMU funktioniert, wie ein TLB funktioniert, und
wie man seine Speicherzugriffe auf ein möglichst kleines "working
set" beschränkt um Seitenfehler zu minimieren.

Solche Optimierungen sieht man teilweise auf der C-Ebene (man kann
beispielsweise seine Datenstrukturen so umordnen, dass die Daten nicht
nach logischem Zusammenhang geordnet sind, sondern nach den
Zugriffsmustern, d.h. dass Daten die gemeinsam benutzt werde auch nahe
beianander im Speicher sind), aber Cache-optimierungen sieht man oft
nur auf der Assembler-Ebene.

Wenns um höchste Geschwindigkeit geht kommt man um ASM daher nicht
drumrum. Wer so Sachen machen will wie etwa Gleichungssysteme oder
DGL's höherer Ordnung lösen, der muss wirklich jede Nanosekunde
rausoptimieren die er rausoptimieren kann. Bei Millionen oder
Milliarden von Berechnungen entscheiden kleinste Optimierungen darüber,
ob man nachher ein paar Minuten oder eine halbe Stunde auf sein
Ergebnis warten muss! Wer sowas programmieren will, muss die totale
Kontrolle haben über alles was passiert, und das geht nur mit ASM.
Selbst so Sachen wie die Seitengröße des virtuellen Speichers muss man
wissen und den Code daraufhin optimieren.

Den Assembler wird's daher weiterhin geben, daran ändert auch die
tollste Hochsprache nicht!

Hi

Sowohl ASM als auch C wie auch Sprachen die noch weiter abstrahieren
(C++, Java) haben ihre Berechtigung. Allerdings ist es die Komplexität
die einem bei der ASM-Optimierung zu schaffen macht. Bei einem AVR,
8051 oder PIC ist es problemlos. Da kann man die Abarbeitung der
Maschinenbefehle 100% vorraussehen ohne viel um die Ecke denken zu
müssen. Bei einem ARM7 mit seiner 3 stufigen Pipeline wirds schon
schwieriger. Bei einem P4 mit seiner über 20 stüfigen Pipeline, Out of
Order Execution und und und ist das nur sehr schwer zu durchschauen.
Vor allem für jeden einzelnen Entwickler von geschwindigkeitskritischer
Software. Der Compilerbauer kann das aber sehr gut da er erstens die
Architektur sehr gut kennt und sich mit nichts anderem als
Codegenerierung beschäftigt.

Ein Beispiel dafür:

POVRay (mehrere Megabyte C++ Sourcecode) compiliert für AMD64 mit GCC
3.3.1 und GCC 3.4.0
Leistungssteigerung: knapp 7%. Um diese 7% per ASM-optimierung zu
erreichen wären wohl einige Tage nötig.

Wenns aber wirklich ans letzte bischen Leistung ran muß kann der
Einsatz von ASM an entscheidenen Stellen durchaus Sinn machen. Oftmals
ist es aber billiger einfach schnellere Hardware einzusetzen (sofern
verfügbar) als Tagelang über ASM-Code zu brüten. Entwicklerstunden sind
teuer.

Ich stell diesen Beitrag mal ins Wiki unter der Überschrift ASM vs. C.
Ich hoffe er ist soweit wertungsneutral das man das so stehen lassen
kann.

Matthias

Natürlich hat C,C++,java usw. genauso eine Daseinsberechtigung wie ASM;
es ist halt immer die Frage was man damit machen will!

Für eine Client-Server Applikation etwa nehme ich Java, weils
Kinder-leicht ist damit einfache Netzwerkapplikationen zu schreiben und
eine grafische Oberfläche damit zu erstellen. Bei sowas interessiert's
keinen Menschen mehr, wie gut der Code nun optimiert ist. Hier hat die
objekt-orientierte Programmierung nicht nur eine Berechtigung, sondern
ist unumgänglich, denn anders kann man komplexe Programme mit großen
Teams gar nicht mehr erstellen.

Wenn ich dagegen ein nicht-lineares Gleichungssystem mit einigen zig
tausend Gleichungen lösen will, dann optimiere ich das bis zum
geht-nicht-mehr. Und solche Probleme treten heute massenhaft auf, etwa
bei Statik-Berechnungen oder Aerodynamik. Hier ist es nicht nur
sinnvoll, an kritischen Stellen mit ASM zu optimieren, sondern
teilweise unabdingbar. Zumindest sollte man seinem Compiler nicht blind
vertrauen sondern wenigstens mal einen Blick auf das ASM-Listing
werfen. Compiler sind stumpfsinnige und stupide Maschinen; sie
verstehen nur die Syntax und nicht die Semantik, d.h. sie haben keinen
blassen Schimmer was der Programmierer vorhat. Subtilere Optimierungen
bringen sie daher nicht zustande.

Wie dem auch sei, es ist albern das so hinzustellen als sei "Assembler
tot", oder als sei da irgendein Widerspruch zu den modernen
Hochsprachen. Den gibts nicht! Wenn ich einen Baum fällen will, nehme
ich dazu eine Axt, und wenn ich ein Loch bohren will, nehme ich dazu
einen Bohrer. Es ist sinnlos zu behaupten, der Bohrer sei besser als
die Axt. Genauso ist es sinnlos zu behaupten, C++ wäre besser als
Assembler! Es kommt immer drauf an was man machen will. Natürlich
eignet sich C++/Java usw. tausend mal besser für DIE MEISTEN Probleme
die man heute an PCs lösen will, weil 100%ige Ausnutzung des Prozessors
nicht gewünscht ist, sondern zuverlässigkeit, logische Struktur,
einfache Wartung und Nachpflege des Codes usw. Wer an irgendwelchen
Stellen aber wirklich das letzte aus der CPU rausquetschen will, kommt
nicht drum herum ASM zu benutzen.

Hallo Leute,
ich bin anfängerin,ich möchte mal einen RS232-RS485 Umsetzer mit iccavr
programmieren unter C sprache.Ich benutze den ATMEL128L als Prozessor.
Kann vielleicht jd helfen ?
danke

@Salwa: hehe, mir ist gerade aufgefallen, dass dieser Thread "C Fragen
nerven!!" heisst. Nicht gerade DER Thread, um eine C Frage zu stellen,
oder?

s

Ich kann zumindest für mich beantworten was an C nervt.

C!

:-)

Eine sehr qualifizierte Antwort...

Hallo allerseits

nun möchte ich meine Senf auch noch dazu geben. Zu den schon gennanten
Vor- und Nachteilen habe ich auch noch ein paar Anmerkungen.

1.) Es gibt C Compiler die derartig gut optimieren, das eine Assembler
Programmiere sehr viel Zeit benötigt um diese Tricks und Kniffe erste
einmal zu lernen.

2.) Schnelle Abarbeitung von mathematischen Funktionen haben häufig
ihre Ursache in der Optimierung des Algorithmus. Mehr als 20% sind auch
bei einem schlecht optimierenden C Compiler gegen ein Assembler Programm
nicht zu erwarten. Ausnahmen stellen hier eventuell Signalprozessoren
dar, aber auch hier soll es mittlerweile Compiler geben die
entsprechend optimiert sind.

3.) Portierbarkeit. Wie wollt Ihr ein Assembler Programm auf eine
neue/andere Hardwareplattform übertragen? In C habe ich, zumindest wenn
ich mich an ein paar einfache Regel halte, eine gute Chance so etwas mit
geringem Aufwand zu bewältigen.

4.) Viele Fragen hier im Forum drehen sich um hardwarenahe Probleme,
wie z.B. Ansteuerung von Ports, UART, etc. Diese Dinge sind aber genau
genommen unabhängig von einer bestimmten Programmiersprache.

5.) Sicher sollte man die Eigenheiten der verwendeten CPU kenne. Dazu
sind natürlich auch Assemblerkenntnisse nötig. Und wenn man einen
Compiler verwendet sollte man an Hand der Listfiles nachvollziehen
können was der Compiler aus dem C-Source macht. Andernfalls steht man
bei Compilerbugs ziemlich im Wald.

Fazit. Ich halte ein Trennung von C und Assembler nicht für sinnvoll.

Hallo jozi,

welche C-Compiler optimieren denn derartig gut?

Ist die Diskussion nicht absolut überflüssig. Es gibt Vorteile in C zu
programmieren und ebenfalls Nachteile. Das gleiche gilt für Assembler.
Es kommt immer auf den Anwendungsfall an.
Daher kommt diese Diskussion nie zuende. Es gibt halt immer Leute aus
dem C Lager und welche aus dem Assembler Lager. Wobei meine Prognose
ist das die Assembler Leute immer weniger werden, da die Komplexität
der heutigen Prozessoren die Entwicklungszeit in Assembler nicht mehr
zulässt. Und daher wird sich die Programmierung in Hochsprachen immer
weiter in den Vordergrund setzen.
Ein Beispiel
Programmiersprachen die die Programmierung eines BS als EchtzeitBS auf
einem Proz. zulassen sind schon länger etabliert und halt nicht
Assembler (->siehe Pearl).

http://www.irt.uni-hannover.de/pearl/pearlein.html