Assembler wieder auf dem Weg nach vorn

[Jörg W. (dl8dtl) (Moderator)]

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.

[Moby A. (moby-project)]

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 ;-)

[Johann L. (gjlayde)]

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?

[Moby A. (moby-project)]

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?

[Carl D. (jcw2)]

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.

[Moby A. (moby-project)]

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 ;-)

[Klaus W. (mfgkw)]

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.

[Moby A. (moby-project)]

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 ;-)

[Frank M. (ukw) (Moderator)]

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. (mfgkw)]

Moby A. schrieb:
> Hey, da hat einer das Prinzip verstanden!!!

Ich schon, nur du nimmst dafür einen AVR mit ASM!

[Moby A. (moby-project)]

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? ;-)

[P. M. (o-o)]

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.

[Moby A. (moby-project)]

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. (Firma: www.wolfgangrobel.de) (mikemcbike)]

Warum bist Du dann noch hier? Kanns ja ganz flott wieder raus geraten...

Die Diskussion ist sowas von sinnfrei, ich bekomme da keinen OrgASM...

[Moby A. (moby-project)]

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.

[Sheeva P. (sheevaplug)]

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". :-)

[Le X. (lex_91)]

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 ;-)

[Jörg W. (dl8dtl) (Moderator)]

le x. schrieb:
> Das ist mal ein gesundes Selbstbewusstsein ;-)

Yep, daran hatte er noch nie einen Mangel. :)

[Gu. F. (mitleser)]

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?

[Karl H. (kbuchegg)]

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.

[Le X. (lex_91)]

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

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

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.

[(prx) A. K. (prx)]

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.

[Le X. (lex_91)]

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 
:-)

[(prx) A. K. (prx)]

le x. schrieb:
> Wobei dieser Assembler für Moby wohl genauso ein Feindbild darstellt

Für mich auch. Ich finde diese Intel-Notation schaurig. ;-)

[Karl H. (kbuchegg)]

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.

    if( SIC & 0x30 ) {
      if( SIC & 0x01 )
      {
        if( Data & 0x01 )
          PORTB |= ( 1 << PB0 );
        else
          PORTB &= ~( 1 << PB0 );
        Data >>= 1;
      }
      PINB |= ( 1 << PB2 );
      SIC++;
      ADC1 = ADC2 = 0;
    }

    else {
      if( SIC & 0x08 )
        ADC2 += ADC;
      else
        ADC1 += ADC;

      if( ( SIC & 0x0F ) == 0x0F ) {
        Data = ADC1 / 8 + ( ADC2 / 8 ) << 10;

        if( PINB & ( 1 << PB1 )
          Data |= ( 1 << 20 );
        if( PINB & ( 1 << PB5 )
          Data |= ( 1 << 21 );

        CheckSum = ( Data & 0xFF ) + ( ( Data >> 8 ) & 0xFF ) + (( Data >> 16 ) & 0xFF );
        if( CheckSum & 0x01 )
          Data |= ( 1 << 22 );
        if( CheckSum & 0x02 )
          Data |= ( 1 << 23 );
      }

      SIC++;
      if( SIC & 0x08 )
        ADMUX = A2PINREF + 3;
      else
        ADMUX = A1PINREF + 2;
    }

[Gu. F. (mitleser)]

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.

[Karl H. (kbuchegg)]

le x. schrieb:

> Was ist an
>

> 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...

Das kannst du doch jemandem nicht vermitteln, der

        ldi    r16,$e0
        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? :-)

[P. M. (o-o)]

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:

void main(){
  
  uint8_t threshold = 89;

  uint8_t value_ptr = 0;
  uint8_t last_values[8] = {0, 0, 0, 0, 0, 0, 0, 0};

  ADC_CONFIG |= (1 << ADC_ON);
  UART_CONFIG = ...; // set some bits here
   
 
  while(true){
    if(ADC_STATUS & (1 << ADC_HAS_NEW_VALUE)){
      
      // save value into ringbuffer
      last_values[value_ptr] = ADC_VALUE;

      // increase ringbuffer pointer
      value_ptr ++;
      value_ptr = (value_ptr < 5) ? value_ptr : 0;

      // sum up values in ringbuffer
      uint16_t sum = 0;
      for(uint8_t i = 0; i < 8; i ++){
        sum += last_values[i];
      }

      // check if average in ringbuffer exceeds threshold
      // if yes, send over uart
      if(sum / 8 > threshold){
        UART_DATA = sum / 8; 
        UART_CONFIG |= (1 << UART_DO_SEND);
      }
  
    }
  }
}

Ich denke, das ist sehr typisches 8-Bit-MS(R). Könntest du das jetzt 
bitte mal in kurzen, kompakten, übersichtlichen Assembler-Code 
umwandeln?

[Wegstaben V. (wegstabenverbuchsler)]

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 ;-)

