Ausführungszeit ISR

Das kann ich mir nicht vorstellen, allein das Sichern der für uint32_t 
nötigen Register dauert ja schon ...

Warum brauchst Du uint32_t?
So wie es aussiht, bleiben die oberen 24 Bit immer Null.

Was passiert mit temp_data im restlichen Programm? Wird es woanders 
gelesen oder auch geschrieben?

Gruß, Stefan

Pepe schrieb:
> Kann mir jemand sagen ob der folgende Code auf einem ATMega328 mit 16MHz
> Quarz in eine ISR passt die zur Abarbeitung 1.5µs (ca. 24 Takte) Zeit
> hat?
>
> void clockOneBitIn(void)
> {
>   uint8_t mask = PINB & 0x01;
>   temp_data = temp_data << 1;
>   temp_data &= (uint32_t) mask;
> }
>
> "temp_data" ist weiter oben im Quelltext natürlich als uint32_t
> definiert.
>
> LG,
>
> Pepe

Sinnlos!
mask kann nur die Werte 0x00 oder 0x01 annehmen.
Nach Zeile Zwei wird das niedrigste Bit in temp_data immer 0 sein.
Nach Zeile Drei steht in temp_data immer 0


Also würde ich folgendermaßen umformen:

1

void clockOneBitIn(void)

2

{

3

  temp_data = 0;

4

}

Ups, da hat sich ein Fehler eingeschlichen! Das UND muss natürlich ein 
ODER sein :-)

void clockOneBitIn(void)
{
  uint8_t mask = PINB & 0x01;
  temp_data = temp_data << 1;
  temp_data |= (uint32_t) mask;
}

Die ISR soll im Prinzip eine SPI "belauschen" und in temp_data stehen 
halt immer die letzten 24 empfangenen Bit drin. Nur die brauche ich.

Die Hardware-SPI kann ich leider nicht benutzen weil die schon als 
MASTER zur Kommunikation mit einer SD-Karte im Einsatz ist.

Mit dem Oszi habe ich gemessen das die Quelle die "belauscht" werden 
soll Clock-Pulse von 1.5µs hat.

LG,

Pepe

Pepe schrieb:
> Mit dem Oszi habe ich gemessen das die Quelle die "belauscht" werden
> soll Clock-Pulse von 1.5µs hat.

und mit welcher Frequenz?

Wenn die 1,5µs stimmen, so hätten wir bei einem Puls/Pause Verhältnis 
von 1:1 eine SPI Frequenz von 1/3 MHz.

Kommt mir 'gefühlt' etwas hoch vor!

Ja, da hab ich mich wieder mal nicht richtig ausgedrückt :-/

Die 1.5µs habe ich schon zwischen den beiden steigenden Flanken zweier 
aufeinanderfolgender Clock-Pulse gemessen.

Sieht also so aus als müsste ich mich um eine andere Lösung bemühen :-/

Vielen Dank,

Pepe

Norbert schrieb:
> Wenn die 1,5µs stimmen, so hätten wir bei einem Puls/Pause Verhältnis
> von 1:1 eine SPI Frequenz von 1/3 MHz.
>
> Kommt mir 'gefühlt' etwas hoch vor!

Ich betreibe SPI mit einer f_clk von 20MHz. Warum sollen 300kHz hoch 
sein?

Ich denke aber, dass man das tunen könnte. Wenn man in 3 globale 
8-bit-Variablen schreibt und jeweils nur 8bit-Operationen ausführt. 
Allerdings muss man dann mitzählen, ob man in das erste, zweite oder 
dritte Byte schreiben muss. Wichtig wäre vielleicht, dass die Variablen 
nicht im RAM zwischengespeichert werden, sondern in Registern bleiben. 
Für so einfache Operationen kann man auch Assembler strapazieren, ohne 
den Überblick zu verlieren!

öhmmm schrieb:
> Norbert schrieb:
>> Wenn die 1,5µs stimmen, so hätten wir bei einem Puls/Pause Verhältnis
>> von 1:1 eine SPI Frequenz von 1/3 MHz.
>>
>> Kommt mir 'gefühlt' etwas hoch vor!
>
> Ich betreibe SPI mit einer f_clk von 20MHz. Warum sollen 300kHz hoch
> sein?

