Herzlich Willkommen, lieber Gast!
  Sie befinden sich hier:

  Forum » Assembler » Was ist Assembler? und welches ist das best?

Forum | Hilfe | Team | Links | Impressum | > Suche < | Mitglieder | Registrieren | Einloggen
  Quicklinks: MSDN-Online || STL || clib Reference Grundlagen || Literatur || E-Books || Zubehör || > F.A.Q. < || Downloads   

Autor Thread - Seiten: [ 1 ] [ 2 ] > 3 < [ 4 ]
020
03.08.2004, 22:38 Uhr
(un)wissender
Niveauwart


Richtig, der Bluescreen ist zwar jetzt performanter, aber MS dachte sich, wenn der doch schon so schön schnell ist, dann sollte der Kunde ihn auch öfter zu sehen bekommen, daraus wurde dann WinME.
--
Wer früher stirbt ist länger tot.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
021
06.10.2004, 17:37 Uhr
derphilipder



Also wir lernen im Studium(Elektrotechnik) gerade ein wenig Assembler. Allerdings nur am alten Intel 8085.
Der Prof sagt, dass in ambedded-Systemen noch zu einem Viertel in Assembler programmiert wird, zumindest bei zeitkritischen Anwendungen.
--
Konfuzius says: "A man who goes to bed with an itchy asshole is a man who wakes up with stinky finger!"
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
022
06.10.2004, 18:08 Uhr
(un)wissender
Niveauwart


Welcher Prof. nennt schon konkrete Zahlen?! Dafür ist er i. d. R. viel zu schlau, das überläßt er seinen Mitarbeitern.
--
Wer früher stirbt ist länger tot.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
023
06.10.2004, 19:13 Uhr
derphilipder





Was soll das jetzt heißen?
--
Konfuzius says: "A man who goes to bed with an itchy asshole is a man who wakes up with stinky finger!"
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
024
06.10.2004, 20:16 Uhr
(un)wissender
Niveauwart


Steht doch da.
Profs halten sich, wenn irgend möglich, von konkreten Aussagen fern, es sei denn sie sind ganz sicher, und die Schätzung ist sicher nicht sicher.
--
Wer früher stirbt ist länger tot.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
025
07.10.2004, 10:33 Uhr
derphilipder



Zitat aus einem Buch zur Infineon XC16X-Mikrocontroller-Programmierung:


Zitat von Verfasser:

C-Code versus Assembler-Code

Die meisten Programmierbeispiele in diesem Buch sind in Assembler-Code gezeigt. Dies wird im ersten Moment sicher keinen Jubel bei C-Programmierern hervorrufen. Aber bevor diese das Buch aus der Hand legen: es lohnt sich hin und wieder doch, auch auf Assembler-Code einen Blick zu werfen. ‘C’ ist sicherlich keine Sprache, die für die Programmierung von Controllern entwickelt wurde, sie hat sich jedoch weltweit auch auf diesem Gebiet durchgesetzt und verdrängt immer mehr die reinen Assembler-Programme. Sie kann jedoch aufgrund ihrer Herkunft und den damit festgelegten Standards nie an die Effektivität von Assembler-Code herankommen. Daher wird es immer notwendig sein, zeitkritische Teile einer Software in Assembler zu realisieren.

Viele der Beispiele zeigen die Behandlung der Peripherie-Einheiten. Manche Assembler-Routinen sind so kurz, daß das Argument, in ‘C’ lassen sich die Aufgaben schneller und leichter lösen, hier nicht gilt. Ebenfalls ist gerade bei der Behandlung der controller-spezifischen Einheiten eine Portierbarkeit der Software auf andere Prozessoren grundsätzlich problematisch, sei es in Assembler oder C-Code. Gerade an Stellen, wo Zugriffe auf Peripherie-Einheiten auftreten, ist es meist wesentlich effektiver, Assembler- statt C-Code einzusetzen. Die Verwendung von C-Code kann sich hier ungünstig auf den Code-Umfang und damit auch direkt auf die Laufzeit der Programme auswirken. Dies kann sogar dort gelten, wo nicht direkt die speziellen Eigenschaften der Controller angesprochen werden, wie z. B. bei rein mathematischen Routinen.

Die efektive Programmierung eines Controllers verlangt auch vom C-Programmierer eine gute Kenntnis des Controllers inklusive der Hardware-Eigenschaften. Es ist ein erheblicher Unterschied, ob z. B. ein Programm für einen PC geschrieben wird, bei dem nahezu unendliche Ressourcen zur Verfügung stehen und kaum Anforderungen an die Laufzeit der Programme gestellt werden, oder ob das Programm auf einem Controller für Echtzeitanwendungen mit wirtschaftlich notwendiger Ressourcenbegrenzung ablaufen soll. Hier wird oft allzuschnell der Ruf laut nach schnelleren Prozessoren und mehr Speicherplatz. Mit einer effektiveren Programmierung und schonenderem Einsatz der Ressourcen können jedoch weit mehr Leistungsreserven geschaffen werden als der Wechsel zur nächstschnelleren Prozessorgeneration erbringen kann. Mit einem Übergang zu schnelleren Speichern und Prozessoren sind in der Regel weitaus höhere Kosten verbunden als durch eine etwas verlängerte und gründlichere Entwicklungszeit inklusive entsprechender Schulung der Projektbeteiligten.