[(prx) A. K. (prx)]

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){

[Witkatz :. (wit)]

P. M. schrieb:
> value_ptr = (value_ptr < 5) ? value_ptr : 0;

warum 5?
wäre nicht

value_ptr %= 8;

 einfacher?

[Carl D. (jcw2)]

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.

[P. M. (o-o)]

Witkatz :. schrieb:
> P. M. schrieb:
>> value_ptr = (value_ptr < 5) ? value_ptr : 0;
>
> warum 5?
> wäre nicht

value_ptr %= 8;

 einfacher?

Tippfehler, sorry.

[P. M. (o-o)]

Korrigierte Aufgabenstellung für Moby:

void main(){
  
  uint8_t threshold = 89;

  uint8_t value_ptr = 0;
  uint8_t last_values[8] = {0, 0, 0, 0, 0, 0, 0, 0};

  ADC_CONFIG |= (1 << ADC_ON);
  UART_CONFIG = ...; // set some bits here
   
 
  while(true){
    if(ADC_STATUS & (1 << ADC_HAS_NEW_VALUE)){
      
      // save value into ringbuffer
      last_values[value_ptr] = ADC_VALUE;

      // increase ringbuffer pointer
      value_ptr ++;
      value_ptr %= 8;

      // sum up values in ringbuffer
      uint16_t sum = 0;
      for(uint8_t i = 0; i < 8; i ++){
        sum += last_values[i];
      }

      // check if average in ringbuffer exceeds threshold
      // if yes, send over uart
      if(sum / 8 > threshold){
        UART_DATA = sum / 8; 
        UART_CONFIG |= (1 << UART_DO_SEND);
      }
  
    }
  }
}

[Gu. F. (mitleser)]

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...

[Gu. F. (mitleser)]

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 ;-)

[Witkatz :. (wit)]

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:

0x7FF8: MOVLW 0x7
0x7FFA: ANDWF __pcstackCOMRAM, F, ACCESS

Wow, zwei Assemblerbefehle für eine Modulo Operation. Auf den Trick muss 
man als Assemblist erst mal kommen.

[Jörg W. (dl8dtl) (Moderator)]

Witkatz :. schrieb:
> Auf den Trick muss man als Assemblist erst mal kommen.

Assemblerprogrammierer kennen keinen Modulus, die kennen nur AND und
Bitmasken. ;-)

[Matthias L. (Gast)]

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.

[Frank M. (ukw) (Moderator)]

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:

        value_ptr &= 0x07;

Nichts anderes hat der Compiler in Assembler hingeschrieben.

[(prx) A. K. (prx)]

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.

[(prx) A. K. (prx)]

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.

[Frank M. (ukw) (Moderator)]

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):

     y = x * 80
<==> y = x * (64 + 16)
<==> y = x * 64 + x * 16
<==> 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.

[Chris B. (dekatz)]

A. K. schrieb:
> Aber nur ohne Vorzeichen.

Mit "Übung, Vorbereitung und System" braucht man ohnehin keine 
Vorzeichen :-D

[(prx) A. K. (prx)]

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.

[Matthias L. (Gast)]

>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.

;-)

[(prx) A. K. (prx)]

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.

[Witkatz :. (wit)]

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...

[Matthias L. (Gast)]

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.

[Frank M. (ukw) (Moderator)]

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

#define COLS_PER_ROW    80

durch

#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.

[(prx) A. K. (prx)]

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.

[Witkatz :. (wit)]

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. (kbuchegg)]

Die Frage ist allerdings eher, ob Moby das trivial Optimierungspotential 
erkennt, das in dieser Funktion noch vorhanden ist.

[Gu. F. (mitleser)]

Hmm, lange kanns ja jetzt nicht mehr bis zum großen Gegenschlag 
dauern...

[Witkatz :. (wit)]

Karl H. schrieb:
> ob Moby das trivial Optimierungspotential erkennt

Wieso? Ich dachte, dass einfache Digitalfilter zu einfacher MSR dazu 
gehören, oder etwa nicht?