Ich schrieb
   'gefühlt' etwas hoch
und meinte
   'gefühlt' etwas hoch für Software-Abtastung!

Sind ja jetzt nach Klarstellung sogar 2/3MHz geworden.

Wenn nur ab und zu mal ein Byte vorbei kommt, würde ich vermutlich beim 
ersten Clock in die ISR hüpfen und dann darin auf sieben weitere Bits 
warten. Macht insgesamt 12µs innerhalb der ISR.
Sollte mit Assembler kein Problem sein.

Wenn das Zeuch allerdings ständig hereinprasselt, bleibt für den Rest 
der Anwendung kaum noch Zeit.

In C wird es schon wegen des Overheads wohl nichts werden mit 24 takten. 
GCC nutzt und sichert dafür einfach zu viel Register. Mit inline ASM 
(oder ggf. auch die ISR als extra ASM file) könnte man es wohl noch 
hinbekommen die Bits einzeln zu empfangen.
Vermutlich wird man den Code auch noch erweitern müssen um zu erkennen 
wenn 24 Bit fertig sind.

Manchmal ist ASM Code einfacher als den C Code so umzustellen und extrem 
zu Optimieren das der Compiler dabei was gutes raus bekommt.

Der Mega328 sollte über die USART noch einen 2. Möglichkeit für Hardware 
SPI habe, zumindest zum Senden.

Pepe schrieb:

> Kann mir jemand sagen ob der folgende Code auf einem ATMega328 mit 16MHz
> Quarz in eine ISR passt die zur Abarbeitung 1.5µs (ca. 24 Takte) Zeit
> hat?

Das wird eng, sogar in Assembler.

inthandler:        ; 4 (minimale konstante Latenz angenommen)
 push R16          ; 2
 in R16,SREG       ; 1
 push R16          ; 2

 lds R16,temp_data ; 2
 lsl R16           ; 1
 sbic PINB,0       ; 2
 sbr R16,1         ;
 sts temp_data,R16 ; 2

 lds R16,temp_data ; 2
 rol R16           ; 1
 sts temp_data,R16 ; 2

 lds R16,temp_data ; 2
 rol R16           ; 1
 sts temp_data,R16 ; 2

 lds R16,temp_data ; 2
 rol R16           ; 1
 sts temp_data,R16 ; 2

 pop R16           ; 2
 out SREG,R16      ; 1
 pop R16           ; 2
 reti              ; 4
                   ;--
                   ;30

Das Schöne an Assembler ist: man sieht sofort: Nö das geht so nicht.

Das noch bessere an Assembler: Es steht einem jederzeit frei, sich 
Auswege aus der Misere auszudenken. Hier z.B. ist eins sofort ganz klar: 
Diese Routine wird in jedem Fall der Hauptverbraucher an Rechenzeit, 
selbst wenn es mit Optimierungen gelingt, sie in den Stand der 
Echtzeitgnade zu setzen.

Im Umkehrschluß ergibt sich: es kann ansonsten im Rest des Systems 
sowieso nicht mehr sehr viel passieren, da spielt ein gewisser 
Effizienzverlust keine große Rolle mehr. Also klauen wir dem Rest des 
Systems einfach fünf (möglichst unwichtige) Register, z.B. R3..R7. Aus 
R3 macht man ein Register, welches dafür reserviert ist, in exclusiven 
ISRs den Inhalt des Statusregisters aufzunehmen und R7::R4 wird einfach 
zu temp_data erklärt.

So, nun nochmal die ISR unter den neuen Randbedingungen:

inthandler:        ; 4 (minimale konstante Latenz angenommen)
 in R3,SREG        ; 1

 clc               ; 1
 sbic PINB,0       ; 2
 sec               ;
 rol R4            ; 1
 rol R5            ; 1
 rol R6            ; 1
 rol R7            ; 1

 out SREG,R3       ; 1
 reti              ; 4
                   ;--
                   ;17


Ooops. Statt "geht garnicht" ist plötzlich mehr als ein Drittel der 
Rechenzeit noch frei. Da kann man dann tatsächlich wirklich noch eine 
richtige Anwendung parallel zur ISR laufen lassen, selbst wenn diese 
dann durch den Verzicht auf 5 von 32 Registern etwas suboptimal 
implementiert sein muß...

Only ASM rules! C is made for losers.

c-hater schrieb:
> Only ASM rules! C is made for losers.

Ach ASM, diese Hochsprache. Schreib doch gleich Opcodes.

Der übersetzte Code in Assembler sieht ja richtig sub-optimal aus?!? 
Optimierungen auf max. gesetzt? Man könnte meinen tempdata ist als

1

volatile uint8_t

deklariert.

Sebastian Wangnick schrieb:

> Ich kenn mich ja mit ASM nicht so aus (mehr mit C/C++), aber geht das
> nicht in zwei Takten?

Ja, aber nur für die beiden Sonderfälle, wo das auszuwertende Bit des 
IO-Bytes Bit 7 oder 0 ist.

Trotzdem ein konstruktiver Beitrag, denn der vorliegende Fall ist ja 
genau einer der beiden Sonderfälle, die auch noch diese Optimierung 
erlauben würden. Wir kommen also auf nur noch 16 Takte für eine 
vollständige Asm-Lösung inclusive allem nötigen ISR-Overhead.

Wie aus dem C-Lager zu hören war, kostet da schon eine nutzlose, 
vollständig leere ISR satte 23 Takte...

c-hater schrieb:
> Wie aus dem C-Lager zu hören war, kostet da schon eine nutzlose,
> vollständig leere ISR satte 23 Takte..

Ja, da geschieht auch nur vodoo magic in den Takten.
Du kannst ja eine naked ISR anlegen.

Keine Ahnung wo Deine Abneigung zu C kommt, Unwissen?

Wichtig ist das passende Mittel zum Zweck.
Also ASM wo angebracht, für komplexe Dinge C - Schon wegen der 
Wartbarkeit und Testbarkeit!

Peter Dannegger schrieb:

> Nä, wat hammer jelaach.

Aha. Auf die Fakten möchtest du natürlich (wie alle Anhänger 
irgendwelcher obskuren Glaubensgemeinschaften) nicht näher eingehen.

Also bei deiner umfassenden Kompetenz und der absolut erwiesenen 
Überlegenheit von C in jeglicher Hinsicht sollte es doch für dich als 
perfekten Kenner dieser absolut genialen Sprache ein leichtes sein, 
einen Ausweg aufzuzeigen, der ähnlich problemlos wie mein Asm-Vorschlag 
mal eben ein System von der offensichtlich vollständigen Unbrauchbarkeit 
wenigstens in den Bereich bringen kann, wo eine Brauchbarkeit als 
zumindest durchaus möglich erscheint.

Wetten, das kannst du nicht! Nä, wat hammer jelaach.

Peter Dannegger schrieb:

> Ist in Assembler auch nicht viel besser:
>
> - mindestens 1 Main-Befehl, z.B. RET: 4

Das ist variable Latenz. Die Zeit geht nicht in den Verbrauch an 
Rechenzeit durch die ISR ein, sondern sorgt nur dafür, daß sie später 
abgearbeitet wird. Dafür brauchen die Takte, die die ISR später lief, 
dann in main oder sonstwo nicht mehr bearbeitet zu werden, weil sie halt 
bereits fertig bearbeitet wurden, bevor die ISR zur Ausführung kam.

Im Übrigen kann die variable Latenz auch noch sehr viel größer als nur 
vier Takte sein. Jeder konkurrierende Interrupt geht hier mit voller 
Laufzeit seines exklusiven Teils ein, darüber hinaus auch jeder 
cli()/sei()-Block. Und nicht zuletzt: auch der simple Lag durch die 
Laufzeit der aktuellen Instruktion kann mehr als 4 Takte betragen, 
nämlich immer dann, wenn es länger dauernde Instruktionen gibt. Z.B. bei 
allen AVRs mit 22Bit-PC (ret, reti) oder auch bei AVRs mit externem RAM 
und Waitstates beim Zugriff darauf (alle RAM-Zugriffe).

Das wirklich Schlimme ist: alle diese Einzellatenzen muß man addieren, 
um den worst case für die variable Interruptlatenz ermitteln zu können. 
Da knallt es dann auch schon wieder in C, denn dort ist das garnicht 
möglich, verläßlich eine exakte Laufzeit für einen bestimmten Codeteil 
anzugeben. Denn beim nächsten Compilerlauf über denselben Quelltext 
könnte schon wieder etwas völlig anderes herauskommen...

Aber das ist nur ein Nebenkriegsschauplatz, zurück zum eigentlichen 
Gemetzel.

> - PC sichern, IV->PC: 4

OK, das ist wirklich absolut unvermeidlich.

> - RJMP zum Handler: 2

Hier ist schonmal etwas, was man in Asm ggf. wegoptimieren kann. Einfach 
indem man die ISR ab Vektor direkt in den Speicher schreibt. Das klappt 
DEFINITIV auf jeden Fall problemlos, solange der kritische Interrupt der 
einzige im System ist.

> - RETI: 4

OK, auch absolut unvermeidlich.

Zählen wir also die wirklich unvermeidlichen Sachen zusammen, ergibt 
sich die simple Rechnung 4+4=8. Und in Asm kann man wirklich problemlos 
eine leere ISR bauen, die tatsächlich immer und unter allen Umständen 
bei jeder Auslösung exakt diese acht Takte benötigt. (Oder 10 auf AVRs 
mit 22Bit-PC)

.ORG WelcherVektorAuchImmer
 reti

Nach deiner Angabe braucht in C aber eine genauso leere und genau so 
nutzlose ISR 23 Takte. Da bleibt eine Differenz von 15 Takten, immerhin 
fast das Doppelte des absoluten Minimums. Was zum Teufel macht C mit 
diesen vielen überaus wertvollen Takten?

H.Joachim Seifert schrieb:

> 1. kann man nicht jeder ISR einfach mal so 5 Register exclusiv
> zuschustern

Doch, das kann man. Wenn man die volle Kontrolle über seinen Code hat. 
Und die hat man in Asm. Da ist das ganz einfach: Man weiß, daß diese 
Register nicht zur Verfügung stehen und benutzt sie deshalb einfach 
nicht außerhalb der Bereiche, für die sie reserviert sind. Wirklich ein 
absolut triviales und leicht nachvollziehbares Konzept...

Kurz bevor die Mnemonic-Salafisten den flammenden Krummsäbel erhoben 
haben und die C-Front mobil machte, blieb die Stimme der Vernunft 
ungehört:

Ulrich hat in der Mitte des Beitrags auf die Möglichkeit hingewiesen, 
die USART im SPI-Mode zu betreiben. Wenn die noch verfügbar ist, würde 
das jede Debatte über die zu bevorzugende Programmiersprache nichtig 
machen - weil ein dediziertes HW-Modul mittels SW nicht übertrumpft 
werden kann (und auf beipflichtende Worte von sw-hater, der den Thread 
bislang augenrollend mitverfolgt hat, weil er alle seine Projekte 
ausschließlich mit GALS oder PALS umsetzt und Software generell hasst, 
kann ich gerne verzichten).

@Pepe: steht die USART noch zur Verfügung?

Gruß,
Andreas

c-hater schrieb:
> H.Joachim Seifert schrieb:
>
>> 1. kann man nicht jeder ISR einfach mal so 5 Register exclusiv
>> zuschustern
>
> Doch, das kann man. Wenn man die volle Kontrolle über seinen Code hat.

Es geht auch mit einem ASM/C-Mix. IAR bietet das, wenn man das 
notwendige Kleingeld oder Lottoglück hat :-)
Die kostenlose Demoversion läßt 4k Code zu, was für kleine, spezielle 
Anwendugen durchaus reichen kann.

Im Beitrag Beitrag "4-fach Flankenauswertung per Interrupt mit ATmega48/88" hatte ich ein 
Beispiel gebracht, wo das Grundprogramm in C und die spezielle Erfassung 
in ASM programmiert sind. Für ASM kann man die notwendigen Register 
reservieren, ohne dass diese in C als fehlend auffallen würden.

Die Int-Routinen im obigen Beispiel (qcnt_6sub.s) sind etwas 
'aufwendiger' und brauchen dennoch nur unter 2µs, weshalb Interrupts mit 
500kHz noch Zeit fürs Hauptprogramm lassen.
Die neueren ATmega/Tiny haben GPIOR-Register, die mit kurzen IN- 
OUT-Befehlen nutzbar sind. Auch da kann man lokale Variablen gut parken.

H.Joachim Seifert schrieb:
> Dann sind sie aber schnell ziemlich alle und aus dem schönen
> 32-Register-Konzept wird wieder ein armseliges A- und
> B-Akkumulator-System. Macht ja nix, wir haben jetzt ein hammergeiles
> Interruptsystem mit 6 verschiedenen sauschnellen Interrupts, also R0-R29
> sind futsch.

Bitte nicht gleich wieder ins Extreme übertreiben!

H.Joachim Seifert schrieb:
> Du laberst einen Kram zusammen...
> 1. kann man nicht jeder ISR einfach mal so 5 Register exclusiv
> zuschustern
> (es gibt tatsächlich Programme, da laufen mehr als eine :-)
>
> 2.hat nie jemand bestritten, dass kleine zeitkritische Sachen in
> Assembler u.U. effektiver programmierbar sind
>
> 3. bietet C aus diesem Grund die Möglichkeit, Assembler einzufügen

natürlich kann man das, man nimmt einfach einen "richtigen" Compiler und 
nicht dieses GCC-Gemurkse! Beim IAR kann man einige Register für solche 
Fälle exklusiv reservieren.

Peter Dannegger schrieb:
> Beim AVR-GCC dauert ein leerer Interrupt 23 Zyklen

Peter Dannegger schrieb:
> In Assembler
>
> - mindestens 1 Main-Befehl, z.B. RET: 4 - PC sichern, IV->PC: 4
> - RJMP zum Handler: 2
> - RETI: 4
> = 14

Ist ja himmelschreiend, diese Performance- Verbraterei! Man mag sich 
nicht ausmalen, was da in einem kompletten C-Projekt an unnützer Wärme 
entsteht...

Takao K. schrieb:
> sich nicht mehr mit Assembler
> rumaergern.

Ärger ist sicher nicht zielführend wenns in erster Linie Spaß machen 
soll.

> Wenn es skalierbar sein soll, muss es einfach und schnell wartbar sein,
> und das ist in Assembler halt nicht der Fall.

Innerhalb einer Architektur bleibend kannste diesen Vorteil in der 
Pfeife rauchen.

> Also sagen wir mal im DB Regionalzug mit Diesellok, 4 Megawatt, ist ein
> LED Anzeigeboard drin, mit 10 controller chips, 50 MHz, und zieht 2
> Ampere. Wen interessierts?

Jedem seine Ansprüche ;-)

Takao K. schrieb:
> Macht es nicht wenn du nicht mal deine eigenen Sources wiederverwerten
> kannst.

Beim Wiederverwerten/Verstehen gibts zwischen C- und asm Programmen kaum 
einen Unterschied. Hängt bei beiden sehr von der Dokumentation und Wahl 
der Bezeichner sowie der Komplexität der internen Funktionsmechanismen 
ab.

Takao K. schrieb:
> Das ist sch. egal.

Mit dieser Mentalität entstehen heutzutage Programme für 
Alltagsaufgaben, die schon vor 20 Jahren anständig liefen und dank 
Gedankenlosigkeit und 
die-Rechner-sind-doch-sowieso-fast-endlos-schnell-Mentalität, trotz 
Zunahme der Rechenleistung sich nur noch dinosaurierartig bewegen.
Guck dir mal manch moderne DSOs an (z.B. MSOX2012A). Vom Einschalten bis 
zur Erfassung und Darstellung des ersten Signals braucht so ein Ding 
mindestens genauso lange, wie mein erstes Röhrenoszi, Mitte der 1970er 
Jahre vor der Verschrottung gerettet.

Mit dieser Mentalität dient der Anspruch der Softwerker an die 
Rechenleistung immer als Wurst vor der Nase der Hardwareentwickler, 
statt aus der verfügbaren Hardware Performance den optimalen Nutzen für 
die Anwendung zu ziehen.

Takao K. schrieb:
> Irgendwann hat mir mal jemand in der Korrespondenz mitgeteilt, das er
> mein Assemblerprogram nicht versteht.

Dann hast Du entweder Mist geschrieben, den Code nicht ordentlich 
dokumentiert oder derjenige konnte mit Asm nichts anfangen.

Takao K. schrieb:
> Zusammen mit der Tatsache das Microchip einen fertigen USB Stack
> anbietet, hat dies dann dazu gefuehrt, dass ich auf C umgestiegen bin.