--
Konfuzius says: "A man who goes to bed with an itchy asshole is a man who wakes up with stinky finger!"
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
026
07.10.2004, 11:59 Uhr
ao

(Operator)



Zitat von derphilipder:
Also wir lernen im Studium(Elektrotechnik) gerade ein wenig Assembler. Allerdings nur am alten Intel 8085.
Der Prof sagt, dass in ambedded-Systemen noch zu einem Viertel in Assembler programmiert wird, zumindest bei zeitkritischen Anwendungen.

Ich glaube, das ist inzwischen kaum noch eine zeitkritische Frage, denn Echtzeitprogrammierung in Hochsprachen ist technisch kein Problem mehr. Sie erfordert nur mehr Resourcen (Speicher und CPU-Leistung), und es ist eine wirtschaftliche Frage, ob sich das lohnt.

Assembler-Entwicklung ist teurer als Hochsprachen-Entwicklung. Die Einarbeitung dauert länger, das Wissen ist spezialisiert und wenig übertragbar.

Lohnen tut sich das besonders bei Produkten, die in Massen hergestellt werden, aber softwaretechnisch eher einfach gestrickt sind. Dann zählt bei der Hardware jeder Cent, und die Softwareentwicklung macht nur einen kleinen Anteil aus. Das heißt, es zahlt sich aus, etwas höhere Softwarekosten in Kauf zu nehmen, wenn man anschließend eine Million Platinen mit einem kleineren ROM oder billigeren Prozessor bestücken kann.

"Softwaretechnisch einfach" meint hier insbesondere "Inselgeräte", die keine Kommunikation mit anderen Geräten ausführen. Sobald Protokolle wie TCP/IP oder auch Multitasking-Systeme ins Spiel kommen, ist der Entwicklungsaufwand dafür meist so hoch, dass eine durchgängige Assembler-Entwicklung zu lange dauert und viel zu teuer wird.

Zumal es für die gängigen Protokolle Hochsprachen-Implementierungen gibt, die hochgradig portabel sind, wo 98 oder mehr Prozent des Codes blind neu kompiliert werden können und nur ein paar ganz elementare Routinen (z.B. Speichermanagement) angepasst werden müssen.

Und auch Multitasking-Systeme werden heutzutage überwiegend in Hochsprachen geschrieben, nur der innerste Kern (der Task-Switcher) ist oft noch in Assembler.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
027
07.10.2004, 12:45 Uhr
ao

(Operator)



Zitat von derphilipder:
Zitat aus einem Buch zur Infineon XC16X-Mikrocontroller-Programmierung:

[quote Verfasser]
C-Code versus Assembler-Code

....


[/quote]

Hier gibt sich aber jemand Mühe, eine Lanze für Assembler zu brechen. Ich seh das anders.

C-Compiler für Microcontroller sind auch ziemlich gut in der Unterstützung der Peripherie. Das ist einer der Gründe, weshalb sie verhältnismäßig teuer sind, denn hier fließt Spezialwissen ein. Es ist also bei weitem nicht so, dass man in C nur schnarchlangsame und speicherfressende Monster schreiben kann.

Klar, handoptimierter Assemblercode kann schneller sein als C-Code, vor allem dann, wenn es um kurze Routinen geht, und die meisten Peripherie-Routinen sind kurz. Aber Handoptimierung ist teuer, weil da viel Zeit reingeht. Es ist ja nicht damit getan, die Lösung einfach hinzutippen, sie muss gesucht werden, und wenn sie gefunden ist, muss noch verifiziert werden, dass sie frei von Seiteneffekten ist usw. Besonders wenn man an irgendwelchen Registern herumoptimiert, schießt man leicht einen Bock. Ich bin froh, dass ich sowas meinem Compiler überlassen kann.

Zum Thema Portierbarkeit: Angenommen, ich habe ein Software-Team von vier Leuten, das meine Microcontroller-Firmware schreibt und die Projekte komplett in Assembler abwickelt. Jetzt migrieren wir auf eine neue Hardware-Plattform, d.h. vier Leute müssen geschult werden und die Software wird von vorn bis hinten neu geschrieben, denn Mitnehmen alter Codeteile ist nicht möglich. Bis was Lauffähiges fertig ist, vergehen locker sechs Monate, d.h. nur die Hardware-Migration (ohne Weiterentwicklung) kostet mindestens zwei Mannjahre Softwareentwicklung plus Schulungskosten für 4 Leute.