[P. M. (o-o)]

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.

[Jörg W. (dl8dtl) (Moderator)]

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 ;-)

  ld   a, (adcsmooth)
  ld   b, a
  add  a
  ld   c, a
  add  a
  add  b
  add  c
  ld   hl, adc_value
  ld   b, (hl)
  add  b
  and  a
  rr   a
  and  a
  rr   a
  ld  (adcsmooth), a

Ist doch ganz einfach, und sofort klar und verständlich. :-)

[Witkatz :. (wit)]

Jörg W. schrieb:
> Ist doch ganz einfach,

Sorry, eine kleine 'kosmetische' Änderung ;-)

float AdcSmooth = (AdcSmooth * 7 + value_ptr) / 8;

[Frank M. (ukw) (Moderator)]

Jörg W. schrieb:
>

>   ld   a, (adcsmooth)
>   [...]
>   ld  (adcsmooth), a
>

>
> Ist doch ganz einfach, und sofort klar und verständlich. :-)

Geradezu selbstdokumentierend :-)

[(prx) A. K. (prx)]

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.

[Jörg W. (dl8dtl) (Moderator)]

Witkatz :. schrieb:
> float AdcSmooth

„Keine typische 8-bit-MSR-Anwendung“

[Karl H. (kbuchegg)]

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)

[Matthias L. (Gast)]

Karl H. schrieb:
> Nein, ich sag jetzt noch nicht wie

Das wird uns Moby hoffentlich dann zeigen.

[Thomas E. (thomase)]

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.

[(prx) A. K. (prx)]

Jörg W. schrieb:
...
Oder so:

   lda  adcsmooth
   mov  b, a
   add  a
   mov  c, a
   add  a
   add  b
   add  c
   lxi  h, adc_value
   mov  b, m
   add  b
   and  a
   rar  a
   and  a
   rar  a
   sta  adcsmooth

[Witkatz :. (wit)]

Karl H. schrieb:
> Aber dein Originalcode hat noch Potential.
> In C trivial zu ändern.

meinst du etwa

int16_t AdcSmooth = (AdcSmooth * 8 - AdcSmooth + ADC_VALUE) / 8;

[Frank M. (ukw) (Moderator)]

Witkatz :. schrieb:
> meinst du etwa
>

int16_t AdcSmooth = (AdcSmooth * 8 - AdcSmooth + ADC_VALUE) / 
> 8.0;

Nein, er meint das:

for(uint8_t i = 0; i < 8; i ++){
        sum += last_values[i];
      }

Statt immer wieder 7 + 1 = 8 Summen auszurechnen, kannst Du auch einmal 
die älteste abziehen.

[Jörg W. (dl8dtl) (Moderator)]

A. K. schrieb:
> Oder so:

Als Ossi bin ich mit der 8080-Mnemonik nie warm geworden. ;)

Die Einleitung müsste auch gehen als:

   ld  b, a
   add a
   add a
   add a
   sub b

Ein Befehl weniger, richtig gespart. :-))

[Karl H. (kbuchegg)]

Hmm
Irgendwie kann ich hier

  and  a
  rr   a
  and  a
  rr   a

die Division durch 8 noch nicht erkennen. m.M. nach ist das bisherige 
eine Division durch 4.

[Jörg W. (dl8dtl) (Moderator)]

Mensch, Karl Heinz, das war doch die Sollbruchstelle für Mobi. :-)

Nee, hatte ich natürlich vergessen, hast recht.

[Karl H. (kbuchegg)]

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.

[Jörg W. (dl8dtl) (Moderator)]

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. :-))

[Karl H. (kbuchegg)]

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.

[Jörg W. (dl8dtl) (Moderator)]

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. :)

[Karl H. (kbuchegg)]

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 :-)

[Matthias L. (Gast)]

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"

[Jörg W. (dl8dtl) (Moderator)]

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!

[Karl H. (kbuchegg)]

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 :-)

[Witkatz :. (wit)]

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?

   AdcSum += ADC_VALUE;
   if(value_cnt == 8){
       AdcSum -= AdcLastValue;
       AdcMovingAvg = AdcSum / 8;
   } else value_cnt++;
   AdcLastValue = ADC_VALUE;

Müsste RAM und zeitsparend sein im Vergleich zu der FOR Schleife mit dem 
Altwertevektor.

[Karl H. (kbuchegg)]

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.

>

   AdcSum += ADC_VALUE;
>    if(value_cnt == 8){
>        AdcSum -= AdcLastValue;
>        AdcMovingAvg = AdcSum / 8;
>    } else value_cnt++;
>    AdcLastValue = ADC_VALUE;

Nein.
So

  while(true){
    if(ADC_STATUS & (1 << ADC_HAS_NEW_VALUE)){

      // remove oldest value from sum      
      sum -= last_values[value_ptr];

      // save value into ringbuffer
      // and add it to sum
      last_values[value_ptr] = ADC_VALUE;
      sum += last_values[value_ptr];

      // increase ringbuffer pointer
      value_ptr ++;
      value_ptr %= 8;

      // check if average in ringbuffer exceeds threshold
      // if yes, send over uart
      if(sum / 8 > threshold){
        UART_DATA = sum / 8; 
        UART_CONFIG |= (1 << UART_DO_SEND);
      }

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.

[Matthias L. (Gast)]

>Achso, P.M.'s Gleitender Mittelwert war gemeint. Also etwa so?

Ich würds etwa so machen:

//-- ältesten Wert entfernen -------------------
AdcSum -= Buffer[BufIdx];

//-- neuen Wert in Puffer ----------------------
Buffer[BufIdx] = NewVal;

//-- neuen Wert zur Summe ----------------------
AdcSum += Buffer[BufIdx];

//-- Idx weiterrücken --------------------------
BufIdx += 1;
BufIdx %= BUFLEN;

//-- Mittelwert berechnen ----------------------
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.

[Witkatz :. (wit)]

Karl H. schrieb:
> Nein.
> So  ...
Ach ja sorry, mein Denkfehler. Man muss natürlich den ältesten Wert 
subtrahieren.

[Johann L. (gjlayde)]

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 :-)

[Karl H. (kbuchegg)]

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.

[P. M. (o-o)]

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.

[Jörg W. (dl8dtl) (Moderator)]

Johann L. schrieb:
>> Und schon hat man eine halbe Stunde an einer Codesequenz verbraten,
>
> Dann bastel doch am GCC.

Für den Z80? ;-)

[(prx) A. K. (prx)]

Jörg W. schrieb:
>> Dann bastel doch am GCC.
>
> Für den Z80? ;-)

Wieso nicht? Für den 68HC11 gibts ihn doch auch.

[Gu. F. (mitleser)]

Wow, unsere Mods leben ja richtig auf.
So ein Mobythread sollte öfter gestartet werden, das ist gut für eure 
Seele :-)

[Frank M. (ukw) (Moderator)]

Jörg W. schrieb:
> Für den Z80? ;-)

Genau. Und dann emulieren wir den Z80 auf einem STM32 ;-)

[P. M. (o-o)]

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?

[Michael K. (Gast)]

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.

[Moby A. (moby-project)]

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.

[Robert L. (lrlr)]

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.html
http://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

[Jörg W. (dl8dtl) (Moderator)]

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 …

[Robert L. (lrlr)]

>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..

[Operator S. (smkr)]

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...

[Robert L. (lrlr)]

das ist sinnlos, wir kenne doch schon alle seine Ausreden, warum er die 
ASM version dazu nicht abliefern würde...

[Yalu X. (yalu) (Moderator)]

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.

[P. M. (o-o)]

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:

void main(){
  
  uint8_t threshold = 89;

  uint8_t value_ptr = 0;
  uint8_t last_values[8] = {0, 0, 0, 0, 0, 0, 0, 0};

  ADC_CONFIG |= (1 << ADC_ON);
  UART_CONFIG = ...; // set some bits here
   
 
  while(true){
    if(ADC_STATUS & (1 << ADC_HAS_NEW_VALUE)){
      
      // save value into ringbuffer
      last_values[value_ptr] = ADC_VALUE;

      // increase ringbuffer pointer
      value_ptr ++;
      value_ptr %= 8;

      // sum up values in ringbuffer
      uint16_t sum = 0;
      for(uint8_t i = 0; i < 8; i ++){
        sum += last_values[i];
      }

      // check if average in ringbuffer exceeds threshold
      // if yes, send over uart
      if(sum / 8 > threshold){
        UART_DATA = sum / 8; 
        UART_CONFIG |= (1 << UART_DO_SEND);
      }
  
    }
  }
}

[Witkatz :. (wit)]

P. M. schrieb:
> Hier nochmals die Aufgabenstellung:

Wo? Ich sehe nur Quellcode. Sieht so eine Spec aus?

[P. M. (o-o)]

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...

[Ralf G. (ralg)]

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?? ^^ :-/ :-)

[Chris D. (myfairtux) (Moderator)]

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.

[Witkatz :. (wit)]

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?

[P. M. (o-o)]

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.

[Jörg W. (dl8dtl) (Moderator)]

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.

[Operator S. (smkr)]

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.

[Ralf G. (ralg)]

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.

[Witkatz :. (wit)]

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?

[Jörg W. (dl8dtl) (Moderator)]

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.)

[Chris D. (myfairtux) (Moderator)]

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.

[Matthias L. (Gast)]

>dass P.M. seine Aufgabe in C ans Laufen

Ich würde P.M. vorher noch empfehlen, die 8en im Code durch ein sizeof 
oder durch eine Konstante zu ersetzen.

[Carl D. (jcw2)]

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.

[Witkatz :. (wit)]

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.

[Johann L. (gjlayde)]

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...

[Witkatz :. (wit)]

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?

[P. M. (o-o)]

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. (dl8dtl) (Moderator)]

P. M. schrieb:
> wie man dies auch Moby klarmachen kann.

Die Antwort ist doch sonnenklar: gar nicht.

[Thomas E. (thomase)]

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.

[Witkatz :. (wit)]

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.

[Jörg W. (dl8dtl) (Moderator)]

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 :-)“

[Gu. F. (mitleser)]

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.

[Bernd K. (prof7bit)]

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.

[Karl H. (kbuchegg)]

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.

[Moby A. (moby-project)]

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.

[Karl H. (kbuchegg)]

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.

[Bernd K. (prof7bit)]

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.

[Carl D. (jcw2)]

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?

[Moby A. (moby-project)]

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.

[Moby A. (moby-project)]

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 ;-)

[Jörg W. (dl8dtl) (Moderator)]

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. ;-)

[Moby A. (moby-project)]

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.

[Moby A. (moby-project)]

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 
;-)

[Le X. (lex_91)]

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?

[Wolfgang R. (Firma: www.wolfgangrobel.de) (mikemcbike)]

Worum ging's gleich nochmal?

;-)

[Klaus W. (mfgkw)]

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 :-)

[Michael K. (Gast)]

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.

[Frank M. (ukw) (Moderator)]

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!

[Gu. F. (mitleser)]

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.

[Frank M. (ukw) (Moderator)]

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.

[Matthias L. (Gast)]

"Wir leben zwar alle unter dem selben Himmel, haben aber nicht alle den 
gleichen Horizont"

[Michael K. (Gast)]

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.

[Robert L. (lrlr)]

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...

[Frank M. (ukw) (Moderator)]

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!

[P. M. (o-o)]

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.

[Jörg W. (dl8dtl) (Moderator)]

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 …

[Frank M. (ukw) (Moderator)]

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.

[Karl H. (kbuchegg)]

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.

[Michael K. (Gast)]

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.

[P. M. (o-o)]

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.

[Matthias L. (Gast)]

>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.

[Jörg W. (dl8dtl) (Moderator)]

Matthias L. schrieb:
> Mit SW Entwicklung offensichtlich nicht.

Dass das rein sein Hobby ist, daraus hat er nie einen Hehl gemacht.

[Matthias L. (Gast)]

>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.

[Frank M. (ukw) (Moderator)]

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.

[Michael K. (Gast)]

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.

[P. M. (o-o)]

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...

[Jörg W. (dl8dtl) (Moderator)]

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?“

[Sheeva P. (sheevaplug)]

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.

[Sheeva P. (sheevaplug)]

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".

[Michael K. (Gast)]

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.

[Jörg W. (dl8dtl) (Moderator)]

Michael K. schrieb:
> Niemand kann mehr aus 8bit / 64K herausholen.

Passt ja zu Moby. :-)

[P. M. (o-o)]

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?

[Jörg W. (dl8dtl) (Moderator)]

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.

[Frank M. (ukw) (Moderator)]

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.

[Johann L. (gjlayde)]

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.

[P. M. (o-o)]

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.

[Jörg W. (dl8dtl) (Moderator)]

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.

[Bernd N. (bernd_n)]

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.pdf
http://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.

[Michael K. (Gast)]

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 ;-)

[P. M. (o-o)]

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".

[Michael K. (Gast)]

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.

[P. M. (o-o)]

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 ;-)

[Carl D. (jcw2)]

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.

[Thomas E. (thomase)]

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.

[Witkatz :. (wit)]

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?

#include <xc.h>
#include <stdint.h>

// CONFIG
#pragma config FOSC = INTRCIO   // Oscillator Selection bits (INTOSC oscillator: I/O function on GP4/OSC2/CLKOUT pin, I/O function on GP5/OSC1/CLKIN)
#pragma config WDTE = OFF       // Watchdog Timer Enable bit (WDT disabled)
#pragma config PWRTE = OFF      // Power-Up Timer Enable bit (PWRT disabled)
#pragma config MCLRE = OFF      // GP3/MCLR pin function select (GP3/MCLR pin function is digital I/O, MCLR internally tied to VDD)
#pragma config BOREN = ON       // Brown-out Detect Enable bit (BOD enabled)
#pragma config CP = OFF         // Code Protection bit (Program Memory code protection is disabled)
#pragma config CPD = OFF        // Data Code Protection bit (Data memory code protection is disabled)

#define _XTAL_FREQ 4000000
#define clockpin GPIObits.GP4
#define datapin GPIObits.GP5

void InitMCU(void){
    GPIO = 0;
    CMCON = 0x07; // Comparator off
    ADCON0bits.ADFM = 1; // Rigth justified
    ADCON0bits.VCFG = 0; // Vref = Vdd 
    ADCON0bits.ADON = 1; // A/D on
    
    ANSELbits.ADCS = 0b101; // TAD = 4µs
    ANSELbits.ANS = 0b0011; // AN0,AN1 
    TRISIO = 0b001111;

}

void ad_acq(uint8_t chs){
    ADCON0bits.CHS = chs;
    __delay_us(20);
    ADCON0bits.GO = 1;
    while (ADCON0bits.GO_nDONE){;}
}

void sendByte(uint8_t s){
    uint8_t mask = 0b10000000;
    while(mask){
        if(s & mask)
            datapin = 1;
        clockpin = 1;
        __delay_ms(5);
        clockpin = 0;
        datapin = 0;
        mask >>= 1;
        __delay_ms(5);
    }
}

void main(void) {
    uint8_t tmpByte3, crc;
    
    InitMCU();
    while(1){
        __delay_ms(80);
        
        // AD Channel 0
        ad_acq(0); // Analog Channel 0 lesen
        sendByte(ADRESL); 
        crc = ADRESL;
        tmpByte3 = ADRESH;

        // AD Channel 1
        ad_acq(1); // Analog Channel 1 lesen
        sendByte(ADRESL);
        crc += ADRESL;
        tmpByte3 |= ADRESH << 2; // 

        // send Byte 3 with CRC
        tmpByte3 |= (GPIO & 0b00001100) << 2; // Digitaleingänge in Bits 4,5 speichern
        crc += tmpByte3;
        tmpByte3 |= (crc & 0b00000011) << 6;
        sendByte(tmpByte3);
    }
}

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. (gjlayde)]

Thomas E. schrieb:
> Frag mich nicht warum. Ich programmiere auf 8-Bittern nur untypische
> Anwendungen.

+1

[Yalu X. (yalu) (Moderator)]

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 :)

[Moby A. (moby-project)]

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.

[Carl D. (jcw2)]

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.

[Moby A. (moby-project)]

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.

[P. M. (o-o)]

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.

[Carl D. (jcw2)]

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.

[Jörg W. (dl8dtl) (Moderator)]

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.

[Moby A. (moby-project)]

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!

[Thomas E. (thomase)]

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.

[Moby A. (moby-project)]

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.

[P. M. (o-o)]

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.

[P. M. (o-o)]

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?

[Moby A. (moby-project)]

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 ;-)

[Moby A. (moby-project)]

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 ;-)

[Moby A. (moby-project)]

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...

[Moby A. (moby-project)]

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.

[Moby A. (moby-project)]

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 ;-)

[Le X. (lex_91)]

Moby A. schrieb:
> vermutlich kennst Du auch nur fetten C-Code

Moby 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?

[Robert L. (lrlr)]

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..

[(prx) A. K. (prx)]

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.

[Robert L. (lrlr)]

>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..

[(prx) A. K. (prx)]

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.

[Gu. F. (mitleser)]

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???

[Chris D. (myfairtux) (Moderator)]

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: ;-) ;-) ;-)