Warum nicht. Dann wird ja vieles vorgekaut was man nicht mehr selbst 
coden muß... Könnte es diesbezüglich mit Atmels ASF auch einfacher 
haben. Nur die ganze Sucherei nach gesuchten Funktionalitäten! Und dann 
paßt es doch nicht wie man will oder enthält unangenehme unbekannte 
Nebeneffekte oder gar Fehler. Das altmodische drahtgebundene USB würd 
mich nun gerade auch nicht reizen ;-(

Takao K. schrieb:
> Mein Punkt ist, dass ich C Compiler als eine Art automatisierte Art
> verstehe, Assembler zu schreiben

Wenn es mal so wäre. Statt dessen Compilerfehler, -eigenheiten, 
-sonderwünsche. Alles langsamer, größer und im Entwicklungsprozeß 
komplizierter als nötig. Na dankeschön...

Takao K. schrieb:
> Windows Programme in Assembler

... sind meiner Meinung nach durchaus möglich. Dazu wären aber viel mehr 
Investments in verwendbaren Funktionscode und angepaßte Tools nötig. Es 
gibt in meinen Augen keinen technischen Grund, warum man 
Asm-Programmierung für Windows nicht genauso komfortabel machen könnte 
wie heutzutage mit dem objektorientierten abstrakten Zeug...

Takao K. schrieb:
> Auch C kann schon ganz gut optimiert werden, bis zu Faktor 10.

Nenn alle Faktoren die Du willst. Cleveres Asm, mit dem der 
Programmierer die tatsächliche Hardware richtig ausnutzt, holt das 
C-Geraffel niemals ein.

Takao K. schrieb:
> und es bei Licht
> betrachtet Erbsenzaehlerei und Murks war.

Na tut mir leid für Dich. Ich progge so seit 20 Jahren und werds 
vermutlich auch die nächsten 20 tun ;-)

Takao K. schrieb:
> Ja kauf dir einen PIC mit 512K und mach es dein Lebenswerk dafuer ein
> Assemblerprogramm zu schreiben welches den Speicher wirklich voll
> ausnutzt.

Möglichst wenig Speicher, möglichst kleine MCs sind das Ziel!
Und nur mit Asm auch wirklich erreichbar ;-)

Takao K. schrieb:
> Weil Assy tot ist, und weil viele schon seit mehr als 10 Jahren nix mehr
> davon halten.

... nix mehr davon verstehen und leider keinen Schimmer davon haben was 
da sinnlos verbraten wird. Nun ja, dann muß eben die Hardware das 
Defizit ausgleichen.

Takao K. schrieb:
> Und bei Mikrocontrollers zieht das jetzt
> auch ein, also speichermanagement, und Application layers.

Die kannst Du ja gerne verwenden (müssen?)...

Takao K. schrieb:
> oder was mit
> Tricks und Taktzyklen zaehlen?

Ich muß in den seltensten Fällen Taktzyklen und Codesize zählen... Denn 
die optimalen Werte stellen sich meist von ganz alleine ein ;-)

Es macht halt einen Unterschied, ob man eine Kaffee-Maschine ohne 
Internet programmieren will oder Feature-Produkte mit immer kürzeren 
Produktzyklen...

Wer immer größere Projekte stemmen will, der wird sich irgendwann ein 
gleichförmiges Muster aneignen, damit er mit seinem Geist eine Ebene 
nach oben wandern und Zusammenarbeit in großen Teams überhaupt erst 
möglich machen kann (Weniger Spezialfälle = weniger kognitive Last, 
weniger Kommunikation).
Genau das macht man mit dem C-Compiler. Und der C-Compiler hat im 
Prinzip alle Möglichkeiten, das umzusetzen, was der 
Assembler-Programmierer per Hand machen würde (solange die 
Compiler-Schreiber sich Mühe geben und natürlich nur bis an die Grenzen 
der InterOp-Spefizifizierung). Viele Optimierungsprobleme sind zudem 
NP-vollständig, da hat der schnellere Ausprobierer (=Compiler) die 
größere Wahrscheinlichkeit, eine (nahezu) optimale Lösung zu finden.
Ich würde soweit gehen und sagen: für jeden Trick, den der kleine 
Assembler-Programmierer in seiner Kammer in stundenlanger Mühe 
erarbeitet, könnte man eine Compiler-Direktive erzeugen, die das ganze 
eine Million Mal schneller und noch 10x besser umsetzt.
Statt also über die Compiler zu jammern, sollter der kleine 
Assembler-Programmierer lieber mithelfen, den Compiler verbessern. 
Schließlich hat der Assembler-Programmierer ja das programmieren 
angefangen, um mithilfe von Software und Hardware manuelle 
Arbeitsschritte zu automatisieren, oder gewisse zeitkritische Dinge 
überhaupt erst möglich zu machen. Ich verstehe nicht, warum er da auf 
der (Meta-)Ebene seiner eigenen Arbeit Halt macht.

Aber trotzdem hat es natürlich seinen Charme, selber Compiler zu 
spielen, genauso wie Leute immernoch stricken, obwohl es dafür 
abgefahrene Maschinen gibt, die tausende Male schneller sind und 
"bessere" Ergebnisse erzielen.

Viele Grüße!

BastiDerBastler schrieb:
> Es macht halt einen Unterschied, ob man eine Kaffee-Maschine ohne
> Internet programmieren will oder Feature-Produkte mit immer kürzeren
> Produktzyklen...

Stimmt. Die Anwendung gibt den Rahmen für die optimale Lösung vor.

> Wer immer größere Projekte stemmen will...

kann das auch in Asm. Eine gewisse Systematik und Vorarbeit 
vorausgesetzt.

> und Zusammenarbeit in großen Teams überhaupt erst
> möglich machen kann (Weniger Spezialfälle = weniger kognitive Last,
> weniger Kommunikation).

Asm stellt sich da nicht in den Weg.

> Ich würde soweit gehen und sagen: für jeden Trick, den der kleine
> Assembler-Programmierer in seiner Kammer in stundenlanger Mühe
> erarbeitet, könnte man eine Compiler-Direktive erzeugen, die das ganze
> eine Million Mal schneller und  noch 10x besser umsetzt.

Na was für ein schöner Traum!

> Statt also über die Compiler zu jammern, sollter der kleine
> Assembler-Programmierer lieber mithelfen, den Compiler verbessern.

Das kann ja gerne tun wer will-
Wer die vollständige Kontrolle über MC und Code für real suboptimale 
Ergebnisse abgeben will- bitteschön.

> angefangen, um mithilfe von Software und Hardware manuelle
> Arbeitsschritte zu automatisieren, oder gewisse zeitkritische Dinge

Asm, automatisierte Abläufe und erst recht zeitkritische Dinge schließen 
sich nicht aus.

> Ich verstehe nicht, warum er da auf
> der (Meta-)Ebene seiner eigenen Arbeit Halt macht.

Weil die einfach optimale Ergebnisse mit minimalem Organisations- und 
Syntaxaufwand bringt. Die Anstrengung lohnt besonders dann, wenn man 
sich leistungsmäßig auf bestimmte Hardware für alle denkbaren 
Einsatzfälle beschränken und seine Codebasis darauf perfekt abstimmen 
kann. Dann ist nämlich auch der Zeitvorteil, den bequemliche 
Hochsprachenprogrammierung für gewöhnlich bringt dahin.

Sehr diplomatisch, Chris.
Aber schon der erhebliche Taktzyklusunterschied zwischen C und Asm bei 
leerem Interrupt ist leider alles andere als nur Bastlersicht und 
bedeutet allgemein für den C Code Speed bestimmt nichts gutes ;-)

Eine leere Interrupt Routine ist meisten sinnlos. Der C Compiler erzeugt 
den minimalen Rahmen, in den C Code eingefügt werden kann. Ganz egal, 
was deine Interrupt Rotuine macht, diese Register müssen gesichert 
werden.

Nur beim Sonderfall (leere Interruptroutine) erzeugt der Compiler 
auffällig schlechten Code.

Peter Dannegger schrieb:
> Das Zyklen knausern ist in der Regel nicht notwendig

Hier knausert zunächst mal niemand (das Pulver kann für wirklich 
kritische Fälle trocken bleiben), aber ich bestreite daß

> Nur beim Sonderfall (leere Interruptroutine) erzeugt der Compiler
> auffällig schlechten Code.