Moby A. schrieb:> Nun, zur Güte hatte ich doch längst schon zugestanden, es langt, die> beschriebene Programmfunktion = den Output nachzubilden.
Nein, das genügte dir nicht, denn du hast noch Bedingungen an
Speicher- oder Registerbenutzung aufgestellt. Auch die Bedingung,
dass partout alles in der ISR abgehandelt werden muss, passt nicht
zu dieser eben von dir gemachten Aussage: wenn es nur um ein Gerät
gänge, welches “plug compatible” ist, muss man nicht solche
Bedingungen aufstellen.
Johann L. schrieb:> Programmierer aller Kontinente, verneigt euch vor Moby!
Statt lustiger Sprüche stelle lieber Dein Talent unter Beweis!
Matthias L. schrieb:> Das Wichtigste fehlt wieder: Die Entwicklungszeit. Zumindest für alle> ausser Dir.
Haben wir damit schon die ersehnte Ausrede gefunden?
Mir geht darum, was C im Controller zu leisten imstande ist.
Entwicklungszeit ist übrigens, zumindest in dieser Größenordnung hier,
was höchst Individuelles. Ich sage nur Übung, Vorbereitung, System ;-)
Moby A. schrieb:> Selbst das ist für C zu hoch, wenn Flash/Ram-Bedarf> meines Programms getoppt werden soll.
Hast du denn ein Beispiel, wo die von dir angepriesenen Vorteile
dergestalt zum tragen kommen, dass es UNMÖGLICH ist, C zu verwenden,
ohne dass es MERKLICHE oder INAKZEPTABLE EINBUSSEN DER FUNKTIONALITÄT
gibt?
Jörg W. schrieb:> Nein, das genügte dir nicht, denn du hast noch Bedingungen an> Speicher- oder Registerbenutzung aufgestellt. Auch die Bedingung,> dass partout alles in der ISR abgehandelt werden muss, passt nicht> zu dieser eben von dir gemachten Aussage: wenn es nur um ein Gerät> gänge, welches “plug compatible” ist, muss man nicht solche> Bedingungen aufstellen.
Hatte ich das nicht eben klargestellt?
Liest Du was ich schreibe?
Moby:
> Hatte ich das nicht eben klargestellt?
Doch! Im Läufe der Zeit schon x-mal und mindestens x-1 mal wieder
zurückgenommen. Alle hätten sich hier auf "Fakten" gefreut. Das sind die
Dinge, die "feststehen". "Variable Fakten" gibt es nicht.
Johann L. schrieb:> Hast du denn ein Beispiel, wo die von dir angepriesenen Vorteile> dergestalt zum tragen kommen, dass es UNMÖGLICH ist, C zu verwenden,> ohne dass es MERKLICHE oder INAKZEPTABLE EINBUSSEN DER FUNKTIONALITÄT> gibt?
C zu verwenden ist natürlich genauso unbeschränkt möglich wie den
32-Bitter für die Blinkschaltung... Die Frage ist aber: Gehts nicht noch
eine Nummer kleiner und simpler? Das Tandem ASM/AVR macht das sehr oft
möglich!
Aus meiner persönlichen Abneigung gegen C mache ich hingegen keinen
Hehl.
Mir ist das zu sperrig, zu aufgeblasen, zu umständlich, zu komplex und
fehlerträchtig in seiner Ausdrucksfähigkeit. Viel zu viel Bürokratie für
oft ganz einfache MSR-Tatbestände. Kryptisches Theater um Typen,
Operatoren und Gültigkeitsbereiche. Darüber könnte ich hier endlos
streiten.
Also: Unmöglich ist nichts. Nur, wenn man sich schon auf Hochsprachen
einlässt muß man sich auch im klaren sein, daß alles seinen Preis hat.
Wie schrieb schon der der große
c-hater im Beitrag #4361484 ?
> Das mußt du begreifen. Mit C läßt du immer Potential der Hardware> brach liegen. Der Fluch der Abstraktionen.
Um verschenktes Potential meiner AVRs tut's mir besonders leid ;-)
Moby A. schrieb:> Die Frage ist aber: Gehts nicht noch> eine Nummer kleiner und simpler? Das Tandem ASM/AVR macht das sehr oft> möglich!LEDs kann ich auch mit einem NE555 blinken lassen.
Klaus W. schrieb:> LEDs kann ich auch mit einem NE555 blinken lassen.
Hey, da hat einer das Prinzip verstanden!!!
Carl D. schrieb:> Doch! Im Läufe der Zeit schon x-mal und mindestens x-1 mal wieder> zurückgenommen. Alle hätten sich hier auf "Fakten" gefreut. Das sind die> Dinge, die "feststehen". "Variable Fakten" gibt es nicht.
So, Du wirst mir jetzt erläutern was an
Moby A. schrieb:> hatte ich doch längst schon zugestanden, es langt, die> beschriebene Programmfunktion = den Output nachzubilden.
noch unklar ist!
Das Ganze bitte mit weniger Flash und gleichviel RAM
(oder umgekehrt ;-)
Auf gehts, Carl D.
Zeig mal, daß Du Probleme auch nichtpolemisch lösen kannst ;-)
Da sich hier die Argumente nur noch seitenlang wiederholen und das Thema
längst nichts mehr mit dem ursprünglichen Thema der TIOBE-"Studie" zu
tun hat, plädiere ich dafür, diesen Thread zu schließen.
Moby-ASM hat nichts mit TIOBE zu tun.
Klaus W. schrieb:> Ich schon, nur du nimmst dafür einen AVR mit ASM!
Nö. Immer das Einfachste!
Frank M. schrieb:> plädiere ich dafür, diesen Thread zu schließen.
Bin ich gerührt wie sehr Dir meine Threads am Herzen liegen ;-)
Im Ergebnis hast Du aber ausnahmsweise recht- rauskommen wird nix mehr.
Für die C-Lösung kann mein entsprechender Projekt-Thread genutzt werden.
Stimmts, Frank M? ;-)
Moby A. schrieb:> P. M. schrieb:>> die Frechheit, so zu tun,>> ... daß mein Programm nach wie vor die Überlegenheit von Asm> dokumentiert!
Und schon wieder: Ohne mit der Wimper zu zucken behauptest du wieder
etwas, das im Thread längst widerlegt wurde. Das ist nun wirklich
Bullshitting in Reinform und ohne jegliche Hemmungen.
P. M. schrieb:> Ohne mit der Wimper zu zucken behauptest du wieder> etwas, das im Thread längst widerlegt wurde.
Ohne mit der Wimper zu zucken behauptest Du etwas, was mangels
Gegenbeispiel noch lange nicht widerlegt wurde. Ohne jegliche
Hemmungen... Deine Diskussionstechnik nennt man "Bullshitting": Eine
Aussage selbst dann immer und immer wieder vorbringen, wenn völlig klar
ist, dass sie falsch ist oder nicht begründet werden kann. Leute, Leute,
manchmal frag ich mich, wo bin ich hier hingeraten ;-)
Wolfgang R. schrieb:> Warum bist Du dann noch hier? Kanns ja ganz flott wieder raus> geraten...>> Die Diskussion ist sowas von sinnfrei, ich bekomme da keinen OrgASM...
Da hast Du recht. Im Augenblick reichts ;-)
Schönen Abend noch.
Moby A. schrieb:> ... daß mein Programm nach wie vor die Überlegenheit von Asm> dokumentiert!
Daß das nichts als dummes Gelaber ist, hat Yalu bereits eindeutig
bewiesen:
Beitrag "Re: C versus Assembler->Performance"
Assembler ist C also sogar nach Deinen Kriterien klar unterlegen, mehr
muß man über Dich, Dein "Können" und Dein "Urteilsvermögen" nicht
wissen. Das macht Dein Gelaber so witzig. Bei dem Wetter ist das genauso
lustig, aber viel angenehmer als draußen mit Jehovas Zeugen zu,
"diskutieren". :-)
Sheeva P. schrieb:> Daß das nichts als dummes Gelaber ist, hat Yalu bereits eindeutig> bewiesen:
Schon bemerkenswert.
Da wird der Kollege Moby mal so richtig vorgeführt.
Nach allen Regeln der Kunst wird sein Code besiegt.
Weniger Features, höherer Ressourcenverbrauch, unleserlich und
unportabel.
Nicht ein, mindestens 2 blaue Augen fängt er sich ein.
Und trotzdem fühlt er sich noch immer als Sieger und tut dies überall
kund.
Das ist mal ein gesundes Selbstbewusstsein ;-)
Moby A. schrieb:> Mir ist das zu sperrig, zu aufgeblasen, zu umständlich, zu komplex und> fehlerträchtig in seiner Ausdrucksfähigkeit. Viel zu viel Bürokratie für> oft ganz einfache MSR-Tatbestände. Kryptisches Theater um Typen,> Operatoren und Gültigkeitsbereiche. Darüber könnte ich hier endlos> streiten.
Das ist deine Umschreibung dafür, dass du keine Ahnung von C hast. Vor
diesem Hintergrund kannst du nicht über die Vor/Nachteile von C vs. Asm
dikutieren.
Du schiest dich immer öfter selber ab. Merkst du das nicht?
Gu. F. schrieb:> Moby A. schrieb:>> Mir ist das zu sperrig, zu aufgeblasen, zu umständlich, zu komplex und>> fehlerträchtig in seiner Ausdrucksfähigkeit. Viel zu viel Bürokratie für>> oft ganz einfache MSR-Tatbestände. Kryptisches Theater um Typen,>> Operatoren und Gültigkeitsbereiche. Darüber könnte ich hier endlos>> streiten.>> Das ist deine Umschreibung dafür, dass du keine Ahnung von C hast.
Es ist ebenfalls seine Umschreibung dafür, dass er noch nie irgendetwas
größeres programmiert hat. Das werfe ich ihm nicht vor. Was ich ihm
vorwerfe, das ist, dass er dann nicht so tun soll, als ob das alles
einfach linear hochskaliert. Denn das tut es nicht, wie jeder der
beruflich programmiert aus leidvoller Erfahrung zu berichten weiss.
Auf diesem Ohr ist er allerdings taub, wie seine konsequente Weigerung
ein etwas größeres Projekt im Vergleich anzugehen, eindeutig beweist.
Moby A. schrieb:> Aus meiner persönlichen Abneigung gegen C mache ich hingegen keinen> Hehl.> Mir ist das zu sperrig, zu aufgeblasen, zu umständlich, zu komplex und> fehlerträchtig in seiner Ausdrucksfähigkeit. Viel zu viel Bürokratie für> oft ganz einfache MSR-Tatbestände. Kryptisches Theater um Typen,> Operatoren und Gültigkeitsbereiche. Darüber könnte ich hier endlos> streiten.
Was ist an
1
uint8_t meineVariable;
bitteschön kryptisch? Das Semikolon?
Ist doch perfekt: ich teile dem Compiler nur kurz mit, dass ich einen
8-Bit-Signed Wert haben will. Oder einen 16-Bit Unsigned.
Oderoderoder...
Sonderbehandlungen übernimmt dann immer der Compiler, und zwar an jeder
Stelle, an der meineVariable benutzt wird.
Toll oder?
Bei einem Signed-Wert wird das Vorzeichen berücksichtigt. Bei einem
16-Bit Wert werden 2 Register allokiert und z.B. bei einer Addition
nicht nur add, sonder auch adc-Code erzeugt.
Sehr bequem.
Du, mein lieber Moby, hast in deinem ASM-Code auch Datentypen (OK,
zugegeben, du nicht. Du hast nur 8-Bit-Unsigned, alles andere ist viel
zu komplex und wird auf dedizierte Hardware ausgelagert. Aber andere
ASM-Programmierer kennen Datentypen).
Dein Datentyp taucht natürlich nicht im Code auf. Bei dir steht
nirgendwo "uint16_t" oder Ähnliches.
Du merkst dir den Datentyp im Kopf. Du schleppst ihn also implizit immer
mit dir rum, ob du das möchtest oder nicht.
Und jedesmal wenn mit einem Register gerechnet werden soll musst du von
Neuem entscheiden wie du vorgesht.
Ob ein Carry für den Vergleich berücksichtigt werden soll.
Ob du mehrere Register allokieren musst....
Und wehe, wehe, der Datentyp ändert sich weil du beim Entwickeln deiner
MSR-Applikation feststellst dass der Wertebereich bei der benötigten
Auflösung nicht ausreicht...
Das das Fehlerträchtig ist hast du bereits kennen lernen dürfen.
Da ist mir mein kryptisches
1
uint8_t meineVariable;
schon lieber, denn damit ist die Sache gegessen.
Nächstes Stichwort: Operatoren
Du findest es kryptisch, zwei Variablen mittels "==" vergleichen zu
können? Völlig unabhängig vom Datentyp? Wow. Da fällt mir echt nichts
mehr ein.
Aber wir wissen ja alle hier dass deine Abneigung gegen C, und
wahrscheinlich deine Vorliebe für dein AVR-ASM einzig daher rührt dass
deine bisherigrn kurzen C-Versuche gescheitert sind.
Im Übrigen würde ich dich bitten nie, NIE wieder von MSR-Anwendungen zu
faseln.
Denn R-Anwendungen sind mit 8-Bit-Unsigned-Arithmetik einfach nicht zu
handeln.
Richtiges "R" fordert oft anspruchsvolle Mathematik.
Bitte benutze also in Zukunft nur noch den Ausdruck "MS-Applikation",
schon aus Respekt vor richtigen Regelungstechnikern.
le x. schrieb:> Dein Datentyp taucht natürlich nicht im Code auf. Bei dir steht> nirgendwo "uint16_t" oder Ähnliches.
In der Intel/Microsoft Notation des 8088 Assembler hätte er auch
deklarierte Datentypen. Da hängt es von der Deklaration einer Variablen
im Speicher ab, ob
add mem, 1
eine 8- oder 16-Bit Operation ist. Und wenn es daraus nicht hervorgeht,
dann hat man so Schönheiten wie
add word ptr [di], 1
an der Backe.
A. K. schrieb:> In der Intel/Microsoft Notation des 8088 Assembler hätte er auch> deklarierte Datentypen
Wobei dieser Assembler für Moby wohl genauso ein Feindbild darstellt wie
C oder Hochsprachen generell.
Moby mag nur AVR-ASM.
Nicht weil es so toll ist, sondern weil es das einzige ist was er kann
:-)
Das müsste eine ziemliche 1:1 Umsetzung des fraglichen Assembler Codes
sein.
Uns wie man sieht wird hier etwas zu oft mit dem ADC gemessen. Soviel
zum Thema Zeit sparen. Und die Checksumme. Na ja. Ist halt ein Alibi
einer Checksumme.
le x. schrieb:> Dein Datentyp taucht natürlich nicht im Code auf. Bei dir steht> nirgendwo "uint16_t" oder Ähnliches.> Du merkst dir den Datentyp im Kopf. Du schleppst ihn also implizit immer> mit dir rum, ob du das möchtest oder nicht.> Und jedesmal wenn mit einem Register gerechnet werden soll musst du von> Neuem entscheiden wie du vorgesht.> Ob ein Carry für den Vergleich berücksichtigt werden soll.> Ob du mehrere Register allokieren musst....> Und wehe, wehe, der Datentyp ändert sich weil du beim Entwickeln deiner> MSR-Applikation feststellst dass der Wertebereich bei der benötigten> Auflösung nicht ausreicht...> Das das Fehlerträchtig ist hast du bereits kennen lernen dürfen.
Deine Argumente sehe ich jetzt schon damit vom Tisch gewischt.
Moby A. schrieb:> Ich sage nur Übung, Vorbereitung, System ;-)
Natürlich nicht ohne ein albernes Zwinkern am Satzende.
> bitteschön kryptisch? Das Semikolon?>> Ist doch perfekt: ich teile dem Compiler nur kurz mit, dass ich einen> 8-Bit-Signed Wert haben will. Oder einen 16-Bit Unsigned.> Oderoderoder...
Das kannst du doch jemandem nicht vermitteln, der
1
ldi r16,$e0
2
out ADCSRA,r16
für guten Stil hält und nicht versteht, was daran eigentlich das Problem
ist, bzw. wie man es behebt obwohl es ihm überhaupt keine Laufzeit
kosten würde.
> Im Übrigen würde ich dich bitten nie, NIE wieder von MSR-Anwendungen zu> faseln.> Denn R-Anwendungen sind mit 8-Bit-Unsigned-Arithmetik einfach nicht zu> handeln.> Richtiges "R" fordert oft anspruchsvolle Mathematik.> Bitte benutze also in Zukunft nur noch den Ausdruck "MS-Applikation",> schon aus Respekt vor richtigen Regelungstechnikern.
Wo kann man die Petition unterschreiben? :-)
Moby A. schrieb:> Mir ist das zu sperrig, zu aufgeblasen, zu umständlich, zu komplex und> fehlerträchtig in seiner Ausdrucksfähigkeit. Viel zu viel Bürokratie für> oft ganz einfache MSR-Tatbestände. Kryptisches Theater um Typen,> Operatoren und Gültigkeitsbereiche.
Kryptisch? Stellen wir uns ein kleines C-Programm vor, das vom ADC
liest, einen Mittelwert über die letzten 8 Werte bildet und sobald
dieser Mittelwert eine bestimmte Schwelle überschreitet, blinkt kurz
eine LED und der Mittelwert wird übers UART gesendet.
Ich bin nicht mehr so fit in AVR-Registern, deshalb verwende ich
symbolisch erfundene Register, was aber keinen Unterschied macht:
1
voidmain(){
2
3
uint8_tthreshold=89;
4
5
uint8_tvalue_ptr=0;
6
uint8_tlast_values[8]={0,0,0,0,0,0,0,0};
7
8
ADC_CONFIG|=(1<<ADC_ON);
9
UART_CONFIG=...;// set some bits here
10
11
12
while(true){
13
if(ADC_STATUS&(1<<ADC_HAS_NEW_VALUE)){
14
15
// save value into ringbuffer
16
last_values[value_ptr]=ADC_VALUE;
17
18
// increase ringbuffer pointer
19
value_ptr++;
20
value_ptr=(value_ptr<5)?value_ptr:0;
21
22
// sum up values in ringbuffer
23
uint16_tsum=0;
24
for(uint8_ti=0;i<8;i++){
25
sum+=last_values[i];
26
}
27
28
// check if average in ringbuffer exceeds threshold
29
// if yes, send over uart
30
if(sum/8>threshold){
31
UART_DATA=sum/8;
32
UART_CONFIG|=(1<<UART_DO_SEND);
33
}
34
35
}
36
}
37
}
Ich denke, das ist sehr typisches 8-Bit-MS(R). Könntest du das jetzt
bitte mal in kurzen, kompakten, übersichtlichen Assembler-Code
umwandeln?
P. M. schrieb:> Kryptisch? Stellen wir uns ein kleines C-Programm vor, das vom ADC> liest, einen Mittelwert über die letzten 8 Werte bildet und sobald> dieser Mittelwert eine bestimmte Schwelle überschreitet, blinkt kurz> eine LED und der Mittelwert wird übers UART gesendet.> Könntest du das jetzt bitte mal in kurzen, kompakten, übersichtlichen> Assembler-Code umwandeln?
Vermutlich ist da zu viel Mathematik drin, daher wird Moby das Angebot
nicht wahrnehmen wollen ;-)
Wegstaben V. schrieb:> Vermutlich ist da zu viel Mathematik drin, daher wird Moby das Angebot> nicht wahrnehmen wollen ;-)
Vergleiche jenseits von 8 Bits sind nicht seine starke Seite:
if(sum / 8 > threshold){
Wegstaben V. schrieb:> Vermutlich ist da zu viel Mathematik drin, daher wird Moby das Angebot> nicht wahrnehmen wollen ;-)
Er wartet noch auf die Controler-Version mit dem AVR-Befehl. AVR wie
average. Nur so ist das kompakt lösbar.
Wegstaben V. schrieb:> Vermutlich ist da zu viel Mathematik drin, daher wird Moby das Angebot> nicht wahrnehmen wollen ;-)
Vermutlich eher keine typische 8-bit MSR Anwendung...
P. M. schrieb:> Korrigierte Aufgabenstellung für Moby:
Ich glaube nicht dass da was draus wird, wegen ...
Moby A. schrieb:> P. M. schrieb:>>> C:template <class T>>> T max(T a, T b){>> return (a > b) ? a : b;>> }>> Das ist kryptischer Kauderwelsch für Eingeweihte.> Dessen Studium ist für 8-Bit MSR überflüssig ;-)
P. M. schrieb:> value_ptr %= 8;
Sorry, ich bin immer noch bei PIC ;-) hab gerade ausprobiert was der
sehr schwach optimierende XC8 (free mode) aus der zitierten Zeile macht:
1
0x7FF8:MOVLW0x7
2
0x7FFA:ANDWF__pcstackCOMRAM,F,ACCESS
Wow, zwei Assemblerbefehle für eine Modulo Operation. Auf den Trick muss
man als Assemblist erst mal kommen.
Witkatz :. schrieb:> Auf den Trick muss man als Assemblist erst mal kommen.
Assemblerprogrammierer kennen keinen Modulus, die kennen nur AND und
Bitmasken. ;-)
Witkatz :. schrieb:> Wow, zwei Assemblerbefehle für eine Modulo Operation. Auf den Trick muss> man als Assemblist erst mal kommen.
Ja, Aber nur weil
x % 2^n = x & 2^n-1
ist.
Witkatz :. schrieb:> P. M. schrieb:>> value_ptr %= 8;> Wow, zwei Assemblerbefehle für eine Modulo Operation. Auf den Trick muss> man als Assemblist erst mal kommen.
Wieso? Das machen Compiler schon seit Jahrzehnten, wenn sie eine
Zweierpotenz erkennen.
Modulo 8 ist nichts als der Rest einer Division durch 8. Eine Division
durch 8 entspricht Schieben um 3 Stellen, damit entspricht Modulo 8
einer Maskierung der letzten 3 Stellen.
Man hätte also auch schreiben können:
1
value_ptr&=0x07;
Nichts anderes hat der Compiler in Assembler hingeschrieben.
Witkatz :. schrieb:> Wow, zwei Assemblerbefehle für eine Modulo Operation. Auf den Trick muss> man als Assemblist erst mal kommen.
Triviale Grundübung. Interessant wirds erst mit Vorzeichen.
Frank M. schrieb:> Modulo 8 ist nichts als der Rest einer Division durch 8. Eine Division> durch 8 entspricht Schieben um 3 Stellen, damit entspricht Modulo 8> einer Maskierung der letzten 3 Stellen.
Aber nur ohne Vorzeichen.
A. K. schrieb:> Aber nur ohne Vorzeichen.
Ja, natürlich.
P.S.
Genialer als diese Modulo-Sache finde ich übrigens, wie der gcc eine
Multiplikation mit 80 löst (auf welchem Prozessor ich das gesehen habe,
weiß ich nicht mehr, ist über 20 Jahre her):
1
y = x * 80
2
<==> y = x * (64 + 16)
3
<==> y = x * 64 + x * 16
4
<==> y = (x << 6) + (x << 4)
Der Compiler zerlegt die Zahl also in Zweierpotenzen und addiert einfach
die jeweiligen geschobenen Ergebnisse. Sowas lohnt sich aber nur auf
Prozessoren, die von Haus aus nicht multiplizieren können.
Frank M. schrieb:> Der Compiler zerlegt die Zahl also in Zweierpotenzen und addiert einfach> die jeweiligen geschobenen Ergebnisse. Sowas lohnt sich aber nur auf> Prozessoren, die von Haus aus nicht multiplizieren können.
Zumindest nicht kombinatorisch. Bei Prozessoren mit per Sequencer oder
Microcode implementierter Multiplikation lohnt sich das schon. Das
gehört zu jenen Optimierungen, die einem Asm-Programmierer recht viel
Arbeit machen - und mit jeder Änderung der Konstanten komplett neu. Die
fortgeschrittene Version verwendet übrigens nicht nur Additionen sondern
auch Subtraktionen.
>Mit "Übung, Vorbereitung und System" braucht man ohnehin keine>Vorzeichen :-D
ASM (selbst) kennt kein Vorzeichen. Somit existiert das Problem
"Vorzeichen" nur in den kryptischen, aufgeblasenen Hochsprachen.
;-)
Chris B. schrieb:> Mit "Übung, Vorbereitung und System" braucht man ohnehin keine> Vorzeichen :-D
Moby rechnet Temperaturen vermutlich in Fahrenheit. Das reicht von
Saukalt bis Kaffee in 8 Bits ohne Vorzeichen.
Frank M. schrieb:> Wieso? Das machen Compiler schon seit Jahrzehnten, wenn sie eine> Zweierpotenz erkennen.
Ich find's nur gut, dass die Compiler solche Gesetzmäßigkeiten erkennen
und entspr. optimieren.
Frank M. schrieb:> Man hätte also auch schreiben können: value_ptr &= 0x07;
Ist zwar formal richtig, aber die Modulooperation gehört zu
Ringbufferhandling dazu - die Verundung verschlechter die Lesbarkeit.
Lieber würde ich die 8 durch eine symbolische Konstante ersetzen. Dann
muss ich nur ein #define anpassen und schon ist der MovingAverageFilter
angepasst. Der Compiler macht den mühsamen Rest...
Witkatz :. schrieb:> Lieber würde ich die 8 durch eine symbolische Konstante ersetzen.
Ja, das ist in dem Beispiel ungünstig. Das müsste im Code zB sizeof
sein.
Aber ich wollte das 8 => 19 dann als Erweiterung vorschlagen, damit Moby
alles neu schreiben darf.
A. K. schrieb:> Das> gehört zu jenen Optimierungen, die einem Asm-Programmierer recht viel> Arbeit machen - und mit jeder Änderung der Konstanten komplett neu.
Eben: Während der C-Programmierer einfach
1
#define COLS_PER_ROW 80
durch
1
#define COLS_PER_ROW 132
ersetzt, muss der Assembler-Programmierer die komplette Plutimikation
neu schreiben.
> Die fortgeschrittene Version verwendet übrigens nicht nur> Additionen sondern auch Subtraktionen.
Hehe :-)
Witkatz :. schrieb:> Lieber würde ich die 8 durch eine symbolische Konstante ersetzen. Dann> muss ich nur ein #define anpassen und schon ist der MovingAverageFilter> angepasst. Der Compiler macht den mühsamen Rest...
Ja, siehe oben.
Matthias L. schrieb:> ASM (selbst) kennt kein Vorzeichen.
Die meisten schon. Eigentlich müsste Intels 8048 sein Ideal sein, denn
da gibts weder Vorzeichenabfrage noch Overflow-Flag. Schon der 8051
fällt aufgrund des fatalen Overflow-Flags aus.
Auch RCA 1802 kommt aus dem gleichen Grund diesem Ideal nahe, scheitert
aber angesichts von 16 16-Bit Registern für die Adressierung an der kaum
vermeidbaren Notwendigkeit zur byteweisen 16-Bit Rechnung bei Adressen.
Frank M. schrieb:> Eben: Während der C-Programmierer einfach> #define COLS_PER_ROW 80> durch> #define COLS_PER_ROW 132>> ersetzt,
oder einfach die komplette MovinAvg geschichte durch z.B.
AdcSmooth = (AdcSmooth * 7 + ADC_VALUE) / 8;
und schwupsdiwups probiert er einen anderen Filter mal eben aus ;-)
Karl H. schrieb:> ob Moby das trivial Optimierungspotential erkennt
Wieso? Ich dachte, dass einfache Digitalfilter zu einfacher MSR dazu
gehören, oder etwa nicht?
Ich bin echt gespannt, wie sich Moby dieses Mal herausredet. Das
Beispiel ist nun wirklich einfachst und perfekt geeignet, um die
Überlegenheit von Assembler zu demonstrieren.
Witkatz :. schrieb:> oder einfach die komplette MovinAvg geschichte durch z.B.> AdcSmooth = (AdcSmooth * 7 + ADC_VALUE) / 8;> und schwupsdiwups probiert er einen anderen Filter mal eben aus ;-)
1
ld a, (adcsmooth)
2
ld b, a
3
add a
4
ld c, a
5
add a
6
add b
7
add c
8
ld hl, adc_value
9
ld b, (hl)
10
add b
11
and a
12
rr a
13
and a
14
rr a
15
ld (adcsmooth), a
Ist doch ganz einfach, und sofort klar und verständlich. :-)
Frank M. schrieb:> Geradezu selbstdokumentierend :-)
Aber sicher. Manche Maschinen besitzen keine Befehle für Laden/Speichern
von Datenworten - ja, auch heute noch! Also weder solche Befehle, noch
als implizite Speicheroperanden von Datenbefehlen. Da wird es schon
interessant, überhaupt die Speicherzugriffe zu finden, denn die gibt es
natürlich trotzdem.
Witkatz :. schrieb:> Karl H. schrieb:>> ob Moby das trivial Optimierungspotential erkennt>> Wieso? Ich dachte, dass einfache Digitalfilter zu einfacher MSR dazu> gehören, oder etwa nicht?
Natürlich.
Aber dein Originalcode hat noch Potential.
In C trivial zu ändern.
(Nein, ich sag jetzt noch nicht wie. Aber es hat mit der Summe zu tun.
Denk mal über S-= Wert; S += Wert; nach)
le x. schrieb:> Im Übrigen würde ich dich bitten nie, NIE wieder von MSR-Anwendungen zu> faseln.> Denn R-Anwendungen sind mit 8-Bit-Unsigned-Arithmetik einfach nicht zu> handeln.> Richtiges "R" fordert oft anspruchsvolle Mathematik.> Bitte benutze also in Zukunft nur noch den Ausdruck "MS-Applikation",> schon aus Respekt vor richtigen Regelungstechnikern.Karl H. schrieb:> Wo kann man die Petition unterschreiben?
Damit tut ihr ihm wirklich Unrecht. Selbstverständlich sind seine
Anwendungen MSR-Anwendungen. Das gilt für alle seine Anwendungen. Ihr
befindet euch in einem grossen Irrtum. Denn MSR steht nicht für das,
wovon ihr glaubt, wofür es steht.
MSR heisst:
M oby
S part
R AM
mfg.
Jörg W. schrieb:> Mensch, Karl Heinz, das war doch die Sollbruchstelle für Mobi. :-)>> Nee, hatte ich natürlich vergessen, hast recht.
:-)
Da lob ich mir halt C.
Da schreibe ich / 8 und der Compiler kümmert sich drum, wie oft
verschoben werden muss. Am Anfang hat mich ja auch dein AND
verunsichert, bis ich erkannte warum. Allerdings könntest du da auch 2
mal ein AND einsparen :-)
Macht sicherlich jeder Compiler problemlos. Nur wenn man es händisch
macht, muss man sich darum kümmern.
Aber gottlob ist mein 8080 Assembler noch nicht so eingerostet, dass ich
es nicht hätte lesen können.
Karl H. schrieb:> Allerdings könntest du da auch 2 mal ein AND einsparen :-)
Nö, beim Rotieren nach rechts wird ja das Carry-Flag wieder befüllt,
man muss es daher wieder löschen.
> Aber gottlob ist mein 8080 Assembler noch nicht so eingerostet, dass ich> es nicht hätte lesen können.
Sach ich doch, klarer, schöner und völlig selbsterklärender
Assembler-Code. Es gibt nichts besseres. :-))
Jörg W. schrieb:> Karl H. schrieb:>> Allerdings könntest du da auch 2 mal ein AND einsparen :-)>> Nö, beim Rotieren nach rechts wird ja das Carry-Flag wieder befüllt,> man muss es daher wieder löschen.
Aber du weisst wo die 2 (äh 3) Bits im Akku landen und kannst sie
hinterher ausmaskieren, sollte da tatsächlich eine 1 aus dem Carry
reingekommen sein.
Karl H. schrieb:> Aber du weisst wo die 2 (äh 3) Bits im Akku landen und kannst sie> hinterher ausmaskieren, sollte da tatsächlich eine 1 aus dem Carry> reingekommen sein.
Ah, OK. :)
Jörg W. schrieb:> Karl H. schrieb:>> Aber du weisst wo die 2 (äh 3) Bits im Akku landen und kannst sie>> hinterher ausmaskieren, sollte da tatsächlich eine 1 aus dem Carry>> reingekommen sein.>> Ah, OK. :)
Und schon hat man eine halbe Stunde an einer Codesequenz verbraten, die
jeder Compiler problemlos optimal hinkriegt :-)
Karl H. schrieb:> Und schon hat man eine halbe Stunde an einer Codesequenz verbraten, die> jeder Compiler problemlos optimal hinkriegt :-)
.. in einer Zeit, die kürzer ist als der Mausklick auf "Kompilieren"
Karl H. schrieb:> Und schon hat man eine halbe Stunde an einer Codesequenz verbraten, die> jeder Compiler problemlos optimal hinkriegt :-)
Ach was! Noch ein weiteres Byte eingespart, das zählt!
Jörg W. schrieb:> Karl H. schrieb:>> Und schon hat man eine halbe Stunde an einer Codesequenz verbraten, die>> jeder Compiler problemlos optimal hinkriegt :-)>> Ach was! Noch ein weiteres Byte eingespart, das zählt!
Na das ist doch ein Argument mit dem dein Chef punkten kann, wenn er dem
Kunden die Arbeitszeit verrechnet :-)
Frank M. schrieb:> Statt immer wieder 7 + 1 = 8 Summen auszurechnen, kannst Du auch einmal> die älteste abziehen.
Achso, P.M.'s Gleitender Mittelwert war gemeint. Also etwa so?
1
AdcSum+=ADC_VALUE;
2
if(value_cnt==8){
3
AdcSum-=AdcLastValue;
4
AdcMovingAvg=AdcSum/8;
5
}elsevalue_cnt++;
6
AdcLastValue=ADC_VALUE;
Müsste RAM und zeitsparend sein im Vergleich zu der FOR Schleife mit dem
Altwertevektor.
Witkatz :. schrieb:> Frank M. schrieb:>> Statt immer wieder 7 + 1 = 8 Summen auszurechnen, kannst Du auch einmal>> die älteste abziehen.>> Achso, P.M.'s Gleitender Mittelwert war gemeint.>
1
AdcSum+=ADC_VALUE;
2
>if(value_cnt==8){
3
>AdcSum-=AdcLastValue;
4
>AdcMovingAvg=AdcSum/8;
5
>}elsevalue_cnt++;
6
>AdcLastValue=ADC_VALUE;
Nein.
So
1
while(true){
2
if(ADC_STATUS&(1<<ADC_HAS_NEW_VALUE)){
3
4
// remove oldest value from sum
5
sum-=last_values[value_ptr];
6
7
// save value into ringbuffer
8
// and add it to sum
9
last_values[value_ptr]=ADC_VALUE;
10
sum+=last_values[value_ptr];
11
12
// increase ringbuffer pointer
13
value_ptr++;
14
value_ptr%=8;
15
16
// check if average in ringbuffer exceeds threshold
17
// if yes, send over uart
18
if(sum/8>threshold){
19
UART_DATA=sum/8;
20
UART_CONFIG|=(1<<UART_DO_SEND);
21
}
wozu hast du denn das Array mit den letzten Werten? Der gerade zu
überschreibende Wert ist der jeweils älteste. Den nimmst du aus der
Summe raus und addierst den neuen dafür dazu. Auf die Art bleibt die
Summe immer ganz von alleine up to date ohne dass du jedesmal alle Werte
im Ringbuffer erneut aufsummieren musst.
>Achso, P.M.'s Gleitender Mittelwert war gemeint. Also etwa so?
Ich würds etwa so machen:
1
//-- ältesten Wert entfernen -------------------
2
AdcSum-=Buffer[BufIdx];
3
4
//-- neuen Wert in Puffer ----------------------
5
Buffer[BufIdx]=NewVal;
6
7
//-- neuen Wert zur Summe ----------------------
8
AdcSum+=Buffer[BufIdx];
9
10
//-- Idx weiterrücken --------------------------
11
BufIdx+=1;
12
BufIdx%=BUFLEN;
13
14
//-- Mittelwert berechnen ----------------------
15
AdcMovingAvg=AdcSum/BUFLEN;
Das ignoriert das Befüllen. Aber dann "schwingt" sich das eben während
der ersten BUFLEN Elemente ein...
Denn dieses if:
>>if(value_cnt == 8){
ist ja nur für den Befüllvorgang nicht erfüllt.
Karl H. schrieb:> Und schon hat man eine halbe Stunde an einer Codesequenz verbraten,
Dann bastel doch am GCC. Die sicherste Möglichkeit, dass der von dir
designte Assembler-Code nicht nutzlos verraucht, sondern x-fach bei
anderen verwendet wird :-)
Witkatz :. schrieb:> Karl H. schrieb:>> Nein.>> So ...> Ach ja sorry, mein Denkfehler. Man muss natürlich den ältesten Wert> subtrahieren.
Das sind Optimierungen, die wirklich was bringen. Ok, bei 8 Werten ist
das jetzt nicht so toll, aber bei 1024 Werten macht das schon was aus.
Nur leider ist es eben keine Optimierung bei der man 1 oder 2 Befehle
einspart und damit nichts für "in Assembler - auch noch den letzten
Taktzyklus an einer Stelle suchen bei der es völlig uninteressant ist"
Programmierer.
Die auf mein einfaches Beispiel folgende Diskussion zeigt noch einen
weiteren interessanten Aspekt: Moby's "Vorbereitung und Planung" kann
man im echten Leben knicken. Bereits das simple Beispiel wirft
verschiedene Verbesserungs- und Modifikationsmöglichkeiten auf. Eine
Programmiersprache, worin sicher und übersichtlich Änderungen gemacht
werden können, ist somit eine Grundvoraussetzung und nicht ein
nice-to-have für jede höhere Software-Entwicklung.
So langsam wäre es an der Zeit, dass der Star des Threads sich mit einem
überzeugend einfachen Assembler-Beispiel für die obige Aufgabenstellung
melden würde. Moby, wo bist du?
Gu. F. schrieb:> Wow, unsere Mods leben ja richtig auf.> So ein Mobythread sollte öfter gestartet werden, das ist gut für eure> Seele :-)
Und wem haben wir das zu verdanken ?
Richtig, dem Moby.
Hätte der frühzeitig aufgegeben als es eklig und persönlich wurde, dann
wären wir nie soweit gekommen.
Der Vergleich einer realen Implementierung mit Mobys (noch zu
erbringendem) ASM code steht natürlich noch aus.
Aber Hut ab, das war richig gute und informative Unterhaltung bis
hierhin.
Über weite Strecken schien der Thread toter als tot zu sein nur um dann
noch mal richtig aufzudrehen.
Karl H. schrieb:> Es ist ebenfalls seine Umschreibung dafür, dass er noch nie irgendetwas> größeres programmiert hat. Das werfe ich ihm nicht vor. Was ich ihm> vorwerfe, das ist, dass er dann nicht so tun soll, als ob das alles> einfach linear hochskaliert.
Aus einer falschen Unterstellung folgerst du einen falschen Vorwurf.
In einigen KB Asm-Code lässt sich ja durchaus schon was 'größeres'
unterbringen. Dir waren für ein 'größeres' (C-) Projekt natürlich andere
KB-Größen im Sinn ;-)
'Linear hochskaliert' ist auch so ein netter Begriff. Stoff genug für
eine Doktor-Arbeit und noch mehr feinsinnigem Streit.
Ich behaupte, mit entsprechend Übung, Vorbereitung und System ist der
Codehimmel offen und weit... Die Grenzen setzen irgendwann Berechnungen
und das Handling großer Datenmengen. Oder übermäßig komplexe Hardware!
> beruflich programmiert aus leidvoller Erfahrung zu berichten weiss.> Auf diesem Ohr ist er allerdings taub,
Durchaus nicht. Hatte ich auch schon öfter gesagt. Allerdings frage ich
mich, warum das, was bei mir und anderen Asm-Programmierern
funktioniert, nicht öfter zum Einsatz kommt. Obwohl, lt. Tiobe tut es
das ja schon ;-)
le x. schrieb:> Nach allen Regeln der Kunst wird sein Code besiegt.
Nennt man das nicht Wunschdenken ?
Michael K. schrieb:> Der Vergleich einer realen Implementierung mit Mobys (noch zu> erbringendem) ASM code steht natürlich noch aus.So und nicht anders schauts für mein Projekt aus.
Zu erbringen hab ich dafür nix mehr.
Bleibe am Ball. Das ist freilich bei sovielen netten, tiefgründigen
Antworten für einen Einzelkämpfer für Asm hier zeitlich schwer zu
stemmen, aber ich bemühe mich.
Moby A. schrieb:> Die Grenzen setzen irgendwann Berechnungen> und das Handling großer Datenmengen.
warum eigentlich?
nur bei dir oder generell..?
weil früher™ ging mathe noch :
http://avr-asm.tripod.com/float128.htmlhttp://avr-asm.tripod.com/math32x.html
usw. (achtung bei der der Website wird man irgendwie komisch
weitergeleitet..)
den moving avg hätten wird dann auch gleich gefunden:
http://avr-asm.tripod.com/avr222.html
natürlich "zufällig" über 8 Werte ;-) (siehst du ich kann auch smilys)
>großer Datenmengen
auch komisch, früher™ hat man GENAU DORT ASM verwendet..
(Bildbearbeitung usw.)
aber auch für "MSR": z.b. messwerte archivieren auf speicherkarte:
http://avr-asm.tripod.com/flashcard.html
Robert L. schrieb:> auch komisch, früher™ hat man GENAU DORT ASM verwendet..> (Bildbearbeitung usw.)
Und noch früher hatte man den Opcode auf Formularen selbst ausgerechnet.
Aber wir warten noch auf deine hochoptimierte Implementierung des
gleitenden Mittelwerts. Meine hast du ja nun schließlich …
>Aber wir warten noch auf deine hochoptimierte
wer auch immer jetzt "deine" ist
aber ich hab ja freundlicherweise eine ASM version für Moby gepostet..
IMHO zeigt der Verlgeich der ASM und C Version recht schön die nachteil
der ASM Version auf..
ob es auch Vorteile der ASM version gibt, kann man jetzt schwer sagen:
dazu müsste IMHO jemand das Ergebnis des C-Programm durch eine de-asm
schicken..
Damit ein Vergleich wirklich ehrlich wird, müsste es eine
Aufgabenstellung geben, die GENAU spezifiziert, was gemacht werden muss.
Ob dabei Ram "verbraucht" wird oder nicht, etc.
Danach fangen ein C und ein ASM Programmierer mit der Implementation an
und wer zuerst fertig wird, stellt seinen ASM Code hier in eine
verschlüsselte .zip Datei rein. Wenn der zweite Programmierer fertig
wird, veröffentlicht er seinen Code und der erste veröffentlicht das
Passwort für seine ASM Datei.
Aber dann wäre das hier ja zu Ende...
Operator S. schrieb:> Damit ein Vergleich wirklich ehrlich wird, müsste es eine> Aufgabenstellung geben, die GENAU spezifiziert, was gemacht werden muss.> Ob dabei Ram "verbraucht" wird oder nicht, etc.>> Danach fangen ein C und ein ASM Programmierer mit der Implementation an
Das hat Karl Heinz bereits in einem anderen Thread vorgeschlagen:
Beitrag "C versus Assembler->Performance"
Ein paar Auszüge aus dem Thread:
Karl H. schrieb:> Wir vereinbaren einen Zeitpunkt an dem du und ich Zeit haben. Ein paar> Forneteilnehmer denken sich eine Aufgabe aus, irgendjemand (du, ich, wir> beide) wählt eine der Aufgaben aus und dann schaun wir mal, wer> schneller das Programm stehen hat und wer es fehlerfreier hinkriegt.>> Ich hab nur eine Bedingung: es darf kein Pipifax Beispiel sein sondern> sollte schon was ordentliches sein.
Es gab in dem Thread auch schon Vorschläge, wie diese Aufgabe aussehen
könnte. Aber:
Karl H. schrieb:> Aber erst mal muss er den Fehdehandschuh aufgreifen. Mal sehen, obs so> kommt wie es immer kommt, wenn ich sowas anbiete :-)Moby A. schrieb:> Den greife ich natürlich nicht auf, weil ich für solche Späße keine Zeit> investiere.
Natürlich hat er dafür keine Zeit, da er diese stattdessen in das
Schreiben seiner Beiträge hier steckt. Davon gibt es in diesem Thread
und den beiden früheren C-vs-Assembler-Threads¹ immerhin schon 551.
Schreibt er jeden Beitrag im Mittel in 5 Minuten², sind das in Summe
46 Stunden, also deutlich mehr als eine Arbeitswoche!
Selbst ein nur mittelmäßiger C-Programmierer bräuchte nur einen kleinen
Bruchteil dieser Zeit, um die vorgeschlagenenen Aufgaben umzusetzen.
Das Ganze allerdings in Assembler zu programmieren, und zwar so, dass
die Laufzeit- und Speichereffizienz mit dem C-Programm von Karl Heinz
mithalten kann, dürfte eine ziemliche Knochenarbeit sein, die sich
durchaus über mehrere Tage erstrecken kann.
Deswegen kann ich gut verstehen, warum sich Moby der Herausforderung
nicht stellen möchte, zumal er es trotz der deutlich längeren
Entwicklungszeit vermutlich nicht schaffen wird, effizienteren Code
abzuliefern, von besserer Les- und Wartbarkeit ganz zu schweigen.
————————————
¹) Beitrag "C versus Assembler->Performance"Beitrag "Kleines Tiny13 Sensorboard"
²) Dieser Wert ist wahrscheinlich noch viel zu niedrig angesetzt, da er
ja auch Zeit für das Lesen der anderen Beiträge braucht, auf die er
sich bezieht.
Moby A. schrieb:> Bleibe am Ball. Das ist freilich bei sovielen netten, tiefgründigen> Antworten für einen Einzelkämpfer für Asm hier zeitlich schwer zu> stemmen, aber ich bemühe mich.
Dann bring doch einfach das Beispiel, anstatt weiter Quatsch zu labern.
Hier nochmals die Aufgabenstellung:
1
voidmain(){
2
3
uint8_tthreshold=89;
4
5
uint8_tvalue_ptr=0;
6
uint8_tlast_values[8]={0,0,0,0,0,0,0,0};
7
8
ADC_CONFIG|=(1<<ADC_ON);
9
UART_CONFIG=...;// set some bits here
10
11
12
while(true){
13
if(ADC_STATUS&(1<<ADC_HAS_NEW_VALUE)){
14
15
// save value into ringbuffer
16
last_values[value_ptr]=ADC_VALUE;
17
18
// increase ringbuffer pointer
19
value_ptr++;
20
value_ptr%=8;
21
22
// sum up values in ringbuffer
23
uint16_tsum=0;
24
for(uint8_ti=0;i<8;i++){
25
sum+=last_values[i];
26
}
27
28
// check if average in ringbuffer exceeds threshold
Witkatz :. schrieb:> P. M. schrieb:>> Hier nochmals die Aufgabenstellung:>> Wo? Ich sehe nur Quellcode. Sieht so eine Spec aus?
Eine bessere Spec als einen kompletten Quellcode kann es gar nicht
geben, denn der definiert eindeutig was das Programm tun muss. Und in
diesem einfachen Fall kann man den Code in 2-5 Minuten durchlesen und
komplett verstehen. Zusätzlich hat es sogar noch Kommentare, die den
Code einzelne Abschnitte zusammenfasst. Wenn das nicht ausreicht als
Vorgabe, dann weiss ich auch nicht mehr weiter...
P. M. schrieb:> Eine bessere Spec als einen kompletten Quellcode kann es gar nicht> geben, denn der definiert eindeutig was das Programm tun muss. Und in> diesem einfachen Fall kann man den Code in 2-5 Minuten durchlesen und> komplett verstehen. Zusätzlich hat es sogar noch Kommentare, die den> Code einzelne Abschnitte zusammenfasst. Wenn das nicht ausreicht als> Vorgabe, dann weiss ich auch nicht mehr weiter...
Moby?? ^^ :-/ :-)
Witkatz :. schrieb:> P. M. schrieb:>> Hier nochmals die Aufgabenstellung:>> Wo? Ich sehe nur Quellcode. Sieht so eine Spec aus?
Ich sehe da wie P.M. auch kein größeres Problem.
Nach Anschauen des Quellcodes war mir (ich bin wahrlich kein C-Gott)
nach gefühlten 30 Sekunden klar, dass das Programm eine über die letzten
acht Werte gemittelte Spannung am ADC an die serielle Schnittstelle
ausgibt, wenn ein Schwellenwert überschritten wurde.
Was genau verlangt wird, ist aus dem Programm also offenbar recht
einfach zu entnehmen.
Chris D. schrieb:> Ich sehe da wie P.M. auch kein größeres Problem.>> Nach Anschauen des Quellcodes war mir (ich bin wahrlich kein C-Gott)
Ist auch nicht nur für dich. Ihr wollt euch mit einem C-Legastheniker
messen und legt eine in C verfasste Spec vor? Ist das nicht ein bisschen
unfair?
Witkatz :. schrieb:> Ist auch nicht nur für dich. Ihr wollt euch mit einem C-Legastheniker> messen und legt eine in C verfasste Spec vor? Ist das nicht ein bisschen> unfair?
Er konnte ja auch lang und breit erklären, inwiefern Assembler gegenüber
C überlegen ist. Also gehe ich mal davon aus, dass er C zumindest
verstehen kann, wenn auch mit vielleicht etwas mehr Mühe als andere.
Witkatz :. schrieb:> Ist das nicht ein bisschen unfair?
Ist es, aber es ist natürlich genau das, was Moby seit Monaten auch
macht. ;-)
Wenn man allerdings das von Yalu zitierte Angebot von Karl Heinz
liest, sah das dort durchaus anders aus.
Witkatz :. schrieb:> Wo? Ich sehe nur Quellcode. Sieht so eine Spec aus?
Gemäss Moby braucht er selber nicht mehr um ein Programm zu verstehen:
Moby A. schrieb:> ttyS2 schrieb:>> Dann liefere doch endlich eine ordentliche Beschreibung der>> Anforderungen.>> Siehe Beschreibung, Diagramm, Sourcecode, Threadverlauf.
Schaltplan ebensowenig, das Layout ist selbsterklärend.
Operator S. schrieb:> Gemäss Moby braucht er selber nicht mehr um ein Programm zu verstehen:
Man muss sich doch aber jetzt nicht selbst auf dieses unterirdische
Niveau begeben.
Jörg W. schrieb:> Ist es, aber es ist natürlich genau das, was Moby seit Monaten auch> macht. ;-)
Nichts gegen Moby, aber er ist mir zu sehr auf ASM beschränkt. Sein
persönlicher Urteil interessiert mich nicht die Bohne, zumal der von
vornherein feststeht. Für einen objektiven Vergleich sollte die Aufgabe
von guten Programmierern beleuchtet werden, die sowohl ASM als auch C
beherrschen.
Mein Vorschlag wäre, dass P.M. seine Aufgabe in C ans Laufen bringt und
den lauffähigen Quellcode, das ASM Listing und den Ressourcenverbrauch
(Flash/RAM/Programmlaufzeit etc.) vorlegt, dann ist schon mal die Hälfte
erbracht. Eventuell kann man das auch mit verschiedenen Compilern und
Optimierungsstufen vergleichen.
Dann kann man auf der ASM Seite (mit oder ohne Moby) schauen, ob und
welches Optimierungspotential in ASM steckt. Vielleicht kann dann Moby
ein besseres ASM Quellcode vorlegen oder gute Optimierungen vorschlagen?
Witkatz :. schrieb:> Vielleicht kann dann Moby ein besseres ASM Quellcode vorlegen oder gute> Optimierungen vorschlagen?
Klar kann man das immer.
Das Problem der Assemblerprogrammierung ist doch, dass es 1.) ziemlich
lange dauert, bis man eine erste, (einigermaßen) bugfreie Lösung hat
und dass man 2.) immer noch die Chance hat, einiges an Potenzial für
Optimierung zu verschenken.
Eine einmal existierende Vorlage nachträglich weiter zu verfeinern,
ist logischerweise sehr viel einfacher, entspricht ja aber nicht dem
Vergleich der beiden Vorgehensweisen.
Das, was Karl Heinz im anderen Thread vorgeschlagen hat, hat schon
Hand und Fuß, das wäre die korrekte Vorgehensweise. Aber siehe oben,
Mobys Antwort dazu war doch eindeutig: „Den greife ich natürlich nicht
auf, weil ich für solche Späße keine Zeit investiere.“ (Dass er im
Gegenzug als Widerlegung für seine These verlangt, dass alle anderen
sich die Zeit für derartige Späße nehmen, ist natürlich bezeichnend
für seine Persönlichkeitsstruktur.)
Witkatz :. schrieb:> Mein Vorschlag wäre, dass P.M. seine Aufgabe in C ans Laufen bringt und> den lauffähigen Quellcode, das ASM Listing und den Ressourcenverbrauch> (Flash/RAM/Programmlaufzeit etc.) vorlegt, dann ist schon mal die Hälfte> erbracht. Eventuell kann man das auch mit verschiedenen Compilern und> Optimierungsstufen vergleichen.
Das hört sich auf jeden Fall richtig interessant an :-)
Bisher habe ich mich (und vermutlich viele andere auch) noch nicht
wirklich in die "Optimierungstiefen" eines C-Compilers gewagt: "was wird
wann wie optimiert?"
So könnte man aus diesem Thread sogar noch etwas mitnehmen.
Witkatz :. schrieb:> Mein Vorschlag wäre, dass P.M. seine Aufgabe in C ans Laufen bringt> und den lauffähigen Quellcode, das ASM Listing und den> Resourcenverbrauch (Flash/RAM/Programmlaufzeit etc.) vorlegt, dann ist> schon mal die Hälfte erbracht. Eventuell kann man das auch mit> verschiedenen Compilern und Optimierungsstufen vergleichen.>> Dann kann man auf der ASM Seite (mit oder ohne Moby) schauen, ob und> welches Optimierungspotential in ASM steckt. Vielleicht kann dann Moby> ein besseres ASM Quellcode vorlegen oder gute Optimierungen> vorschlagen?
Damit kann man gut die Frage klären, ob Compilercode noch Potential für
Handoptimierung hat, aber nicht einen Wettstreit ASM-handgebaut gegen
Compiler-Bloat. Letztlich erfährt man nur, ob Moby fehlerfrei
abschreiben kann. Zweifel sind erlaubt, besonders wenn der GCC auf die
Idee kommt, "seltene Opcodes" zu benutzten.
Jörg W. schrieb:> entspricht ja aber nicht dem> Vergleich der beiden Vorgehensweisen.
Den hat P.M. auch nicht vorgeschlagen. Er hat die Aufgabe in Hochsprache
bereits gelöst und das ist auch mMn die übliche Vorgehensweise. Um das
getestete Projekt vom Test-µC auf einen kleineren Produktions-µC zu
portieren, würde man vielleicht anfangen in C zu optimieren oder auf ASM
zurückgreifen. Mit so einer Pipifax Aufgabe vielleicht nicht, aber wie
soll man das Optimierungspotential von C und ASM für kleine MSR Aufgaben
sonst vergleichen, als mit einer kleinen MSR Aufgabe?
Als Ergänzung der Aufgabe würde ich noch bei Überschreitung des
Grenzwertes einen Ausgang setzen und bei Unterschreitung mit definierter
Hysterese zurücksetzen. Als Alibifunktion für das SR in MSR.
Ey Leute, was soll das?
Anhand eines einzigen, konstruierten Beispiel die Überlegenheit einer
Sprache oder Programmiertechnik aufzeigen zu wollen?
Jeder von und weiß, dass die Welt nicht so simpel ist, und dass zudem
ein so konstruierten Beispiel wahrscheinlich so gestrickt ist, dass es
die eigene Einstellung untermauert.
Die meisten hier bevorzugen Hochsprachen für die Umsetzung ihrer
Projekte.
Moby bevorzugt und liebt sein AVR-ASM für die Umsetzung seiner
Projekte und hat eine klar artikulierte Abneigung gegen C.
So what?
Argumente für und wider gibt es duzende, ich brauch sie hier nicht zu
wiederholen.
Aber jeder wichtet die Bedeutung der einzelnen Argumente und
Software-Metriken anders und sogar mit anderen Vorzeichen (z.B.
Kontrolle über "alles" wie etwa Registerlayout zu haben oder haben zu
müssen). Und jeder hat andere Vorlieben, Präferenzen, Erfahrungen,
Hintergrundwissen, Qualitätsbewusstsein, Grad an Pragmatismus,
Perfektionismus, Kontrollzwang.
Und am Ende wird jeder eine überwältigende Mehrzal an Argumenten für
seine eigene Überzeugung finden.
Viele, die hier für C argumentieren, könnten ähnliche Argumente
hernehmen, um von C abzuraten und Arduino oder BASCOM zu propagieren...
Zumal C nur auf den ersten Blick einfach ist: Es hat genug Fallstricke,
und C ist weder von Hobby-Programmierern entworfen worden noch für
Hobby-Programmierer entworfen worden. C++ ist nochmals um
Größenordnungen komplexer.
Inzwischen geht's hier ja nur noch ums Missionieren bzw. um Repliken auf
als Missionierung empfundene Repliken auf als Missionierung empfundene
Repliken auf...
Johann L. schrieb:> Jeder von und weiß, dass die Welt nicht so simpel ist, und dass zudem> ein so konstruierten Beispiel wahrscheinlich so gestrickt ist, dass es> die eigene Einstellung untermauert.
Nö, sehe ich nicht so. Einen Analogwert messen, glätten und auf
Grenzwertverletzung reagieren - was ist daran bitte schön künstlich
konstruiert um irgedwas zu untermauern?
Johann L. schrieb:> Jeder von und weiß, dass die Welt nicht so simpel ist, und dass zudem> ein so konstruierten Beispiel wahrscheinlich so gestrickt ist, dass es> die eigene Einstellung untermauert.
Es verwendet zwei Peripherie-Geräte (ADC und UART), einfache Arithmetik
(Mittelwertbildung) und muss auf simple Statusänderungen (ADC hat neuen
Wert, Grenzwert zu hoch) reagieren. Ich finde, das ist ein sehr
repräsentatives Beispiel für allgemeine MS(R)-Aufgaben.
Und ganz ehrlich: Beim Thread geht's ja schon längst nicht mehr darum,
ob C oder Assembler "besser" ist. Wir sind uns alle einig, dass C für
die meisten Fälle die bessere Wahl ist und Assembler seine volle
Berechtiung in gewissen Nischen hat. Es geht schon lange nur noch darum,
wie man dies auch Moby klarmachen kann.
Jörg W. schrieb:> Die Antwort ist doch sonnenklar: gar nicht.
Zumal seine Erkenntnisse nicht auf Erfahrungen beruhen, sondern er nur
die üblichen Klosprüche nachplappert.
mfg.
P. M. schrieb:> Wir sind uns alle einig, dass ...> Assembler seine volle> Berechtiung in gewissen Nischen hat.
Für mich sind eben diese Nischen das einzig Interessante an diesem
Thread. Ich hätte gerne eine objektive (oder zumindest fundierte
subjektive) Antwort auf die akademische Frage ob und wann sich Assembler
lohnt und ob in ASM wirklich noch nennenswertes Optimierungspotential
steckt, das man mit gut optimierendem Compiler nicht mehr rausholen
kann.
Witkatz :. schrieb:> ob und wann sich Assembler lohnt
Dafür wirst du keine pauschale Aussage bekommen, außer sowas wie:
wenn du auf den einzelnen Taktzyklus genau sein willst, dann musst du
den Maschinencode natürlich komplett selbst zimmern. Je moderner die
CPU aber ist, um so schwieriger wird es, die Zyklenzahl überhaupt
so genau zu ermitteln, siehe bspw. die Diskussion dort:
Beitrag "[ARM / Cortex-M0(+)] delay-Funktionen "avr-libc style""
Da ist so ein Cortex-M0(+) zwar in der Einfachheit der CPU noch
relativ nah dran an dem, was man bspw. von einem AVR gewohnt ist
(bspw. typisch keinen Cache), aber selbst da hängt es eben nun nicht
nur davon ab, wie viele Flash wait states man konfigurieren muss,
sondern eben auch davon, dass bei 16-bit-Thumb ein Opcode fetch
gleich zwei Befehle mit einem Takt lädt.
Ansonsten kannst du dir natürlich immer mal den vom Compiler generierten
Assemblercode ansehen um ein Gefühl zu bekommen, was da so läuft.
Beispielsweise sowas hier:
Beitrag "Re: Codeblähungen beim Rechnen mit globaler Variable"
von dem dann Johann meint: „Find ich naheliegend und nicht skurril :-)“
Jörg W. schrieb:> P. M. schrieb:>> wie man dies auch Moby klarmachen kann.>> Die Antwort ist doch sonnenklar: gar nicht.
Ist ja auch egal.
Er hat sich eh verdrückt.
Moby A. schrieb:> Für den Ressourcenvorteil von Asm? Genügend.
Mannmonate sind auch Ressourcen. Sauteure Ressourcen sogar, teurer als
jedes MHz und jedes kByte, denn die kB und die MHz entstehen quasi aus
dem Nichts, einfach durch Warten und Däumchen drehen: Während der
ASM-Coder schwitzend und fluchend Jahre an teurer Zeit verbrennt tauchen
noch lange bevor er auch nur ansatzweise fertig ist wie aus dem Nichts
schon neue Controller auf mit doppelt so viel Speicher und Rechenkraft
fürs halbe Geld, die all diese Bemühungen nun mit einem Schlag obsolet
machen.
Witkatz :. schrieb:> Nö, sehe ich nicht so. Einen Analogwert messen, glätten und auf> Grenzwertverletzung reagieren - was ist daran bitte schön künstlich> konstruiert um irgedwas zu untermauern?
Na ja.
Aber wenn du jetzt ehrlich bist, so herausfordernd ist dieses Beispiel
jetzt auch wieder nicht. Auch wenn Moby eine Abneigung gegen alles was
mehr als 8 Bit Arithmetik hat, 16 Bit Additionen kriegt er auch hin.
Genauso wie der Compiler.
Ganz im Gegenteil würde ich sogar erwarten, dass hier der Compiler einen
Assembler Code hinlegt, den man auch mit Handoptimierung nicht mehr
schneller hinkriegt und wenn dann höchstens um ein paar Takte im kleinen
einstelligen Bereich.
Bernd K. schrieb:> Während der> ASM-Coder schwitzend und fluchend Jahre an teurer Zeit verbrennt
Weder schwitzend noch fluchend.
Die Zeit ist auch nicht teuer.
Hobbyzeit ist Spaßzeit!
> noch lange bevor er auch nur ansatzweise fertig ist wie aus dem Nichts> schon neue Controller auf mit doppelt so viel Speicher und Rechenkraft> fürs halbe Geld, die all diese Bemühungen nun mit einem Schlag obsolet> machen.
Ob aber der 'neue Controller' für die geplante Anwendung überhaupt nötig
wäre? (Bitte zweimal lesen)
Als Bastler kann ich dank effizientem Asm bei einfachen MSR-Aufgaben auf
ewig beim AVR bleiben. Es gibt nicht den geringsten Anlass, den
Controller wechseln zu müssen. Deshalb werden auch keine Bemühungen mit
einem Schlag obsolet.
Wenn sich der gewerbliche Programmierer genötigt sieht, den Controller
zu wechseln hat das u.a. einen Grund: Die Ineffizienz der Hochsprache.
Die Ineffizienz der Abstraktion. Und das mit steigender Tendenz.
Moby A. schrieb:> Karl H. schrieb:>> Es ist ebenfalls seine Umschreibung dafür, dass er noch nie irgendetwas>> größeres programmiert hat. Das werfe ich ihm nicht vor. Was ich ihm>> vorwerfe, das ist, dass er dann nicht so tun soll, als ob das alles>> einfach linear hochskaliert.>> Aus einer falschen Unterstellung folgerst du einen falschen Vorwurf.> In einigen KB Asm-Code lässt sich ja durchaus schon was 'größeres'> unterbringen.
Ansichtssache.
einige KB sind für manche hier (mich eingeschlossen) immer noch
Kinderkram :-)
Aber das hätte ich von dir gar nicht verlangt.
> 'Linear hochskaliert' ist auch so ein netter Begriff. Stoff genug für> eine Doktor-Arbeit und noch mehr feinsinnigem Streit.
Nicht wirklich.
Es ist die einfache Milchmädchenrechnung: Wenn ein Arbeiter einen Graben
in 1 Stunde aushebt, dann schaffen 3600 Arbeiter das in 1 Sekunde.
> Codehimmel offen und weit... Die Grenzen setzen irgendwann Berechnungen> und das Handling großer Datenmengen. Oder übermäßig komplexe Hardware!
Na, na. Wer wird denn gleich.
Sargon Chess ist auf dem Z80 in Assembler programmiert. Seine
Datenhandhabung ist alles andere als einfach.
Ein Lee Algorithmus ist vom Prinzip her nicht schwer, aber die
Datenstruktur kann knifflig werden. Hab ich trotzdem in Assembler
gemacht. Warum? Zum Spass! Und natürlich weil 1984 die Z80-C Compiler
nach sehr, sagen wir mal, in den Kinderschuhen steckten. Als junger
Student hatte ich nachts Zeit und die Übung hat mir sicherlich nicht
geschadet.
Moby A. schrieb:> Die Zeit ist auch nicht teuer.> Hobbyzeit ist Spaßzeit!
OK. Wenn es nur dein Hobby ist dann ist das OK, dann kannst Du auch ein
2m hohes Eiffelturm-Modell aus 42000 einzelnen Streichhölzern bauen.
Vollkommen OK. Macht evtl. sogar Spaß.
Aber dann brauchst Du nicht mit dem Wort "Ressourcen" argumentieren,
oder irgendwas wäre effizienter als irgendwas anderes, die ganze alberne
Diskussion hat sich dann komplett erledigt, Du betreibst dann das
ASM-Puzzlespiel nur zum reinen Selbstzweck, völlig losgelöst von
irgendwelchen Erwägungen bzgl. Effizienz oder praktischem Nutzen.
K.H.:
> Als junger Student hatte ich nachts Zeit und die Übung hat mir> sicherlich nicht geschadet.
Du bist aber deshalb nicht dran kleben geblieben und versuchst auch
nicht alle anderen, die nicht dran kleben geblieben sind, als faul und
unbegabt darzustellen, oder?
Gu. F. schrieb:> Er hat sich eh verdrückt.
Da mach Dir mal keine unnötigen Sorgen. Leider hab ich für diesen Thread
keinen Vollzeitjob. Aus Zeitgründen kann ich mir vorerst nur
konstruktive Einwände herauspicken. Deine werden fürchte ich jetzt auf
der Strecke bleiben ;-(
le x. schrieb:> Ist doch perfekt: ich teile dem Compiler nur kurz mit, dass ich einen> 8-Bit-Signed Wert haben will. Oder einen 16-Bit Unsigned.
Das ist mit .BYTE x schneller erledigt. Die gebräuchlichsten Variablen
sind absehbar eh nur Bytes und Words- mehr braucht man höchstens bei
selteneren Berechnungen.
> Du, mein lieber Moby, hast in deinem ASM-Code auch Datentypen (OK,> zugegeben, du nicht. Du hast nur 8-Bit-Unsigned, alles andere ist viel> zu komplex und wird auf dedizierte Hardware ausgelagert. Aber andere> ASM-Programmierer kennen Datentypen).
War der erste Teil noch richtig wirst Du beim zweiten wieder unsachlich.
> Du merkst dir den Datentyp im Kopf. Du schleppst ihn also implizit immer> mit dir rum, ob du das möchtest oder nicht.
Ich schleppe gar nichts. Mit der Definition der Variable ist der vorab
bestimmte Wertebereich klar. Vermutlich oft sparsamer dimensioniert, als
durch den zur Verschwendung neigenden C-Programmierer.
> Und jedesmal wenn mit einem Register gerechnet werden soll musst du von> Neuem entscheiden wie du vorgesht.> Ob ein Carry für den Vergleich berücksichtigt werden soll.> Ob du mehrere Register allokieren musst....
Das stellst Du Dir unnötig kompliziert vor.
Im Kopf sind die verfügbaren Register. Sooo viele sinds nicht; mein
System der Verwendung hatte ich bereits weiter oben skizziert.
Das Carry-Bit wird auch selten zum Stolperstein, add/adc und sub/sbc
sind gewohnte Kombinationen. Größere Berechnungen werden an die
immergleichen fertigen Funktionsbausteine delegiert, die Input (Output)
mit System in entsprechenden "standardisierten" Registern empfangen
(ausgeben). Und überhaupt Berechnungen: Ja, sie wären ein Argument für
C- wenn, ja wenn sie denn so häufig wären.
> Und wehe, wehe, der Datentyp ändert sich weil du beim Entwickeln deiner> MSR-Applikation feststellst dass der Wertebereich bei der benötigten> Auflösung nicht ausreicht...
Wiegesagt, wenn man sich bitteschön vorher einen Kopf macht welche
Wertebereiche (z.B. ab einem ADC) benötigt werden muß man auch hinterher
nix mehr ändern.
> Du findest es kryptisch, zwei Variablen mittels "==" vergleichen zu> können? Völlig unabhängig vom Datentyp? Wow. Da fällt mir echt nichts> mehr ein.
Aber mir fällt spontan cp/cpc dazu ein. Wiegesagt, es sind eh meist nur
Byte- oder Word Variablen.
> Aber wir wissen ja alle hier dass deine Abneigung gegen C, und> wahrscheinlich deine Vorliebe für dein AVR-ASM einzig daher rührt dass> deine bisherigrn kurzen C-Versuche gescheitert sind.
Falsch. Das C-Programm steht und funktioniert- und es war kein kurzes.
Aus seinen Erfahrungen sollte man aber lernen. Die Asm-Freiheiten gerade
bei der kleinteiligen Auswertung von Hardware habe ich sehr vermisst.
Die Möglichkeit kurzer knapper Formulierung ohne viel Palaver.
> Im Übrigen würde ich dich bitten nie, NIE wieder von MSR-Anwendungen zu> faseln.
Ich fasele nicht. Überdenke Deine Wortwahl.
> Denn R-Anwendungen sind mit 8-Bit-Unsigned-Arithmetik einfach nicht zu> Richtiges "R" fordert oft anspruchsvolle Mathematik.> handeln.
Also meine Regelung für die Fernheizung funktioniert auch ohne Studium.
Ist alles halb so schwer als wie Du glauben machen möchtest ;-)
> Bitte benutze also in Zukunft nur noch den Ausdruck "MS-Applikation",> schon aus Respekt vor richtigen Regelungstechnikern.
Da habe ich Respekt und ich weiß aus betrieblicher Erfahrung, daß
Regelungen durchaus anspruchsvoll sein können. Meine Erfahrung im
SmartHome- und das ist auch kein kleiner Bereich- zeigt mir aber, daß
Regelungen als Teil von MSR hier den geringsten Teil ausmachen. Aber es
gibt sie.
Bernd K. schrieb:> Aber dann brauchst Du nicht mit dem Wort "Ressourcen" argumentieren,> oder irgendwas wäre effizienter als irgendwas anderes
Da hat sich nichts erledigt. Mein Programm zeigt C im Ressourcenbedarf
die Grenzen auf. Was mein Asm-Programm kann, das können Millionen
weitere auch. Lass die Streichhölzer stecken. MSR auf 8-Bittern geht mit
Asm sparender und sehr oft leichter. Ich muß gerade wieder über
Beitrag "Codeblähungen beim Rechnen mit globaler Variable"
schmunzeln... Mein Gott, was für Kopfstände, um seinen Code optimal zu
bekommen!!!
Karl H. schrieb:> einige KB sind für manche hier (mich eingeschlossen) immer noch> Kinderkram :-)
Tja, Kinderkram hin oder her, es reicht fürs komfortable Smarthome.
Was dort langt langt noch ganz woanders. 'Kinderkram' nehm ich mal als
Kompliment fürs effiziente Tandem AVR/ASM- denn in der Tat, so sind
Probleme spielend einfach gelöst!
> Aber das hätte ich von dir gar nicht verlangt.
Danke. Du bist großzügig. ;-)
> Es ist die einfache Milchmädchenrechnung: Wenn ein Arbeiter einen Graben> in 1 Stunde aushebt, dann schaffen 3600 Arbeiter das in 1 Sekunde.
Ja ja, die hübschen Vergleiche wieder... Darauf geb ich inzwischen
keinen Cent mehr.
> Sargon Chess ist auf dem Z80 in Assembler programmiert. Seine> Datenhandhabung ist alles andere als einfach.
Glaub ich. Da werden viele Berechnungen gebraucht. Da gibts viele Daten.
Hatte ich das nicht schon als Ausschlußkriterium für Asm-Projekte
erwähnt?
> Und natürlich weil 1984 die Z80-C Compiler> nach sehr, sagen wir mal, in den Kinderschuhen steckten.
Compiler werden immer in den Kinderschuhen stecken.
Warum? Weil sie den konkreten Anwendungsfall und oft die konkrete
Hardware gar nicht im Focus haben. Der Asm-ler, ja deeer hat es!
> Als junger> Student hatte ich nachts Zeit und die Übung hat mir sicherlich nicht> geschadet.
Ja, Respekt Karl Heinz. Da lernt man was. Mein größtes Z80 Asm Projekt,
ein onboard programmierbarer SPS-EPC inklusive eigener Sprache hatte
22KB. Versauert leider im Keller, denn irgendwann hat der AVR das ganze
System plötzlich in die Tasche gesteckt. Seitdem kam nichts besseres und
einfacheres mehr nach ;-)
Karl H. schrieb:> Und natürlich weil 1984 die Z80-C Compiler nach sehr, sagen wir mal, in> den Kinderschuhen steckten.
Da hat man ja auch Turbo-Pascal benutzt. ;-)
Karl H. schrieb:> Das müsste eine ziemliche 1:1 Umsetzung des fraglichen Assembler Codes> sein.
Was hindert Dich daran, daraus einen vollständigen Programmcode zu
machen den ich überprüfen kann? Die Vorahnung, daß es mit 1:1 oder dem
Ressourcenbedarf doch nicht so weit her ist ?
P. M. schrieb:> Ich denke, das ist sehr typisches 8-Bit-MS(R). Könntest du das jetzt> bitte mal in kurzen, kompakten, übersichtlichen Assembler-Code> umwandeln?
Klar könnte ich. Doch hättest Du mal lieber die Zeit wie K.H. in die
Übersetzung meines Projekts gesteckt, dann hätte ich längst vergleichen
können. Irgendwelche neue Aufgabenstellungen zu präsentieren trägt nicht
dazu bei.
A. K. schrieb:> Vergleiche jenseits von 8 Bits sind nicht seine starke Seite
cp+cpc Jungs, so einfach ist das ;-)
Matthias L. schrieb:> ASM (selbst) kennt kein Vorzeichen. Somit existiert das Problem> "Vorzeichen" nur in den kryptischen, aufgeblasenen Hochsprachen.
Bis 32 Bit hab ich fertige Routinen...
Ich müsste aber laaang überlegen wann ich Operationen mit Vorzeichen bei
MSR zuletzt gebraucht habe.
A. K. schrieb:> Moby rechnet Temperaturen vermutlich in Fahrenheit. Das reicht von> Saukalt bis Kaffee in 8 Bits ohne Vorzeichen.
Schon mal was von Angaben in Kelvin gehört?
Oft interessiert doch noch nicht einmal die Einheit, wenn es nur um
Vergleiche auf Sollwertüberschreitungen geht.
Witkatz :. schrieb:> Wieso? Ich dachte, dass einfache Digitalfilter zu einfacher MSR dazu> gehören, oder etwa nicht?
Nie gebraucht !
Karl H. schrieb:> Da schreibe ich / 8 und der Compiler kümmert sich drum, wie oft> verschoben werden muss.
Genial. Das überzeugt mich jetzt. Wie das Shifting mit dem
Divisionsergebnis zusammenhängt ist aber auch sowas von schwer zu merken
;-)
Moby A. schrieb:> Bis 32 Bit hab ich fertige Routinen...> Ich müsste aber laaang überlegen wann ich Operationen mit Vorzeichen bei> MSR zuletzt gebraucht habe.
Beim Vergleich der Führungsgröße mit der Rückführung wird
klassischerweise Signed-Arithmetik benötigt. Aber nur bei Regelungen,
nicht bei Micky Maus.
Moby A. schrieb:>> Du findest es kryptisch, zwei Variablen mittels "==" vergleichen zu>> können? Völlig unabhängig vom Datentyp? Wow. Da fällt mir echt nichts>> mehr ein.>> Aber mir fällt spontan cp/cpc dazu ein. Wiegesagt, es sind eh meist nur> Byte- oder Word Variablen.
Ach, und "==" ist kryptischer als cp/cpc? Was soll das sein?
Chickenpizza/Chickenpizza-Curry?! Das Zeichen "=" ist in der Regel aus
der Grundschule bekannt.
Moby A. schrieb:> Das ist mit .BYTE x schneller erledigt. Die gebräuchlichsten Variablen> sind absehbar eh nur Bytes und Words- mehr braucht man höchstens bei> selteneren Berechnungen.Moby A. schrieb:> Ich schleppe gar nichts. Mit der Definition der Variable ist der vorab> bestimmte Wertebereich klar. Vermutlich oft sparsamer dimensioniert, als> durch den zur Verschwendung neigenden C-Programmierer.Moby A. schrieb:> Wiegesagt, wenn man sich bitteschön vorher einen Kopf macht welche> Wertebereiche (z.B. ab einem ADC) benötigt werden muß man auch hinterher> nix mehr ändern.Moby A. schrieb:> Mein Programm zeigt C im Ressourcenbedarf> die Grenzen auf.
Man verzeihe mir bitte meine Unsachlichkeit, aber jetz muss ich mal blöd
fragen:
Moby, glaubst du die Scheiße die du hier verzapfst eigentlich wirklich
selbst?
le x. schrieb:> Beim Vergleich der Führungsgröße mit der Rückführung wird> klassischerweise Signed-Arithmetik benötigt. Aber nur bei Regelungen,> nicht bei Micky Maus.
Das ist keine typische Anwendung für Controller - es reicht doch eine
Zweipunktregelung :-)
Moby A. schrieb:> Wenn sich der gewerbliche Programmierer genötigt sieht, den Controller> zu wechseln hat das u.a. einen Grund: Die Ineffizienz der Hochsprache.> Die Ineffizienz der Abstraktion. Und das mit steigender Tendenz.
Das stimmt nicht.
Bisher habe ich die MCU gewechselt weil ich:
a.) spezielle Hardware
(Viele Uarts, I²S, viele Hardware PWMs, spezielle Hardware für SMPS)
b.) besonders kleine Bauformen
c.) einen extrem niedrigen Preis
benötigt habe.
Der AVR ist ganz nett, aber er ist alt, langsam, teuer, groß und braucht
mehr Beschaltung als viele seiner modernen Kollegen.
Ein freundlicher Dinosaurierer so wie der 8051 den ich auch lange benutz
habe um dann weiterzuziehen.
Durch die modernen C Compiler kann ich fröhlich zwischen den MCU
Familien hin und herspringen, was immer gerade für mich passt.
Niemand hat ein Problem damit wenn Du auf ewig beim AVR bleiben möchtest
und ASM Dein erkärter Liebling ist.
Aber hör doch bitte auf uns zu erzählen was das beste für uns ist und
was wir wirklich brauchen.
Du steckst nicht in unseren Schuhen und hast keine Ahnung davon was
unsere Gründe sind zu tun was wir tun.
Aus Deiner Sicht mag Dein Weg der ideale für Dich sein.
Freut mich auch für Dich, bleib dabei wenns für Dich funktioniert.
Ich empfinde Deinen Weg als kompliziert, einschränkend und als Relikt
einer vergangenen Epoche.
Das kann ich sagen weil ich mit ASM auf 8085 / 8051 angefangen und die
Annehmlichkeiten moderner MCUs und Sprachen zu schätzen gelernt habe.
Ich werde mich stark hüten nun meine Maßstäbe zu nehmen und zu behaupten
das mein Weg nun auch für alle anderen der richtige ist.
Der richtige Weg ist von derat vielen Parametern abhängig und so stark
personenbezogen das den jeder für sich selber finden muß.
Manch einer nimmt lieber eine starke MCU und programmiert sich die
Hardwareemulation wo die Hardware fehlt,der andere wechselt dafür die
MCU Familie, der nächste löst das im FPGA Block usw.
Richtig ist das was funktioniert und im persönichen Aufwands-, Kosten-,
Zeitrahmen bleibt.
Die ganze Diskussion dreht sich immer wieder um Deine Eigenschaft das
eigene Vorgehen als die ultimative Wahrheit zu verkaufen und jedes
Argument so zurecht zu biegen das es Deine individuelle Sicht der Dinge
untermauert.
Das ist kindisch und unreif, eine Form des Altersstarrsinns oder ein
Defizit in der Persönlichkeit.
Sorry, das ich das so sagen muß, aber das geht uns allen hier gehörig
auf den Keks.
Natürlich ist das auch unterhaltsam, aber eher in der Art wie eine
Satiresendung oder ein komödiantisches Bühnenstück.
Ob Du das machst weil Du die Konfrontation liebst oder weil Deine
Emotionale Intelligenz tatsächlich an der Nulllinie kratzt kann ich
nicht sagen, ist mir auch egal.
Wenigstens bist Du unterhaltsam ohne extrem ausfallend zu werden.
Damit gehörst Du für mich zu den wertvolleren Mitgliedern dieses Forums.
Moby A. schrieb:> Wenn sich der gewerbliche Programmierer genötigt sieht, den Controller> zu wechseln hat das u.a. einen Grund: Die Ineffizienz der Hochsprache.
Das heisst, Du bekommst jedes erdenkliche "typische 8-Bit-Programm" in
einen Tiny13 gequetscht, weil Du in ASM programmierst? Du brauchst also
niemals mehr den Prozessor wechseln? Es passt alles in einen Tiny13?
Kompliment!
Frank M. schrieb:> Das heisst, Du bekommst jedes erdenkliche "typische 8-Bit-Programm" in> einen Tiny13 gequetscht, weil Du in ASM programmierst? Du brauchst also> niemals mehr den Prozessor wechseln? Es passt alles in einen Tiny13?
Ja, da passt alles rein was sein persönlicher Horizont erfassen kann.
Gu. F. schrieb:> Ja, da passt alles rein was sein persönlicher Horizont erfassen kann.
Man kann an seiner Aussage nicht nur seinen persönlichen Horizont
erkennen, sondern auch deren Schwachsinnsgehalt.
Gu. F. schrieb:> Ja, da passt alles rein was sein persönlicher Horizont erfassen kann.
Wir sollten Sturheit nicht mit Dummheit verwechseln.
Moby durchdringt durchaus auch kompliziertere Probleme.
Ich finde es wenig hilfreich wieder zu den düsteren Passagen dieses
Threads zurückzukehren in denen es eher um persönliche Angriffe ging.
Das sind alles nur Steilvorlagen um alles was wir sagen in die
Beleidigungsecke zu schieben ohne sich inhaltlich damit beschäftigen zu
müssen.
Moby A. schrieb:> P. M. schrieb:>> Ich denke, das ist sehr typisches 8-Bit-MS(R). Könntest du das jetzt>> bitte mal in kurzen, kompakten, übersichtlichen Assembler-Code>> umwandeln?>> Klar könnte ich. Doch hättest Du mal lieber die Zeit wie K.H. in die> Übersetzung meines Projekts gesteckt, dann hätte ich längst vergleichen> können. Irgendwelche neue Aufgabenstellungen zu präsentieren trägt nicht> dazu bei.
Erinnert mich an meine Kinder..
Ist ja wie im Kindergarten.
"Ich hab es aber als erstes gehabt!"
Sobald ein Kind diesen Satz sagt, ist jede Diskussion Sinnlos: Damit
wird jedes Argument abgeschmettert..
(egal ob das Kind überhaupt noch an der Sache interessiert ist, da man
es ja als erster gehabt hat, behält man es natürlich..)
Moby hat als erster seine ASM Code gepostet, und erwartet das andere
den C-Code liefern..
Damit ist aus Sicht eines 5 Jährigen die Sachlage vollkommen klar:
Wenn jemand anderer das selbe macht, also C-Code postet und von Moby das
selbe in ASM-Code erwartet ist das natürlich vollkommen illegitim...
Man muss sich auch mal in die Lage des C-Programmierers versetzen, der
nach Mobys Forderung dessen ASM-Programm in C übersetzen soll:
Wozu soll dieser sich diese Mühe machen, Mobys Programm zu verstehen
(80% der Arbeit) und dann zu übersetzen (20% der Arbeit)? Er braucht das
Programm nämlich nicht. Er würde es für die Tonne programmieren.
Moby erbringt keine Vorleistung (die 80% könnte er nämlich leisten),
bleiben also 100% beim C-Programmierer hängen.
100% Arbeit für die Katz? Nein!
Moby A. schrieb:> P. M. schrieb:>> Ich denke, das ist sehr typisches 8-Bit-MS(R). Könntest du das jetzt>> bitte mal in kurzen, kompakten, übersichtlichen Assembler-Code>> umwandeln?>> Klar könnte ich. Doch hättest Du mal lieber die Zeit wie K.H. in die> Übersetzung meines Projekts gesteckt, dann hätte ich längst vergleichen> können.
Soso. Du bist der, der behauptet, aber liefern sollen die andern.
Zudem will ich ja die Optimierungsmöglichkeiten von Assembler gegenüber
C sehen.
Moby A. schrieb:> Da habe ich Respekt und ich weiß aus betrieblicher Erfahrung, daß> Regelungen durchaus anspruchsvoll sein können.
Aber wohl bloss vom Hörensagen... ;-)
Sag mal: Was hast du überhaupt für eine Ausbildung? Ohne mindestens ein
FH-Studium oder ein paar Jahre Berufserfahrung als Software-Entwickler
kann man dich hier dann wirklich überhaupt nicht mehr ernst nehmen.
P. M. schrieb:> Sag mal: Was hast du überhaupt für eine Ausbildung?
Was für eine Rolle sollte das denn spielen?
Er hat einfach in erster Linie eine Überzeugung, und ansonsten
natürlich die interessante Gabe, alles, aber auch alles, was gesagt
wird, zu seinen Gunsten und als Bestätigung seiner Überzeugung
auszulegen.
Für die Sachen, wo er mit seiner Strategie an seine Grenzen stößt,
kauft er dann einfach was dazu. Das passt offensichtlich dennoch
mit seiner Überzeugung zusammen …
P. M. schrieb:> Sag mal: Was hast du überhaupt für eine Ausbildung? Ohne mindestens ein> FH-Studium oder ein paar Jahre Berufserfahrung als Software-Entwickler> kann man dich hier dann wirklich überhaupt nicht mehr ernst nehmen.
Er ist Hobbyprogrammierer und hat den ASM-Befehl EOR vor etwa 4 Jehren
kennengelernt:
Beitrag "Re: AVR/ASM: Bit in Register invertieren"
Aber wie Jörg schon sagt: Die Ausbildung bzw. der Beruf spielt hier
überhaupt keine Rolle.
Moby A. schrieb:> Karl H. schrieb:>> Das müsste eine ziemliche 1:1 Umsetzung des fraglichen Assembler Codes>> sein.>> Was hindert Dich daran, daraus einen vollständigen Programmcode zu> machen den ich überprüfen kann?
Weil es mich ehrlich gesagt überhaupt nicht wirklich interessiert. Du
weigerst dich ja auch beharrlich auf meinen Vergleichs-Vorschlag
einzugehen.
Dabei würde es mich wirklich interessieren, was ein guter Assembler
Programmierer aus meiner schnell hingeschusterten Heizungssteuerung noch
rausholen kann. Nicht das es wichtig wäre. Sie passt in den Mega16, ist
schnell genug, ich hab kein Problem damit und die Benutzersteuerung ist
für meine Begriffe komfortabel genug. Ob die Zykluszeit da um 2
Millisekunden schneller ist oder nicht ist also völlig uninteressant und
für 20 Bytes weniger Flash Verbrauch kann ich mir auch nichts kaufen.
Die 2 investierten Samstag Nachmittage haben sich dann auch im Rahmen
gehalten. Nur mit einem kann ich nicht dienen: Du wirst nicht nur mit
den AVR-Registern auskommen sondern wirst dir ein Konzept zur
Registerbenutzung überlegen müssen.
P. M. schrieb:> Sag mal: Was hast du überhaupt für eine Ausbildung? Ohne mindestens ein> FH-Studium oder ein paar Jahre Berufserfahrung als Software-Entwickler> kann man dich hier dann wirklich überhaupt nicht mehr ernst nehmen.
Na das mußt Du mir erklären.
Ich konnte bisher zwischen Fähigkeit und erfolgreich abgeschlossenem
Studium seltenst einen kausalen Zusammenhang finden.
Michael K. schrieb:> Na das mußt Du mir erklären.> Ich konnte bisher zwischen Fähigkeit und erfolgreich abgeschlossenem> Studium seltenst einen kausalen Zusammenhang finden.
Naja...Regelungstechnik oder richtiges Software-Design lernt man
jedenfalls nicht an der Hauptschule und auch nicht wirklich on-the-job.
Und falls keinerlei Zusammenhang besteht zwischen Ausbildung und
Fähigkeit, warum sollte man dann überhaupt studieren? Warum sollte man
(teure) Hochschulabsolventen einstellen, wenn deren Ausbildung nix wert
ist?
Jörg W. schrieb:> P. M. schrieb:>> Sag mal: Was hast du überhaupt für eine Ausbildung?>> Was für eine Rolle sollte das denn spielen?
In so einer Diskussion interessiere ich mich irgendwann auch für den
Hintergrund, den eine Person mitbringt. Wenn ein Uni-Professor etwas
sagt, was für mich unglaubwürdig klingt, dann betrachte ich es aus
anderen Augen, als wenn ein Gymnasiast das selbe erzählt. Aktuell ist
das zwar nicht gerade in Mode, Hinz und Kunz mit ihrem
Hauptschulabschluss fühlen sich schnell beleidigt, wenn man ihnen
weniger 'credibility' zumisst als gebildeteren Leuten.
>P. M. schrieb:>> Sag mal: Was hast du überhaupt für eine Ausbildung?>Was für eine Rolle sollte das denn spielen?
So ganz uninteressant ist es nicht. Zumindest aus dem Bereich wo er
beruflich tätig ist. Mit SW Entwicklung offensichtlich nicht.
>Dass das rein sein Hobby ist,
Ich fahre auch gern in meiner Freizeit mit meinem Mountainbike auf
Radwegen herum. Das ist nicht sehr effektiv, aber muss es ja nicht.
Zumindest würde ich aus meinem Verhalten nie gegen Rennräder wettern,
das diese zum Fahrradfahren nicht nötig seien. Ein Mountainbike reiche
doch.
Matthias L. schrieb:> Zumindest würde ich aus meinem Verhalten nie gegen Rennräder wettern,> das diese zum Fahrradfahren nicht nötig seien. Ein Mountainbike reiche> doch.
Er sagt halt:
"Mein Montainbike kann keiner überholen - ein Rennrad schon gar nicht."
Obwohl er eher auf einem Dreirad als einem Mountainbike unterwegs ist.
Notfalls lässt er sich von einem Porsche (XPORT) abschleppen und sagt:
"Seht her! Ich fahre Autobahn (IoT) mit einem Dreirad!"
Alles eine Frage der Wahrnehmung.
P. M. schrieb:> In so einer Diskussion interessiere ich mich irgendwann auch für den> Hintergrund,
Mir war nur dieser Text zu provokativ.
> Ohne mindestens ein> FH-Studium oder ein paar Jahre Berufserfahrung als Software-Entwickler> kann man dich hier dann wirklich überhaupt nicht mehr ernst nehmen.P. M. schrieb:> warum sollte man dann überhaupt studieren?
Weil es vieles einfacher macht wenn man in dem Bereich arbeiten will und
Personalchefs sowas sehen wollen.
P. M. schrieb:> Warum sollte man> (teure) Hochschulabsolventen einstellen, wenn deren Ausbildung nix wert> ist?
Eine berechtigte Frage.
Ich sage nur das das Studium zu bestehen nicht viel darüber aussagt wie
gut man als Entwickler geeignet ist.
Gute und Schlechte gibt es mit und ohne Studium.
Michael K. schrieb:> P. M. schrieb:>> warum sollte man dann überhaupt studieren?> Weil es vieles einfacher macht wenn man in dem Bereich arbeiten will und> Personalchefs sowas sehen wollen.
Und warum wollen sie es sehen? Weil es für sehr viele
Entwicklungsaufgaben schlicht unentbehrlich ist! Klar - ein bisschen C
und Elektronik zusammenstiefeln, das kann auch einer mit Abitur oder
Berufsausbildung. Und wer sowieso mehr Projektmanagement als Technik
macht, der braucht nicht unbedingt klassischen Fähigkeiten aus dem
Studium. Aber für sehr viele gehobene Entwicklungsaufgaben geht's ohne
Studium einfach nicht. Und ich finde, auch in einer Fachdiskussion (wie
wir es hier zumindest formell haben) gehört ein gewisses theoretisches
Fundament dazu. Klar, das hören diejenigen nicht gern, die alles
on-the-job gelernt haben...
P. M. schrieb:> Klar, das hören diejenigen nicht gern, die alles on-the-job gelernt> haben...
Richtig.
Ich habe von Programmierung auch nichts im Studium gelernt, falls es
dich beruhigt, wenn man mal von einer Pascal-Lehrveranstaltung
absieht. Aber die war nur pro Forma, um einen Abschluss zu haben
(den ich gegen was anderes „kaubeln“ konnte), denn zu diesem Zeitpunkt
konnte ich Pascal bereits fließend. (*)
Dass ich dann das vormalige Hobby zum Beruf gemacht habe, lag an der
politischen und ökonomischen Entwicklung hier nach der Übernahme der
DDR – Elektroniker brauchte gerade niemand, Programmierer schon.
(*) Anekdote dazu: Ich war auch nie zur Lehrveranstaltung, habe mich
dem Vorlesenden anfangs mal vorgestellt und meine Motivation
erläutert. Zum Praktikum war ich (hat ja Spaß gemacht), und er hat
sich anschließend bedankt, dass er von mir einige Details seines
GRW-Pascals lernen konnte. ;-) „Ja, ich weiß, normalerweise
funktioniert das in die andere Richtung, aber warum nicht mal so?“
Moby A. schrieb:> Die Vorahnung, daß es mit 1:1 oder dem> Ressourcenbedarf doch nicht so weit her ist ?
Daß ich das noch erleben darf: Männer, die streiten, wer den Kürzesten
hat.
Moby A. schrieb:> Wie das Shifting mit dem Divisionsergebnis zusammenhängt ist aber auch> sowas von schwer zu merken
Das Konzept "sich etwas merken müssen" widerspricht dem von Dir
behaupteten Konzept "ist alles ganz einfach".
P. M. schrieb:> Und warum wollen sie es sehen? Weil es für sehr viele> Entwicklungsaufgaben schlicht unentbehrlich ist!
Wenn Du es sagst.
Was machen wir jetzt mit den guten Entwicklern ohne Abschluss ?
Müssen die jetzt den Hof fegen weil deren Job nun von jemanden gemacht
wird der brav alles auswendig gelernt hat um die Scheine zu bekommen,
dem aber der Biss und die Fantasie fehlt knifflige Probleme zu lösen ?
Was haben eigentlich die Softwarepioniere gemacht bevor es den
Studiengang überhaupt gab ?
Klar, das Studium sollte viele nützliche Dinge vermitteln.
Ob dieses Wissen auf fruchtbaren Boden fällt oder nicht ist ungewiss.
70% dessen was man später im Berufsleben braucht vermittelt aber kein
Studium, kann kein Studium vermitteln.
Das Studium vermittelt 'Momentaufnahmen' der jeweils aktuellen
Entwicklung. Aktuell heißt dann oft jahrealtes Wissen eines Profs.
Danach kommen aber nochmal 40Jahre Berufsleben.
Da ist mir jemand lieber der das leidenschaftlich tut und sich aus Lust
an der Freude alles beibringt was er jeweils braucht um das Projekt
durchzuziehen.
Jörg W. schrieb:> Dass ich dann das vormalige Hobby zum Beruf gemacht habe, lag an der> politischen und ökonomischen Entwicklung hier nach der Übernahme der> DDR – Elektroniker brauchte gerade niemand, Programmierer schon.
Erinnert mich an den Witz der 'hier im Westen' umging.
Frage: Wo sitzen die besten Programierer der Welt ?
Antwort: In der DDR. Niemand kann mehr aus 8bit / 64K herausholen.
Michael K. schrieb:> der brav alles auswendig gelernt hat um die Scheine zu bekommen
Hast du überhaupt studiert? Hast du eine Ahnung, was man in einem
Studium lernt? Oder basiert deine Meinung einfach darauf, dass du ein
paar Mal die Freude erleben durftest, etwas zu können, was ein
Studierter nicht konnte?
P. M. schrieb:> Hast du überhaupt studiert?
Komm mal wieder runter. Darum geht's in diesem Thread nicht.
Im Gegensatz zu dir postet Michael hier übrigens nicht nur mit vollem
Namen, sondern auch mit dem seiner Firma, und wenn du einfach nur mal
reinguckst, was sein Laden so macht, dann weißt du, dass er da nicht
nur irgendwelche „Zufallstreffer“ landet.
Jörg W. schrieb:> Komm mal wieder runter. Darum geht's in diesem Thread nicht.
Sehe ich genauso. Ob man sein Fach tatsächlich an einer Hochschule
studiert hat oder nicht, ist vollkommen nebensächlich.
Ein Studium mag für viele von persönlichem Vorteil sein, weil man da
lernt zu lernen. Aber was bzw. welches Fach man da lernt, ist nicht
unbedingt das, was man später mal macht. Das kann man sich später auch
autodidaktisch, d.h. im "Selbststudium" aneignen. Gerade das Internet
bietet dafür heutzutage fast unbegrenzte Möglichkeiten.
Aber: hier ist das offtopic.
Moby A. schrieb:> A. K. schrieb:>> Vergleiche jenseits von 8 Bits sind nicht seine starke Seite>> cp+cpc Jungs, so einfach ist das ;-)
*ROFL*
Unser Moby ist einfach Weltklasse!
Gibt sich hier als Macker und Assembler-Versteher, wobei hier fast jeder
seine armselige Vorstellung diesbezüglich live miterleben durfte.
Zur Erinnerung: Rein aus Neugier wollte ich wissen, wie er einen 32-Bit
Wert gegen eine Konstante vergleicht; immerhin eine kurze, überschaubare
und klar formulierte Aufgabe, die durchaus in 4-5 Instruktionen machbar
ist:
Beitrag "Re: C versus Assembler->Performance"
Nachdem sich Moby in gewohnter Geschmeidigkeit um eine konkrete Antwort
drückte, wartete er schließlich mit einer 9 Instruktionen langen Sequenz
auf — die falsch war. Die korrigierte Version war dann 12 Instruktionen
lang!
Okay, geschenkt. Moby hat ja gerne mal nen "langen" Tag, und auch mit
"Vorbereitung, Erfahrung und System" ist unser Assembler-Papst nicht
unfehlbar. Un dimmerhin hat er in dem Thread einen Zweck von CPC und
SBCI gelernt.
Viel bezeichnender fand ich, dass er — noch bevor er seine eigene Lösung
für das Nobelpreis-würdige Problem präsentierte — darauf hingewiesen
wurde, dass GCC nur 4-5 Instruktionen braucht und dies dann als
AUSGESCHLOSSEN klassifizierte:
Beitrag "Re: C versus Assembler->Performance"
Mobys Code ist also IMMER optimal, weil ihm nämlich grad nix besseres
eingefallen ist.
L'ASM, c'est moi!
Da kann man echt nur froh sein, dass er ASM-Populist als Hobby hat und
nicht in die Politik gegangen ist.
Jörg W. schrieb:> Komm mal wieder runter. Darum geht's in diesem Thread nicht.
Die Nebendiskussion wurde von dir und Michael gestartet, nicht von mir.
Ich habe bloss gefragt, ob Moby denn überhaupt einen entsprechenden
Hintergrund hat - Studium oder Berufserfahrung. Berufserfahrung explizit
eingeschlossen.
Warum fühlt ihr euch so angegriffen, sobald der Begriff "Studium" fällt?
Ich glaube absolut, dass Michael und du auch ohne Studium beruflichen
Erfolg haben können, keine Frage. Ich würde euch auch als Fachleute
nicht geringschätzen wegen fehlendem Studium. Aber ich sehe auch, dass
ich im Studium Dinge gelernt haben, die man im Berufsleben einfach nie
mehr lernt. Darunter sind durchaus auch Inhalte, die ich für meine
tägliche Arbeit brauche.
In meinem Fall zwar nicht im Bereich von Programmiersprachen, aber wer
mal in das Gebiet des Compilerbaus und der Programmiersprachen-Theorie
reingeschaut hat, der weiss, das dort beinharte theoretische Informatik
dahintersteckt, die man eigentlich nur via mehrjähriges Studium erwerben
kann.
P. M. schrieb:> wer mal in das Gebiet des Compilerbaus und der> Programmiersprachen-Theorie reingeschaut hat, der weiss, das dort> beinharte theoretische Informatik dahintersteckt, die man eigentlich nur> via mehrjähriges Studium erwerben kann.
Kann natürlich auch ein Selbststudium sein, aber Compilerbau ist etwas,
von dem ich auch die Finger lasse. Da beneide ich Johann für seine
vielen Ideen, die er umsetzen konnte.
Gehen wir mal anders an die Sache heran. Nachdem dieser Thread so
ausartet habe ich mir mal Moby's Sensor Thread zu Gemüte geführt.
Beitrag "Kleines Tiny13 Sensorboard"
Also das hoch effiziente ASM Programm holt zwei 10 BIT Analogwerte und
zwei Digitalwerte. Was passiert den mit den Werten ?
Weiter schreibst du...
>> Das heißt natürlich nicht, dass nun keine Erweiterungen denkbar wären.>> Das könnte zum Beispiel...>> - Vorverarbeitung der Messwerte>> - Prüfen auf Bedingungen>> - Ergänzen eines Schalttransistors
Ist doch ne Idee, mh, geht das denn ? Da braucht es doch dann Mathematik
die auf so kleinen MCs gar nicht hinzubekommen ist.
Also im Datenblatt steht:
– 1K Bytes of In-System Self-programmable Flash program memory
- 64 Bytes EEPROM
- 64 Bytes Internal SRAM
Puh, das wird eng :-(
Im gleichen Sensor Thread schreibst du dann...
>> 2) Lässt sich die Genauigkeit der ADU-Wandlung hier mit>> einfachen Mitteln weiter optimieren?
Und weiter in diesem Thread hier...
>> Die gebräuchlichsten Variablen sind absehbar eh nur Bytes und Words->> mehr braucht man höchstens bei selteneren Berechnungen.
Naja, dann probieren wir mal. Ein wenig Mathematik braucht es da schon
aber die hast du ja schon im Fundus.
Moby schreibt...
>> Bis 32 Bit hab ich fertige Routinen
Na dann los...
http://www.atmel.com/images/doc8003.pdfhttp://www.atmel.com/images/doc2559.pdf
Da steht wie es geht. Wenn dein Ausgabe Format denn eine Spannung,
Temperatur oder sonst was sein soll dann setz doch die ATMEL Tipps um.
Ach ja, ist vermutlich ne seltene Berechnung und vermutlich passt es in
den kleine Tiny nicht hinein.
Mein lieber Moby, dass sind keine seltenen Berechnungen sondern typische
Berechnungen. Ich kenne keinen einzigen Sensor der nicht Kalibriert ist.
Das gilt auch für typische Messungen. Glaubst du nicht ? Na dann ein
Beispiel hierzu.
Peda ist bekannt für seinen effizienten Assembler und C Code. In der
Codesammlung findet sich ein nettes Beispiel für eine 7 Segment
Anzeige...
Beitrag "ADC mit Multiplexanzeige"
Besser gesagt ein Voltmeter. Da ich faul bin bediene ich mich hier mal.
Seine „defines“ sind clever aufgebaut und so lässt sich das schnell an
meine Hardware anpassen und flux habe ich ein funktionierendes
Voltmeter. Das Ergebnis ist allerdings ein wenig ernüchternd. In den
angehängten Bildern (7Segment_PeDa1 – 3) sieht man wie sehr der Messwert
von dem vorgegebenen abweicht. 4.96V werden zu 4.62 usw. Das wird bei
deinen Messwerten nicht wesentlich anders aussehen. Besser gesagt, bei
dir bekomme ich nur den Wandler Wert selbst, nur durchgereicht.
Implementieren wir mal die AppNotes von Atmel. Das Ergebnis findet sich
in den Bildern 7Segment_1_kompensiert 1 – 3. Siehe da, es geht und auch
die letzte Stelle löst auf 1mV auf.
Also erzähl mir nicht das sei seltene Mathematik. Das wird so gut wie
immer benötigt. Mit der Codeergänzung kompiliert PeDa's Code zu 764
bytes. Das passt noch locker in deinen Tiny hinein.
Na dann los Moby, zeig mal was du kannst. Erweitere dein Programm mal um
die Kleinigkeit und zeig uns deinen hocheffizienten ASM code.
Wir können auch gerne andere Code Beispiele aus der Sammlung nehmen, die
Klassiker sind LCD + Co oder kleine Messgeräte aber komm mir nicht mit
deinem Assembler Fragment und stelle Vergleiche an.
Das waren jetzt Fakten Fakten Fakten, genau wie du es magst :-) und was
lernen wir daraus ? Codequalität liest man nicht an der
Programmiersprache ab sondern am Gesamtergebnis.
Immerhin habe ich mir die Mühe gemacht mein altes AVR Zeugs auszupacken
obwohl ich seit mehr als 6 Jahren keinen davon angefasst habe.
Compiliert habe ich mit der aktuellen Atmel Studio Version da ich nicht
mal eine IDE für AVR hatte. Also, auf geht’s, geb dir auch nen Ruck und
zeig mal was du kannst :-) Damit meine ich nicht ASM vs C sondern etwas
das durch seine Funktionalität besticht.
P. M. schrieb:> Warum fühlt ihr euch so angegriffen, sobald der Begriff "Studium" fällt?
Tue ich nicht.
Würdest Du bitte aber auch verstehen das ich darüber spreche das
Entwickler zu sein mit viel mehr zu tun hat als 'beinharte Theorie'
gelernt zu haben ?
Das Studium macht dich nicht gut und das Nichtstudium macht dich nicht
schlecht.
OT ist es ohnehin, aber wenigstens müsste dieses hier der 1000te Beitrag
in diesem Thread sein ;-)
Michael K. schrieb:> Würdest Du bitte aber auch verstehen das ich darüber spreche das> Entwickler zu sein mit viel mehr zu tun hat als 'beinharte Theorie'> gelernt zu haben ?> Das Studium macht dich nicht gut und das Nichtstudium macht dich nicht> schlecht.
Würdest du im Gegenzug verstehen, dass zumindest ein Teil dieser Theorie
ganz signifikant dazu beiträgt, ein sehr viel besserer Entwickler zu
werden oder sogar Grundvoraussetzung ist, um gewisse Problemstellungen
zu lösen? Ich habe im übrigen mit keinem Wort behauptet, ohne Studium
sei man ein schlechter Entwickler, durfte mir aber Sprüche anhören von
wegen "auswendig gelernt" und "nur den Schein holen".
P. M. schrieb:> durfte mir aber Sprüche anhören von> wegen "auswendig gelernt" und "nur den Schein holen".
[aufstöhn]
Nein, ich habe nur gesagt das es eben diese Kollegen AUCH gibt.
Großer Titel, nichts dahinter.
Ich kenne beide Varianten.
Dich kenne ich garnicht genug um mir anzumaßen etwas über Deine
Qualifiation zu sagen.
Können wir das jetzt bitte lassen ?
Wenn ich Dir zu nahe getreten bin dann tut es mit leid, das war nicht
meine Absicht und ich entschuldige mich dafür.
Michael K. schrieb:> Nein, ich habe nur gesagt das es eben diese Kollegen AUCH gibt.
Ja. Klar. Die gibts überall. Der Punkt ist, dass es - sobald es um
Studierte geht - jeweils explizit erwähnt werden muss. Wenn wir hier
über LKW-Führerscheine sprechen, dann wird ja auch keiner erwähnen, dass
es unter den LKW-Fahrern auch schwarze Schafe hat. Das irritiert und da
fühlt man sich in der Tat angegriffen, ja.
Aber ja, können wir gerne lassen. Die Suppe wird meist ja sowieso etwas
heisser gekocht als gegessen ;-)
P. M. schrieb:> Michael K. schrieb:>> Nein, ich habe nur gesagt das es eben diese Kollegen AUCH gibt.>> Ja. Klar. Die gibts überall. Der Punkt ist, dass es - sobald es um> Studierte geht - jeweils explizit erwähnt werden muss. Wenn wir hier> über LKW-Führerscheine sprechen, dann wird ja auch keiner erwähnen, dass> es unter den LKW-Fahrern auch schwarze gibt.
Der Unterschied ist nur, ohne Führereschein darf er nicht fahren. Ohne
Diplomurkunde programmieren dagegen schon.
Bernd N. schrieb:> Gehen wir mal anders an die Sache heran. Nachdem dieser Thread so> ausartet habe ich mir mal Moby's Sensor Thread zu Gemüte geführt.
Das ist sehr lobenswert, aber das hättest du dir sparen können.
Bernd N. schrieb:> Mit der Codeergänzung kompiliert PeDa's Code zu 764> bytes.
Das beweist nur die Überlegenheit von effizientem Asm-Code.
Und das:
Bernd N. schrieb:> Na dann los Moby, zeig mal was du kannst. Erweitere dein Programm mal um> die Kleinigkeit und zeig uns deinen hocheffizienten ASM code.
wird er auf gar keinen Fall machen. Denn es ist keine typische
8-Bit-Asm-Anwendung.
Frag mich nicht warum. Ich programmiere auf 8-Bittern nur untypische
Anwendungen.
mfg.
Moby A. schrieb:> Die meisten können schon das bischen> Tiny-Code meines Projekts nicht nachvollziehen, obwohl sie hier große> Reden schwingen ;-)
Ich kann deinen ASM Quellcode nicht nachvollzienen, weil ich andere µC
benutze. Aber um jetzt themenabschließend für mich den Vergleich zu
ziehen, habe ich die Funktion deines Sensorboards anhand der
Funktionsbeschreibung im Kommentarteil auf einem kleinen PIC12F675
nachzuprogrammiert.
Hier mein QuD Entwurf. Von der Funktion müsste eigentlich alles aus dem
Tiny-Projekt drin sein, oder?
Wobei ich bei der CRC unsicher bin, weil sich dazu die
Funktionsbeschreibung ausschweigt. Es wird von allen Nutzbytes die Summe
gebildet und die zwei LSB bits übertragen, richtig?
1
#include<xc.h>
2
#include<stdint.h>
3
4
// CONFIG
5
#pragma config FOSC = INTRCIO // Oscillator Selection bits (INTOSC oscillator: I/O function on GP4/OSC2/CLKOUT pin, I/O function on GP5/OSC1/CLKIN)
6
#pragma config WDTE = OFF // Watchdog Timer Enable bit (WDT disabled)
7
#pragma config PWRTE = OFF // Power-Up Timer Enable bit (PWRT disabled)
8
#pragma config MCLRE = OFF // GP3/MCLR pin function select (GP3/MCLR pin function is digital I/O, MCLR internally tied to VDD)
9
#pragma config BOREN = ON // Brown-out Detect Enable bit (BOD enabled)
10
#pragma config CP = OFF // Code Protection bit (Program Memory code protection is disabled)
11
#pragma config CPD = OFF // Data Code Protection bit (Data memory code protection is disabled)
12
13
#define _XTAL_FREQ 4000000
14
#define clockpin GPIObits.GP4
15
#define datapin GPIObits.GP5
16
17
voidInitMCU(void){
18
GPIO=0;
19
CMCON=0x07;// Comparator off
20
ADCON0bits.ADFM=1;// Rigth justified
21
ADCON0bits.VCFG=0;// Vref = Vdd
22
ADCON0bits.ADON=1;// A/D on
23
24
ANSELbits.ADCS=0b101;// TAD = 4µs
25
ANSELbits.ANS=0b0011;// AN0,AN1
26
TRISIO=0b001111;
27
28
}
29
30
voidad_acq(uint8_tchs){
31
ADCON0bits.CHS=chs;
32
__delay_us(20);
33
ADCON0bits.GO=1;
34
while(ADCON0bits.GO_nDONE){;}
35
}
36
37
voidsendByte(uint8_ts){
38
uint8_tmask=0b10000000;
39
while(mask){
40
if(s&mask)
41
datapin=1;
42
clockpin=1;
43
__delay_ms(5);
44
clockpin=0;
45
datapin=0;
46
mask>>=1;
47
__delay_ms(5);
48
}
49
}
50
51
voidmain(void){
52
uint8_ttmpByte3,crc;
53
54
InitMCU();
55
while(1){
56
__delay_ms(80);
57
58
// AD Channel 0
59
ad_acq(0);// Analog Channel 0 lesen
60
sendByte(ADRESL);
61
crc=ADRESL;
62
tmpByte3=ADRESH;
63
64
// AD Channel 1
65
ad_acq(1);// Analog Channel 1 lesen
66
sendByte(ADRESL);
67
crc+=ADRESL;
68
tmpByte3|=ADRESH<<2;//
69
70
// send Byte 3 with CRC
71
tmpByte3|=(GPIO&0b00001100)<<2;// Digitaleingänge in Bits 4,5 speichern
72
crc+=tmpByte3;
73
tmpByte3|=(crc&0b00000011)<<6;
74
sendByte(tmpByte3);
75
}
76
}
Der XC8 (free mode) übersetzt das zu 164 Befehlsworten und 10
Datenbytes. Der PIC12F675 ist damit zu 16% gefüllt, sowohl Flash als
auch Datenspeicher. Das C-Projekt ließe sich das sogar auf einen
PIC10F220 ausführen.
Mein Fazit in dem Fall: No Need For Assembler!
Johann L. schrieb:> Moby A. schrieb:>> A. K. schrieb:>>> Vergleiche jenseits von 8 Bits sind nicht seine starke Seite>>>> cp+cpc Jungs, so einfach ist das ;-)>> *ROFL*
Ging mir exakt genauso :D
DAS sind genau die Stellen, die die Moby-Threads so herrlich amüsant
machen :)
Vielen Dank für die vielen interessanten Beiträge in der Zwischenzeit.
Ich fang mal von hinten an:
Witkatz :. schrieb:> habe ich die Funktion deines Sensorboards anhand der> Funktionsbeschreibung im Kommentarteil auf einem kleinen PIC12F675> nachzuprogrammiert
Schau einer an. Wie das auf einmal geht wenn man nur will...
> Es wird von allen Nutzbytes die Summe> gebildet und die zwei LSB bits übertragen, richtig?
Nein, alle 1er Bits werden schlicht gezählt und die zwei
niederwertigsten Bits der Summe dann drangehängt. Das wurde allerdings
erst später im Thread so geändert weil auf Hinweis von Yalu die einfache
Summe etwas witzlos ist. Zu finden später im Projektthread.
> Mein Fazit in dem Fall: No Need For Assembler!
Mein Fazit:
> 10> Datenbytes
...zu viel. Was die Vergleichbarkeit von PIC-und Asm Code betrifft bin
ich auch gerade auch etwas überfragt. Aber danke für Deinen ernsthaften
Beitrag. Leider kann ich auch die Funktion mangels C-Kenntnissen nicht
nachvollziehen und habe keine PIC-Hardware zum Testen.
Vielleicht sollte man dazu wissen, daß die 10 Datenbytes beim AVR
Register genannt werden. Der Pic12F220 hat nämlich nur 16 Bytes im
Registerfile. Also effektiv 10 Register und NULL Byte RAM.
Carl D. schrieb:> Vielleicht sollte man dazu wissen,
Ok, hab mir das nicht so genau angeschaut, kann zum PIC und zu PIC-Asm
Code jetzt wenig sagen. Was den AVR betrifft hatte ich ja
freundlicherweise alle Register zur Verwendung freigegeben, mein Code
nutzt derer 11. Nur bei diesem kann ich das Ergebnis wirklich
nachprüfen.
Moby A. schrieb:> Leider kann ich auch die Funktion mangels C-Kenntnissen
Ach...du hast gar keine C-Kenntnisse? Wie kannst du dann überhaupt
irgendwelche Aussagen dazu machen?
Moby A. schrieb:> Ok, hab mir das nicht so genau angeschaut, kann zum PIC und zu PIC-Asm> Code jetzt wenig sagen.
"Dazu kann ich jetzt wenig sagen" - das ist alles? Diverse Leute haben
jetzt mehrfach geliefert, aber du selbst kannst weder zu diesen
Beispielen etwas vernünftiges sagen, noch ein C-Beispiel effizienter in
Assembler implementieren. Von dir kommt einfach rein gar nichts ausser
Sprüche.
Moby:
> Ok, hab mir das nicht so genau angeschaut, kann zum PIC und> zu PIC-Asm Code jetzt wenig sagen.
Ich habe auch noch nie einen PIC in den Fingern gehabt, aber kenne
trotzdem dessen grobes Design und dann gibt's da noch das berühmte
Datenblatt, 2 Clicks entfernt im Netz.
Besonders wenn man was vergleichen will, ist es besser mindestens zwei
Dinge zu kennen. OK, ich vergaß: Es kann nur Einen geben.
P. M. schrieb:> aber du selbst kannst weder zu diesen Beispielen etwas vernünftiges> sagen
Du musst ihm nun schon den fertig programmierten PIC mit einer
Bedienungsanleitung hinschicken, damit er verifizieren kann, ob
der Beitrag seine Bedingungen erfüllt.
le x. schrieb:> Ach, und "==" ist kryptischer als cp/cpc? Was soll das sein?> Chickenpizza/Chickenpizza-Curry?! Das Zeichen "=" ist in der Regel aus> der Grundschule bekannt.
Ach Herr je, wenns mal bloß das "==" wär ;-)
> Man verzeihe mir bitte meine Unsachlichkeit, aber jetz muss ich mal blöd> fragen:> Moby, glaubst du die Scheiße die du hier verzapfst eigentlich wirklich> selbst?
Einen Glauben würde ich als rationaler Mensch nicht so vehement
verteidigen ;-) Du solltest bitteschön sachlich bleiben- mit Deiner
Wortwahl erreichst Du eher: Nichts!
P. M. schrieb:> Ach...du hast gar keine C-Kenntnisse?
Wusstest du das nicht?
P. M. schrieb:> Wie kannst du dann überhaupt> irgendwelche Aussagen dazu machen?
Er gibt das wieder, was er irgendwo aufgeschnappt hat.
P. M. schrieb:> Von dir kommt einfach rein gar nichts ausser> Sprüche.
Das ist ihm egal.
mfg.
Jörg W. schrieb:> P. M. schrieb:>> aber du selbst kannst weder zu diesen Beispielen etwas vernünftiges>> sagen>> Du musst ihm nun schon den fertig programmierten PIC mit einer> Bedienungsanleitung hinschicken, damit er verifizieren kann, ob> der Beitrag seine Bedingungen erfüllt.
Tja hilft nix. In Pic werde ich mich jetzt sicher nicht einarbeiten.
Und was heißt schon "meine Bedingungen". Die Funktion ist eindeutig,
woran zu sparen ist auch ;-)
P. M. schrieb:> "Dazu kann ich jetzt wenig sagen" - das ist alles? Diverse Leute haben> jetzt mehrfach geliefert, aber du selbst kannst weder zu diesen> Beispielen etwas vernünftiges sagen, noch ein C-Beispiel effizienter in> Assembler implementieren. Von dir kommt einfach rein gar nichts ausser> Sprüche.
Nun mal langsaaam... Auch Du liest und beantwortest zig Beiträge nicht
in ein paar Minuten.
Carl D. schrieb:> Besonders wenn man was vergleichen will, ist es besser mindestens zwei> Dinge zu kennen. OK, ich vergaß: Es kann nur Einen geben.
Moby scheint nicht mal C zu können, weiss aber, dass Assembler besser
ist... (Bin jetzt gespannt, wie er mir das "besser" im Mund umdreht.)
Moby A. schrieb:>> Man verzeihe mir bitte meine Unsachlichkeit, aber jetz muss ich mal blöd>> fragen:>> Moby, glaubst du die Scheiße die du hier verzapfst eigentlich wirklich>> selbst?>> Einen Glauben würde ich als rationaler Mensch nicht so vehement> verteidigen ;-) Du solltest bitteschön sachlich bleiben- mit Deiner> Wortwahl erreichst Du eher: Nichts!
Doch, obige Frage ist sowas von berechtigt. Seit über 1000 Beiträgen
lässt du dich nun nach Strich und Faden zerpflücken. Wirklich, meinst du
das alles ernst oder verarschst du uns einfach? Falls du wirklich mit
uns spielst, so könntest du das als fairer Sportsmann nach so vielen
Beiträgen auch mal zugeben. Falls du nicht spielst...gute Nacht.
Moby A. schrieb:> Nun mal langsaaam... Auch Du liest und beantwortest zig Beiträge nicht> in ein paar Minuten.
Das C-Beispiel ist seit gestern oder vorgestern gestellt und war in ein
paar Minuten geschrieben. Sollte in Assembler doch auch eine kurze Sache
sein, und dann hättest du den Beweis ja erbracht. Also warum nicht?
P. M. schrieb:> als fairer Sportsmann
Ach Du meine Güte. Von fairem Sportsgeist mit Betonung auf 'fair' könnte
ich ja hier auch ein Liedchen singen. Nein im Ernst, die Hoffnung darauf
sollte man in einem solchen Forum schnellstens begraben. Du kannst aber
davon ausgehen, daß mir das Thema als langjährigem ASMler schon am
Herzen liegt. Freilich ist die Materie offensichtlich so schnell nicht
durchdiskutiert. Deshalb brachte ich gleich ein fertiges Beispiel mit
klar definierten Vergleichsmerkmalen. Das kann man nun mit einem
C-Beispiel toppen oder man kann es eben nicht.
> Moby scheint nicht mal C zu können, weiss aber, dass Assembler besser> ist... (Bin jetzt gespannt, wie er mir das "besser" im Mund umdreht.)
Für ein Urteil zum Ressourcenverbrauch langt schon mal locker der Blick
auf die Fakten, für ein Urteil zum bürokratischen Aufwand langt ein
Blick in jedes C-Buch. Für ein Urteil des Handlings beim Erarbeiten von
Lösungen langt ein längerer Selbstversuch. Das Ganze garniert mit
vielen netten Infos u.a. von Fachkundigen hier aus dem Forum. Für
inmundige Umdreherei bin ich allerdings kein Experte, da sind andere
besser ;-)
Robert L. schrieb:> das ist sinnlos, wir kenne doch schon alle seine Ausreden, warum> er die> ASM version dazu nicht abliefern würde...
Nochmal ganz klar zum Mitschreiben: Ich liefere hier keine Lösungen
für weitere Aufgaben. Spart Euch die Ablenkungsmanöver und kreativen
Ausreden. Es gilt mein Beispiel zu toppen. Ich möchte ein fertiges
Gegenbeispiel, daß ich selbst kompilieren und auf Funktion testen kann.
Danach investiere ich gern mal meine beschränkte Zeit für angeblich so
C-vorteilhafte Beispiele wie den gleitenden Durchschnitt usw.usf.
Ich finde es ja ohnehin hochnotpeinlich, wieviele gestandene
C-Programmierer hier viele gewichtige Worte verlieren aber ein Beispiel
simpelster Funktionalität mit dem angeblich so hochprodukiven C für den
easy AVR nicht codiert bekommen. Dafür darf ich dann kreativste Ausreden
und Schlimmeres entgegennehmen.
Robert L. schrieb:> Ist ja wie im Kindergarten.
Na immerhin noch einer mit Unterhaltungswert ;-)
P. M. schrieb:> Eine bessere Spec als einen kompletten Quellcode kann es gar nicht> geben, denn der definiert eindeutig was das Programm tun muss. Und in> diesem einfachen Fall kann man den Code in 2-5 Minuten durchlesen und> komplett verstehen. Zusätzlich hat es sogar noch Kommentare, die den> Code einzelne Abschnitte zusammenfasst. Wenn das nicht ausreicht als> Vorgabe, dann weiss ich auch nicht mehr weiter...
Lustig. Das hatte ich auch schon mal angenommen. Wie utopisch. Daß dann
aber weder meine wörtliche Beschreibung mit klarem Output-Diagramm als
auch die >300 Beiträge meines Projektthreads nicht zum vollständigen
Verständnis des bischen Funktion langen hätte ich dann doch nicht zu
träumen gewagt ;-)
P. M. schrieb:> Ohne mindestens ein> FH-Studium oder ein paar Jahre Berufserfahrung als Software-Entwickler> kann man dich hier dann wirklich überhaupt nicht mehr ernst nehmen.
Meine funktionierenden Projekte darfst Du ernst nehmen.
Das tust Du offensichtlich ja auch sonst wärst Du hier nicht weiter
munter dabei ;-)
Karl H. schrieb:> Weil es mich ehrlich gesagt überhaupt nicht wirklich interessiert. Du> weigerst dich ja auch beharrlich auf meinen Vergleichs-Vorschlag> einzugehen.> Dabei würde es mich wirklich interessieren, was ein guter Assembler> Programmierer aus meiner schnell hingeschusterten Heizungssteuerung noch> rausholen kann.
Das hatte ich schon befürchtet, daß zur vollständigen Funktionalität
Deines Codes noch einiges fehlt. Die Frage ist warum Du überhaupt damit
angefangen hast. Interessieren tut hier nur eine vollständige,
vergleichbare Lösung. Privat hätte ich auch so manches zu vergeben ;-)
> Du wirst nicht nur mit> den AVR-Registern auskommen sondern wirst dir ein Konzept zur> Registerbenutzung überlegen müssen.
Hatte ich das nicht schon? Was hälst Du denn von meinem Konzept?
Für meine Begriffe ist es das sinnvollste...
Bernd N. schrieb:> Also das hoch effiziente ASM Programm holt zwei 10 BIT Analogwerte und> zwei Digitalwerte. Was passiert den mit den Werten ?
Lass Dir die Funktion im Projektthread erklären.
> Weiter schreibst du...>>> Das heißt natürlich nicht, dass nun keine Erweiterungen denkbar wären.>>> Das könnte zum Beispiel...>>> - Vorverarbeitung der Messwerte>>> - Prüfen auf Bedingungen>>> - Ergänzen eines Schalttransistors> Ist doch ne Idee, mh, geht das denn ? Da braucht es doch dann Mathematik> die auf so kleinen MCs gar nicht hinzubekommen ist.
Du meine Güte, was denn für großartige Mathematik?
Im Flash ist für obige Funktionalität noch 80% Platz frei. Damit lässt
sich absolut was anfangen. Natürlich kann man jetzt Anforderungen
beliebig hochschrauben- wie fantasievoll.
Wenn es Dir an selbiger für den noch freien Platz fehlt kann ich Dir
aber leider nicht helfen. Irgendwann hat jeder MC seine Grenze,
vermutlich kennst Du auch nur fetten C-Code !?
Wie Du dem Projekt entnehmen konntest handelt es sich primär nur um
einen Zubringer zu einem größeren System mit dem Sinn, zwei analoge
10-bittige (und zwei digitale) Messwerte über ein längeres,
ungeschirmtes Kabel verfügbar zu machen.
Frank M. schrieb:> Er ist Hobbyprogrammierer und hat den ASM-Befehl EOR vor etwa 4 Jehren> kennengelernt:
Erstmalig benötigt. Tatsächlich ist eben eine Teilmenge der
AVR-Instruktionen zumeist ausreichend. Wußtest Du natürlich vorher.
Frank M. schrieb:> Das heisst, Du bekommst jedes erdenkliche "typische 8-Bit-Programm" in> einen Tiny13 gequetscht, weil Du in ASM programmierst? Du brauchst also> niemals mehr den Prozessor wechseln? Es passt alles in einen Tiny13?
Es passt alles in AVRs- vom Tiny bis zum Xmega. Hattest Du gerade wieder
vergessen.
Frank M. schrieb:> Man kann an seiner Aussage nicht nur seinen persönlichen Horizont> erkennen, sondern auch deren Schwachsinnsgehalt.
Ich finde ja reichlich schwachsinnig, wie Du ohne Unterlaß nicht nur
mein Projekt mit sinnlosen Einwürfen zu torpedieren versuchst, permanent
die gleichen dämlichen Unterstellungen machst und mich wo es nur irgend
geht lächerlich machen möchtest. Mit etwas mehr Horizont hättest Du
längst erkannt, daß damit nichts Konstruktives zu erreichen ist. Versuch
doch Mod zu werden, dann darfst Du endlich Asm-Beiträge nach Belieben
löschen und Asm-Threads beenden... Die lassen Deinen fetten C-Code
einfach zu schlecht aussehen ;-)
Moby A. schrieb:> vermutlich kennst Du auch nur fetten C-CodeMoby A. schrieb:> Deinen fetten C-Code
Woher bringt dich denn eigentlich immer zu dieser Annahme, C-Code sei
fett?
Ich dachte deine einzige C-Erfahrung war ein mehr oder weniger
gescheitertes DOS-Programm (also x86).
Hast du dir davon das Assembler-Listing angeschaut und
Verbesserungspotential entdeckt?
Falls du dieses Märchen hier aus dem Forum hast würd ich vorschlagen die
Beiträge hier weniger selektiv zu lesen.
Deine These mag sich auf Beiträgen von solch Gestalten wie unsren
c-hater, W.S. etc. stützen.
Dann frag ich mich aber wieso du soviel auf deren Meinung gibst,
Argumente von nachweislichen Experten die seit Jahrzehnten in beiden
Welten (eher: in zig Welten) unterwegs sind ignorierst.
Weils ins eigene Weltbild passt?
Moby A. schrieb:> Spart Euch die Ablenkungsmanöver und kreativen> Ausreden. Es gilt mein Beispiel zu toppen.
das mit dem x < 100000 meinst du, oder ;-)
die C-Version war im Ergebnis kürzer als deine ASM Version
Wenn also die Vorteile bei einem SOO kurzen Beispiel schon so glasklar
sind, brauchen wir uns über "größere" Projekte ja nicht zu unterhalten,
solange du keine bessere ASM lösung ablieferst..
le x. schrieb:> Woher bringt dich denn eigentlich immer zu dieser Annahme, C-Code sei> fett?
Das ist ein Axiom seines Weltbildes und somit unwiderlegbar.
>Bis 32 Bit hab ich fertige Routinen...
hier könnte man übrigens gut belegen dass ein C-Compilter besser im
Routinen aussuchen ist als du, aber das willst ja eh nicht wissen..
Moby A. schrieb:> Die lassen Deinen fetten C-Code> einfach zu schlecht aussehen ;-)
Diese Wahrnehmungsstörung erinnert mich ein wenig an Bulimiker. Die
können aussehen wie Haut und Knochen kurz vor dem Exitus, und empfinden
sich dennoch als fett.
P. M. schrieb:> Doch, obige Frage ist sowas von berechtigt. Seit über 1000 Beiträgen> lässt du dich nun nach Strich und Faden zerpflücken. Wirklich, meinst du> das alles ernst oder verarschst du uns einfach?
Ich habe schon öfter behauptet, dass er bewusst trollt.
Möglicherweise ist das aber gegen die Foremregeln, da es regelmäßig
gelöscht wurde???
Gu. F. schrieb:> Ich habe schon öfter behauptet, dass er bewusst trollt.
Meiner Meinung nach weiss er natürlich alles, was andere ihm
beizubringen versuchen, schon lange. Den Rest kann sich jeder denken.
> Möglicherweise ist das aber gegen die Foremregeln, da es regelmäßig> gelöscht wurde???
Wir löschten das nur dann, wenn er mit seiner Meinung in Threads
auftauchte, die damit nichts zu tun hatten.
Hier darf er gerne schreiben.
Edit:
Noch vergessen: ;-) ;-) ;-)
Thread beobachten
Seitenaufteilung abschalten