Habe ich aber einen Mann im Team, der nur die Lowest-Level-Funktionen in Assembler schreibt, und die anderen programmieren die höheren Teile in C, dann muss ich nur den einen Mann fortbilden, damit der seine Low-Level-Routinen in vier Wochen portiert. Die anderen brauchen keine Schulung, die kriegen neue C-Compiler, das kostet ungefähr dasselbe. Damit recompilieren die nur ihren Quellcode (gut, ganz ohne Verifikation gehts auch nicht, aber vom Neuschreiben sind wir weit weg), und nach wenigen Wochen steht das alte Produkt auf einer neuen Plattform. Ich hatte nicht nur weniger Lohnkosten, ich bin auch schneller fertig und komme schon ans Verkaufen, wenn die Konkurrenz noch wild am Entwickeln ist.

Dieser Post wurde am 07.10.2004 um 14:24 Uhr von ao editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
028
07.10.2004, 14:33 Uhr
ao

(Operator)



Zitat von ao:
[quote derphilipder]Zitat aus einem Buch zur Infineon XC16X-Mikrocontroller-Programmierung:

[quote Verfasser]
C-Code versus Assembler-Code

....


[/quote]

Hier gibt sich aber jemand Mühe, eine Lanze für Assembler zu brechen. Ich seh das anders.

C-Compiler für Microcontroller sind auch ziemlich gut in der Unterstützung der Peripherie. Das ist einer der Gründe, weshalb sie verhältnismäßig teuer sind, denn hier fließt Spezialwissen ein. Es ist also bei weitem nicht so, dass man in C nur schnarchlangsame und speicherfressende Monster schreiben kann.

Klar, handoptimierter Assemblercode kann schneller sein als C-Code, vor allem dann, wenn es um kurze Routinen geht, und die meisten Peripherie-Routinen sind kurz. Aber Handoptimierung ist teuer, weil da viel Zeit reingeht. Es ist ja nicht damit getan, die Lösung einfach hinzutippen, sie muss gesucht werden, und wenn sie gefunden ist, muss noch verifiziert werden, dass sie frei von Seiteneffekten ist usw. Besonders wenn man an irgendwelchen Registern herumoptimiert, schießt man leicht einen Bock. Ich bin froh, dass ich sowas meinem Compiler überlassen kann.

Zum Thema Portierbarkeit: Angenommen, ich habe ein Software-Team von vier Leuten, das meine Microcontroller-Firmware schreibt und die Projekte komplett in Assembler abwickelt. Jetzt migrieren wir auf eine neue Hardware-Plattform, d.h. vier Leute müssen geschult werden und die Software wird von vorn bis hinten neu geschrieben, denn Mitnehmen alter Codeteile ist nicht möglich. Bis was Lauffähiges fertig ist, vergehen locker sechs Monate, d.h. nur die Hardware-Migration (ohne Weiterentwicklung) kostet mindestens zwei Mannjahre Softwareentwicklung plus Schulungskosten für 4 Leute.

Habe ich aber einen Mann im Team, der nur die Lowest-Level-Funktionen in Assembler schreibt, und die anderen programmieren die höheren Teile - d.h. alles, was nicht auf Hardware zugreift - in C, dann muss ich nur den einen Mann fortbilden, damit der seine Low-Level-Routinen in vier Wochen portiert. Die anderen brauchen keine Schulung, die kriegen neue C-Compiler, das kostet ungefähr dasselbe. Damit recompilieren die nur ihren Quellcode (gut, ganz ohne Verifikation gehts auch nicht, aber vom Neuschreiben sind wir weit weg), und nach wenigen Wochen steht das alte Produkt auf einer neuen Plattform. Ich hatte nicht nur weniger Lohnkosten, ich bin auch schneller fertig und komme schon ans Verkaufen, wenn die Konkurrenz noch wild am Entwickeln ist.[/quote]

Dieser Post wurde am 07.10.2004 um 14:34 Uhr von ao editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
029
07.10.2004, 18:41 Uhr
derphilipder



Hmm...können wir uns wenigstens darauf einigen, dass es, um die Funktionsweise eines Mikroprozessor besser zu verstehen, nicht schadet, mal Assembler zu lernen?!
--
Konfuzius says: "A man who goes to bed with an itchy asshole is a man who wakes up with stinky finger!"
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
Seiten: [ 1 ] [ 2 ] > 3 < [ 4 ]     [ Assembler ]  


ThWBoard 2.73 FloSoft-Edition
© by Paul Baecher & Felix Gonschorek (www.thwboard.de)

Anpassungen des Forums
© by Flo-Soft (www.flo-soft.de)

Sie sind Besucher: