Strukturierte AVR-Assembler-Programmierung

[Eberhard H. (sepic)]

Da die Spezies der AVR-Assembler-Programmierer offensichtlich nicht vom 
Aussterben bedroht ist und täglich neue µC-Anwender sogar mit 
Assembler-Programmierung anfangen, möchte ich an dieser Stelle eines 
meiner Projekte vorstellen, nämlich ein Software-Tool für strukturierte 
AVR-Assembler-Programmierung unter Windows*, das entweder als 
eigenständiges Programm zusammen mit einem AVRASM2-kompatiblen Assembler 
oder integriert in Atmel Studio (bislang getestet mit Version 7) und 
anderen Programmen verwendet werden kann.

Die Grundidee ist nicht neu: Man schreibt sein AVR-Quellprogramm 
weiterhin grundsätzlich in Assembler-Sprache, verwendet aber statt 
Verzweigungs- und Vergleichsabfragen per Assembler-Befehlen die von 
höheren Programmiersprachen bekannten Sprachelemente für strukturierte 
Programmierung**, wie z.B. IF/ELSEIF/ELSE, WHILE, REPEAT, FOR und LOOP, 
die im Programm beliebig oft und beliebig tief geschachtelt werden 
können.

Alles andere bleibt reine Assembler-Sprache. Durch das strukturierte 
Programmieren kann das Programm deutlich übersichtlicher, weniger 
fehlerträchtig und sehr viel schneller erstellt werden und ist später 
besser lesbar und zu pflegen (auch von anderen).

Der Programmierer hat dabei weiterhin wie bisher (hoffentlich) volle 
Kontrolle über jedes Register und jedes Bit des jeweiligen 
AVR-µControllers.

Das vom Tool erzeugte Programm ist als Maschinen-Code nur minimal größer 
(wenn überhaupt) als ein voll ausgereiztes reines Assembler-Programm.

Der einzige Wermutstropfen ist (neben einer einmaligen Einarbeitung = 
lesen des Handbuchs) ein kleiner Zwischenschritt, um das strukturierte 
Quellprogramm in ein reines "flaches" Assemblerprogramm zu kompilieren 
(was - je nach Einbindung in die Entwicklungsumgebung - nur zwei 
Mausklicks und Sekundenbruchteile benötigt), um es dann wie gewohnt zu 
assemblieren, ggf. (seltener) zu debuggen und in den AVR zu "brennen".

Dass sich einige eingeschworene AVR-Assembler-Gurus nicht unbedingt mit 
zusätzlichen Sprachelementen für strukturierte Programmierung belasten 
wollen, ist mir klar. Ein Anfänger oder jemand, der nicht täglich in 
Assembler programmiert, wird eine solche Möglichkeit aber durchaus zu 
schätzen wissen und damit bestimmt schneller zum gewünschten Ergebnis 
kommen.

Langer Rede kurzer Sinn: Eine Beschreibung des Tools und ein 
ausführliches Handbuch (in Deutsch) stehen auf meiner Website zur 
Verfügung: http://www.led-treiber.de/html/s-avr.html

Das Programm selbst wurde von mir unter WIN10 mit verschiedenen 
Anwendungen ausgiebig und bislang fehlerfrei auf einem ATmega328 
getestet, ist jedoch derzeit noch in der Beta-Phase.

Deshalb möchte ich es vorerst auch nicht allgemein zum Download 
anbieten, aber Interessierten per PN-Anfrage und E-Mail zur Verfügung*** 
stellen.

Diese bekommen dann von mir solange automatisch Updates (falls welche 
nötig sind) bis das Programm allgemein zum Download zur Verfügung steht.

Anregungen und Kommentare sind gerne auch an dieser Stelle willkommen.

Eberhard

* Alle Versionen von WIN98SE bis WIN10 werden unterstützt.

** Ja, ich weiß, dass es eine ähnliche, aber weniger elegante Methode 
mit Makros gibt.

*** Kostenlos natürlich. Dann bitte angeben, welches Dateiformat 
gewünscht ist: ca. 600kB als EXE, nur halb so groß als ZIP (oder 7Z).

[c-hater (Gast)]

Eberhard H. schrieb:

> ** Ja, ich weiß, dass es eine ähnliche, aber weniger elegante Methode
> mit Makros gibt.

Warum sollte das weniger elegant sein?

[Pandur S. (jetztnicht)]

> Ein Anfänger oder jemand, der nicht täglich in Assembler programmiert, wird eine 
solche Möglichkeit aber durchaus zu schätzen wissen und damit bestimmt schneller 
zum gewünschten Ergebnis kommen.


Besten Dank fuer die Vorarbeit und das Angebot. ASM programmiert man 
nicht einfach so irgendwann einmal, sondern eben haeufig oder gar nicht. 
Auch wenn die syntax vielleicht etwas verloren gegangen sein kann, muss 
man die Konzepte trotzdem kennen.
Am muehsamsten fand ich zB bei den AVR, dass die Register nicht uniform 
angesprochen werden koennen. Das eine Mal kann man das Port direkt 
bedienen, das andere Mal nicht, da ausserhalb des Adressbereiches.

LDI UDR,0x00

LDI R16,0x00
STS UDR,R16

oder so. Es ist aber leider nicht so, dass man die zweite Moeglichkeit 
generell benutzen koennte.

Wie auch immer, wir schauen's uns dein Konzept gerne an.

[Carl D. (jcw2)]

Sapperlot W. schrieb:
> LDI UDR,0x00
Hmmmm?!

[Edson (Gast)]

Eberhard H. schrieb:
> Da die Spezies der AVR-Assembler-Programmierer offensichtlich nicht vom
> Aussterben bedroht ist und täglich neue µC-Anwender sogar mit
> Assembler-Programmierung anfangen,

Ich denke, es ist wohl eher so, dass manch Einer täglich neu mit der 
ASM-Programmierung anfängt ;)

Sapperlot W. schrieb:
> ASM programmiert man
> nicht einfach so irgendwann einmal, sondern eben haeufig oder gar nicht.

So ist es.

[Peter D. (peda)]

Ich kann mich erinnern, da gab es mal einen 8051 Assembler von Erik 
Buchmann mit solchen Erweiterungen. Aber die Webseite scheint 
verschwunden zu sein.

[Marc V. (Firma: Vescomp) (logarithmus)]

Eberhard H. schrieb:
> Deshalb möchte ich es vorerst auch nicht allgemein zum Download
> anbieten, aber Interessierten per PN-Anfrage und E-Mail zur Verfügung***
> stellen.

 Das gefällt mir schon mal nicht. Warum das ?


> höheren Programmiersprachen bekannten Sprachelemente für strukturierte
> Programmierung**, wie z.B. IF/ELSEIF/ELSE, WHILE, REPEAT, FOR und LOOP,
> die im Programm beliebig oft und beliebig tief geschachtelt werden
> können.

 Ein Beispiel für geschachtelte FOR oder WHILE Schleifen bist du aber
 auf deiner Seite schuldig geblieben.

 Aneinander gereihte Schleifen oder Abfragen gehen genauso mit Macros.
 Und soviel ich gesehen habe, wird der Register rchk (der als
 einziger benutzt wird) auch nirgendwo vorher gerettet. Das heisst,
 dass dieser Register im Assemblerprogramm nicht benutzt werden darf.

 Heisst das auch, dass dein Programm bei 3 verschachtelten Schleifen
 3 verschiedene Register benutzt ?
 Da es sich um einen Register R16-R31 handelt, ist das schon mal ein
 klares KO für dein Programm.

 Sende mal ein assembliertes Beispiel für 3 verschachtelte Schleifen
 in einer IF-Abfrage mit bedingtem Raussprung aus der mittleren...

[Falk B. (falk)]

@Eberhard H. (sepic)

>weiterhin grundsätzlich in Assembler-Sprache, verwendet aber statt
>Verzweigungs- und Vergleichsabfragen per Assembler-Befehlen die von
>höheren Programmiersprachen bekannten Sprachelemente für strukturierte
>Programmierung**, wie z.B. IF/ELSEIF/ELSE, WHILE, REPEAT, FOR und LOOP,
>die im Programm beliebig oft und beliebig tief geschachtelt werden
>können.

Aha, du erfindest als den Macroassembler neu.

>Alles andere bleibt reine Assembler-Sprache. Durch das strukturierte
>Programmieren kann das Programm deutlich übersichtlicher, weniger
>fehlerträchtig und sehr viel schneller erstellt werden und ist später
>besser lesbar und zu pflegen (auch von anderen).

Sinnlos. Da kann man auch gleich eine Hochsprache ala C oder Pascal 
nehmen, die machen das wenigstens richtig.

>Der Programmierer hat dabei weiterhin wie bisher (hoffentlich) volle
>Kontrolle über jedes Register und jedes Bit des jeweiligen
>AVR-µControllers.

Hat er unter C auch. Und wenn es mal WIRKLICH schnell gehen muss, nimmt 
man Inline-Assembler oder eine ASM-Funktion in einer separaten Datei. 
Das ist aber heute eher selten.

>lesen des Handbuchs) ein kleiner Zwischenschritt, um das strukturierte
>Quellprogramm in ein reines "flaches" Assemblerprogramm zu kompilieren

Aha, als doch ein Compiler für Arme ;-)

>wollen, ist mir klar. Ein Anfänger oder jemand, der nicht täglich in
>Assembler programmiert, wird eine solche Möglichkeit aber durchaus zu
>schätzen wissen und damit bestimmt schneller zum gewünschten Ergebnis
>kommen.

Den Beweis mußt du erstmal liefern. Für mich klingt das eher nach einer 
halbgaren Spielerei für DICH.

>Deshalb möchte ich es vorerst auch nicht allgemein zum Download
>anbieten, aber Interessierten per PN-Anfrage und E-Mail zur Verfügung***
>stellen.

Ob das so sinnvoll ist?

[Bernd K. (prof7bit)]

Ihr habts echt drauf die Leute zu motivieren und ihre Bemühungen zu 
würdigen, da wird einem ja richtig warm ums Herz ;-)

[Falk B. (falk)]

@Bernd K. (prof7bit)

>Ihr habts echt drauf die Leute zu motivieren und ihre Bemühungen zu
>würdigen, da wird einem ja richtig warm ums Herz ;-)

Wir sind hier nicht im Kindergarten, wo es ach für die häßlichste 
Sandburg ein "hast du aber fein gemacht" gibt. Wenn der OP keine offene, 
sachliche Kritik hören will, darf er nicht danach fragen.

https://de.wikipedia.org/wiki/Kritikkompetenz

"Kritik stellt für die meisten Menschen ein Problem dar. Sie ist negativ 
belegt, wird ungern empfangen und meist auch ungern erteilt – zumindest 
wenn es konstruktive, durchdachte und für den anderen fordernde und 
fördernde Kritik sein soll. Der Begriff Kritikkompetenz sieht Kritik, 
sofern richtig eingesetzt, als eine kreative Ressource, die unabdingbar 
für Lernprozesse und Weiterentwicklung ist. Denn Kritik bietet die Basis 
für die persönliche Entwicklung eines Menschen und ist damit ein 
Grundstein für Lernprozesse in diversen gesellschaftlichen Bereichen, 
wie der schulischen Ausbildung, Erwachsenenbildung oder in der 
Wirtschaft, die unter Begriffen wie Soft Skills oder 
Schlüsselqualifikationen soziale Fähigkeiten in der Personalauswahl und 
-entwicklung für sich entdeckt hat. Als besonders wichtig ist der Besitz 
von Kritikkompetenz bei Führungspersönlichkeiten, wie z. B. Lehrern oder 
Vorgesetzten, einzuschätzen, da sie durch ihr Kritik-Verhalten großen 
Einfluss auf die Personen haben, für die sie verantwortlich sind."

[Eberhard H. (sepic)]

Ich habe überhaupt kein Problem mit Kritik.

Wie es meine Zeit zulässt, werde ich zu allen ernst gemeinten Fragen und 
Einwänden Stellung nehmen.

PS: Mein Beitrag stand ursprünglich unter "Projekte & Code", wurde aber 
nach hierher verschoben.

[Marc V. (Firma: Vescomp) (logarithmus)]

Eberhard H. schrieb:
> Wie es meine Zeit zulässt, werde ich zu allen ernst gemeinten Fragen und
> Einwänden Stellung nehmen.

 Meine Fragen und Einwände waren ernst gemeint.

 Und eine Stellungnahme anzukündigen, anstatt gleich eine Antwort zu
 schreiben ist ?

 Was bist du denn - ein Politiker oder Parteisprecher der erst seine
 Berater fragen muss, bevor er Stellung nimmt ?

[Eberhard H. (sepic)]

Hier meine erste Stellungnahme ...

c-hater schrieb:
> Eberhard H. schrieb:
>
>> ** Ja, ich weiß, dass es eine ähnliche, aber weniger elegante Methode
>> mit Makros gibt.
>
> Warum sollte das weniger elegant sein?

Über die "Eleganz" von Programmiersprachen/Methoden lässt sich bestimmt 
trefflich streiten. Aber das war und ist nicht die Absicht mit meiner 
Aussage.

Nehmen wir einmal das einfache Lauflicht-Beispiel von meiner Website (es 
ist der Übersicht halber ein Auzug ohne Include, 
Interrupt-Sprungtabelle, Initialisierung und Unterprogramme):

Zunächst in struktutierter Form (Atmel-Studio-Dateierweiterung .s):

.def  LEDport = r17  ; register for LED port data (bits 0...5)
.def  bitmask = r18  ; bit mask 00_0001 through 10_0000

.def  LEDcnt = r19  ; loop counter addressing the individual LEDs
.def  lpcnt = r20    ; outer loop counter (test only)

ldi    lpcnt,1      ; for the test display            
ldi    LEDport,0b0011_1111  ; set lower 6 bits ...
out    DDRC,LEDport  ; ... as outputs
cbi    DDRB,2      ; Port B bit 2 = input (/SS, default)
sbi    PORTB,2      ; enable pull-up (push button to GND)

LOOP  ; main loop
    rcall  LCDStart  ; display lpcnt

    REPEAT            ; walking LEDs from LSB to MSB
      ldi    LEDport,0b0011_1111  ; set lower 6 bits
      out    PORTC,LEDport  ; ...and all LEDs off
      ldi    bitmask,0b00_0001  ; set LSB of 6 bits
      FOR LEDcnt := #12    ; 6 cycles ON one after the other
                  ; 6 cycles OFF one after the other
        in  LEDport,PORTC
        eor  LEDport,bitmask  ; toggle masked LED position
        out  PORTC,LEDport
        IF LEDcnt == #7
          ldi  bitmask,0b00_0001  ; reload bitmask
        ELSE
          lsl  bitmask    ; next LED position
        ENDI
        rcall  delay100ms  ; defines the walking speed
        EXITIF  !%PINB,2  ; push button LOW?
      ENDF
    UNTIL !%PINB,2  ; push button still LOW?

    ; pushing the button continuously will flash the MSB and LSB
    ; LEDs and continue one of the modes after releasing the button

    REPEAT            ; walking LEDs from MSB (reverse order)
      ldi    LEDport,0b0011_1111  ; set lower 6 bits
      out    PORTC,LEDport  ; ...and all LEDs off
      ldi    bitmask,0b10_0000  ; set MSB of 6 bits
      FOR LEDcnt := #12    ; 6 cycles ON one after the other
                  ; 6 cycles OFF one after the other
        in  LEDport,PORTC
        eor  LEDport,bitmask  ; toggle masked LED position
        out  PORTC,LEDport
        IF LEDcnt == #7
          ldi  bitmask,0b0010_0000  ; reload bitmask
        ELSE
          lsr  bitmask    ; next LED position
        ENDI
        rcall  delay100ms  ; defines the walking speed
        EXITIF  !%PINB,2  ; push button LOW?
      ENDF
    UNTIL !%PINB,2  ; push button still LOW?

    inc  lpcnt
ENDL  ; main loop (forever)

Und hier die kompilierte Form (Atmel-Studio-Dateierweiterung .asm) mit 
der Compiler-Option, die ursprünglichen strukturierten Befehle als 
Kommentar zu behalten:

.def  LEDport = r17  ; register for LED port data (bits 0...5)
.def  bitmask = r18  ; bit mask 00_0001 through 10_0000

.def  LEDcnt = r19  ; loop counter addressing the individual LEDs
.def  lpcnt = r20    ; outer loop counter (test only)

ldi    lpcnt,1      ; for the test display            
ldi    LEDport,0b0011_1111  ; set lower 6 bits ...
out    DDRC,LEDport  ; ... as outputs
cbi    DDRB,2      ; Port B bit 2 = input (/SS, default)
sbi    PORTB,2      ; enable pull-up (push button to GND)

  ;01// LOOP  ; main loop
_L1:
  rcall  LCDStart  ; display lpcnt

  ;02// REPEAT            ; walking LEDs from LSB to MSB
_L4:
  ldi    LEDport,0b0011_1111  ; set lower 6 bits
  out    PORTC,LEDport  ; ...and all LEDs off
  ldi    bitmask,0b00_0001  ; set LSB of 6 bits
  ;03// FOR LEDcnt := #12    ; 6 cycles ON one after the other
  LDI  LEDcnt,12
_L7:
                  ; 6 cycles OFF one after the other
  in  LEDport,PORTC
  eor  LEDport,bitmask  ; toggle masked LED position
  out  PORTC,LEDport
  ;04// IF LEDcnt == #7
  CPI  LEDcnt,7
  BREQ  _L11
  RJMP  _L10
_L11:
  ldi  bitmask,0b00_0001  ; reload bitmask
  RJMP  _L12
_L13:
  ;04// ELSE
_L10:
  lsl  bitmask    ; next LED position
  ;04// ENDI
_L12:
  rcall  delay100ms  ; defines the walking speed
  ;03// EXITIF  !%PINB,2  ; push button LOW?
  SBIS  PINB,2
  RJMP  _L9
_L8:
  ;03// ENDF
  DEC  LEDcnt
  BREQ  _L15
  RJMP  _L7
_L15:
_L9:
  ;02// UNTIL !%PINB,2  ; push button still LOW?
  SBIC  PINB,2
  RJMP  _L4
_L5:

    ; pushing the button continuously will flash the MSB and LSB
    ; LEDs and continue one of the modes after releasing the button

  ;02// REPEAT            ; walking LEDs from MSB (reverse order)
_L16:
  ldi    LEDport,0b0011_1111  ; set lower 6 bits
  out    PORTC,LEDport  ; ...and all LEDs off
  ldi    bitmask,0b10_0000  ; set MSB of 6 bits
  ;03// FOR LEDcnt := #12    ; 6 cycles ON one after the other
  LDI  LEDcnt,12
_L19:
                  ; 6 cycles OFF one after the other
  in  LEDport,PORTC
  eor  LEDport,bitmask  ; toggle masked LED position
  out  PORTC,LEDport
  ;04// IF LEDcnt == #7
  CPI  LEDcnt,7
  BREQ  _L23
  RJMP  _L22
_L23:
  ldi  bitmask,0b0010_0000  ; reload bitmask
  RJMP  _L24
_L25:
  ;04// ELSE
_L22:
  lsr  bitmask    ; next LED position
  ;04// ENDI
_L24:
  rcall  delay100ms  ; defines the walking speed
  ;03// EXITIF  !%PINB,2  ; push button LOW?
  SBIS  PINB,2
  RJMP  _L21
_L20:
  ;03// ENDF
  DEC  LEDcnt
  BREQ  _L27
  RJMP  _L19
_L27:
_L21:
  ;02// UNTIL !%PINB,2  ; push button still LOW?
  SBIC  PINB,2
  RJMP  _L16
_L17:

  inc  lpcnt
  ;01// ENDL  ; main loop (forever)
  RJMP  _L1

Gerne darfst du mir eine Macro-basierende Version zum Vergleich 
schreiben und dann können wir darüber diskutieren.

Es ist mir bewusst (und das steht auch im Handbuch beschrieben), dass 
man bei sehr kurzen Programmsegmenten statt RJMP vorteilhaft 
Branch-Befehle nimmt, was mir aber wegen deren geringen Sprungweite 
nicht universell genug schien.

Das lässt sich jedoch mit einer Spracherweiterung .s (für short und 
Branch-Befehle statt RJMP) und .l (für long und JMP-Befehle, nicht für 
die älteren ATtinys) verbessern.

Die vorgestellte Version ist eine Lite-Version, da lässt sich mit einer 
solchen Einschränkung (wenn es immer wirklich eine ist) durchaus leben.

[Eberhard H. (sepic)]

Marc V. schrieb:
> Eberhard H. schrieb:
>> Deshalb möchte ich es vorerst auch nicht allgemein zum Download
>> anbieten, aber Interessierten per PN-Anfrage und E-Mail zur Verfügung***
>> stellen.
>
>  Das gefällt mir schon mal nicht. Warum das ?

Wie gesagt, es ist derzeit eine Beta-Bersion, wenn auch sehr ausgiebig 
getestet. Und solange das der Fall ist, möchte ich mir diese 
Vorgehensweise vorbehalten. Mein Angebot gilt für alle, aber man muss es 
ja nicht nützen, wenn es einem nicht gefällt.

Wenn es dann keine Einwände mehr gibt (offensichtlich gibt es derzeit 
noch viele - ohne je den Compiler verwendet zu haben), werde ich die 
Lite-Version zum Download zur Verfügung stellen.

>  Ein Beispiel für geschachtelte FOR oder WHILE Schleifen bist du aber
>  auf deiner Seite schuldig geblieben.

Wenn du das Angebot für einen Test nicht wahrnehmen willst, darfst du 
gerne hier ein beliebig geschachteltes strukturiertes Programm zur 
Diskussion stellen. Ich füge dann das kompilierte flache 
Assembler-Programm dazu.

>  Aneinander gereihte Schleifen oder Abfragen gehen genauso mit Macros.
>  Und soviel ich gesehen habe, wird der Register rchk (der als
>  einziger benutzt wird) auch nirgendwo vorher gerettet. Das heisst,
>  dass dieser Register im Assemblerprogramm nicht benutzt werden darf.

Der Compiler verwendet von sich aus überhaupt keine zusätzlichen 
AVR-Register (das ist ein wichtiger Grundsatz des Konzepts), sondern 
ausschließlich die vom Programmierer verwendeten AVR-Register.

>  Heisst das auch, dass dein Programm bei 3 verschachtelten Schleifen
>  3 verschiedene Register benutzt ?
>  Da es sich um einen Register R16-R31 handelt, ist das schon mal ein
>  klares KO für dein Programm.

s.o.

>  Sende mal ein assembliertes Beispiel für 3 verschachtelte Schleifen
>  in einer IF-Abfrage mit bedingtem Raussprung aus der mittleren...

s.o.

[Mampf F. (mampf)]

Eberhard H. schrieb:
> Nehmen wir einmal das einfache Lauflicht-Beispiel von meiner Website (es
> ist der Übersicht halber ein Auzug ohne Include,
> Interrupt-Sprungtabelle, Initialisierung und Unterprogramme):
>
> Zunächst in struktutierter Form (Atmel-Studio-Dateierweiterung .s):

Ähm, was mir als erstes auffällt ist, dass du die Zeilen Strukturiert 
eingerückt hast.

Das kann man fei auch machen, wenn man direkt Assembler programmiert ...

Aber kein Wunder, dass der Output dann unstrukturiert aussieht, weil da 
alle Einrückungen verschwunden sind ...

> werde ich die Lite-Version zum Download zur Verfügung stellen.

Ahja da haben wir es ja ... Das ist nichts weiter als Werbung und jemand 
möchte seinen Kram verkaufen.

Kann man ja mal versuchen ...^^

[Eberhard H. (sepic)]

Falk B. schrieb:
> @Eberhard H. (sepic)
>
>>weiterhin grundsätzlich in Assembler-Sprache, verwendet aber statt
>>Verzweigungs- und Vergleichsabfragen per Assembler-Befehlen die von
>>höheren Programmiersprachen bekannten Sprachelemente für strukturierte
>>Programmierung**, wie z.B. IF/ELSEIF/ELSE, WHILE, REPEAT, FOR und LOOP,
>>die im Programm beliebig oft und beliebig tief geschachtelt werden
>>können.
>
> Aha, du erfindest als den Macroassembler neu.

Strukturierte Sprachelemente (wie die von mir vorgeschlagenen) haben mit 
einem Macroassembler zunächst nichts zu tun.

>>Alles andere bleibt reine Assembler-Sprache. Durch das strukturierte
>>Programmieren kann das Programm deutlich übersichtlicher, weniger
>>fehlerträchtig und sehr viel schneller erstellt werden und ist später
>>besser lesbar und zu pflegen (auch von anderen).
>
> Sinnlos. Da kann man auch gleich eine Hochsprache ala C oder Pascal
> nehmen, die machen das wenigstens richtig.

Das ist nicht sinnlos, sonst hätten nicht namhafte Firmen dasselbe (aber 
in den eigentlichen Assembler integriert) schon vor Jahrzehnten gemacht. 
Und noch hast du mir nicht gezeigt, dass mein Tool etwas Falsches macht.

>>Der Programmierer hat dabei weiterhin wie bisher (hoffentlich) volle
>>Kontrolle über jedes Register und jedes Bit des jeweiligen
>>AVR-µControllers.
>
> Hat er unter C auch. Und wenn es mal WIRKLICH schnell gehen muss, nimmt
> man Inline-Assembler oder eine ASM-Funktion in einer separaten Datei.
> Das ist aber heute eher selten.

Über die Vor- und Nachteile von C müssen wir hier nicht diskutieren, 
auch nicht über Inline-Assembler. Mein Vorschlag ist eine sinnvolle 
Erweiterung für reine AVR-Assembler-Sprache.

> Aha, als doch ein Compiler für Arme ;-)

Warum nicht?

>>wollen, ist mir klar. Ein Anfänger oder jemand, der nicht täglich in
>>Assembler programmiert, wird eine solche Möglichkeit aber durchaus zu
>>schätzen wissen und damit bestimmt schneller zum gewünschten Ergebnis
>>kommen.
>
> Den Beweis mußt du erstmal liefern. Für mich klingt das eher nach einer
> halbgaren Spielerei für DICH.

Das dürfen gerne ernsthafte Anwender beurteilen.

>>Deshalb möchte ich es vorerst auch nicht allgemein zum Download
>>anbieten, aber Interessierten per PN-Anfrage und E-Mail zur Verfügung***
>>stellen.
>
> Ob das so sinnvoll ist?

Hierzu habe ich bereits Stellung genommen.

[Jan (Gast)]

..
Dass sich einige eingeschworene AVR-Assembler-Gurus nicht unbedingt mit 
zusätzlichen Sprachelementen für strukturierte Programmierung belasten 
wollen, ist mir klar. Ein Anfänger oder jemand, der nicht täglich in 
Assembler programmiert, wird eine solche Möglichkeit aber durchaus zu 
schätzen wissen und damit bestimmt schneller zum gewünschten Ergebnis 
kommen.
...

Warum sollten Anfänger mit Assembler Programmierung anfangen?
Das sollte mann jedem Anfänger abraten

[Mampf F. (mampf)]

Jan schrieb:
> Ein Anfänger oder jemand, der nicht täglich in
> Assembler programmiert, wird eine solche Möglichkeit aber durchaus zu
> schätzen wissen und damit bestimmt schneller zum gewünschten Ergebnis
> kommen.

Ich seh das Problem eher darin:

1. man muss noch etwas dazu lernen (gut, der Aufwand ist vertretbar)
2. man weiß nicht, was implizit alles passiert

Oben wurden schon einige Frage gestellt, ob jetzt pro Loop ein eigenes 
Register verwendet wird oder ob die Register gepusht und gepopt werden 
oder und ob man die dann nicht in der Schleife verwenden darf usw usf 
... Dann gibts Leute, die finden es gut, wenn gepusht und gepopt wird, 
dann gibts andere, die stört das. Dann wird das aufgebohrt durch 
zusätzliche Direktiven, mit denen man das steuern kann. Dann gibts 
wieder andere, die können ihre Zyklus-Zeit nicht mehr abzählen usw usf 
... Man kann es eh nicht jedem recht machen^^

Gerade das schöne an Assembler geht verloren ... Man hat die 100%ige 
Kontrolle über das, was passiert.

Ob man jetzt Assembler + s-avr oder gleich eine Hochsprache lernt ... 
Mei, ist eigentlich total egal :)

*edit*: Noch eine Frage ... Was macht die "Lite" zur lite? Gibt es auch 
eine nicht-Lite?

[Falk B. (falk)]

@Eberhard H. (sepic)

>> Aha, du erfindest als den Macroassembler neu.

>Strukturierte Sprachelemente (wie die von mir vorgeschlagenen) haben mit
>einem Macroassembler zunächst nichts zu tun.

Der Unterschied ist eher gering.

>> Sinnlos. Da kann man auch gleich eine Hochsprache ala C oder Pascal
>> nehmen, die machen das wenigstens richtig.

>Das ist nicht sinnlos, sonst hätten nicht namhafte Firmen dasselbe (aber
>in den eigentlichen Assembler integriert) schon vor Jahrzehnten gemacht.

Wo denn?

>Und noch hast du mir nicht gezeigt, dass mein Tool etwas Falsches macht.

Darum geht es gar nicht, sondern ums Grundkonzept. Halb Fisch, halb 
Fleisch. Nicht mein Geschmack.

>Über die Vor- und Nachteile von C müssen wir hier nicht diskutieren,
>auch nicht über Inline-Assembler. Mein Vorschlag ist eine sinnvolle
>Erweiterung für reine AVR-Assembler-Sprache.

So wertvoll wie ein 3. Knie.

>> Aha, als doch ein Compiler für Arme ;-)

>Warum nicht?

Weil Unsinn ist. Außer ein paar Freaks interessiert das Keinen. Da 
kannst du dich mit Bome zusammentun, der ist schon ein par Schritte 
weiter ;-)

>> Den Beweis mußt du erstmal liefern. Für mich klingt das eher nach einer
>> halbgaren Spielerei für DICH.

>Das dürfen gerne ernsthafte Anwender beurteilen.

Die gar nicht deine Zielgruppe sind ;-) Ernsthafte Anwender nehmen ASM 
oder C und nicht so einen Käse.

>Hierzu habe ich bereits Stellung genommen.

Das scheint deine Kernkompetenz zu sein.

[Marc V. (Firma: Vescomp) (logarithmus)]

Eberhard H. schrieb:
> Der Compiler verwendet von sich aus überhaupt keine zusätzlichen
> AVR-Register (das ist ein wichtiger Grundsatz des Konzepts), sondern
> ausschließlich die vom Programmierer verwendeten AVR-Register.

 Aha.

    ;02// FOR rchk := #16 ; loop 16 times
    LDI   rchk,16         ;* <--- rchk soll ein (unerfahrener Asmprogrammierer) selbst definieren ?

 Was ist wenn der (unerfahrene) Programmierer R10 als rchk definiert ?

 Weiter schreibst du:

Eberhard H. schrieb:
> höheren Programmiersprachen bekannten Sprachelemente für strukturierte
> Programmierung**, wie z.B. IF/ELSEIF/ELSE, WHILE, REPEAT, FOR und LOOP,
> die im Programm beliebig oft und beliebig tief geschachtelt werden
> können.

 Und das ist schon mal entweder Blödsinn oder gelogen.
 So, wie das auf deiner Webseite übersetzt worden ist, geht es
 höchstens 16 Mal und dem Programmierer bleiben genau Null
 Register übrig.
 Zieht man die X, Y und Z Register ab, bleiben furs Programm nur noch
 10 Register übrig und dem Programmierer bleiben ?

 Genau, wieder gar keine...

Eberhard H. schrieb:
> Wenn du das Angebot für einen Test nicht wahrnehmen willst, darfst du
> gerne hier ein beliebig geschachteltes strukturiertes Programm zur
> Diskussion stellen. Ich füge dann das kompilierte flache
> Assembler-Programm dazu.

  FOR achk := #16   ; loop 16 times
    FOR brchk := #16   ; loop 16 times
      EXITIF achk==8
      FOR crchk := #16   ; loop 16 times
        FOR dchk := #16   ; loop 16 times
          FOR echk := #16   ; loop 16 times
            WHILE rchk <= #16 ; count from 1 through 16
              rcall chkok
              inc rchk
            ENDW
            rcall chkok
          ENDF
        ENDF
      ENDF
    ENDF
  ENDF
ex:  rjmp ex

chkok:
    ldi  r16, 8
    ldi  zl, 17
    clr  zh
fill:
    st  Z+, r16
    dec  r16
    brne  fill
    ret

Eberhard H. schrieb:
> Die vorgestellte Version ist eine Lite-Version, da lässt sich mit einer
> solchen Einschränkung (wenn es immer wirklich eine ist) durchaus leben.

 D.h. du machst Werbung für eine Version, die angeblich viel mächtiger
 sein soll, dafür aber nicht frei ?

[Eberhard H. (sepic)]

Mampf F. schrieb:
> 2. man weiß nicht, was implizit alles passiert

Sehr wohl, denn der Compiler verändert außer dem Befehlszähler, dem 
jeweiligen FOR-Schleifenzähler (der am Ende der Schleife dekrementiert 
wird) und dem Statusregister (bedingt durch die Abfragen) KEINE 
AVR-Register, die nicht durch den Programmierer vorgegeben sind.

> Oben wurden schon einige Frage gestellt, ob jetzt pro Loop ein eigenes
> Register verwendet wird oder ob die Register gepusht und gepopt werden
> oder und ob man die dann nicht in der Schleife verwenden darf usw usf

Vom Compiler wird also auch nichts gepushed und nichts gepoppt.
Bei einer FOR-Schleife wird nur das vom Programmieren vorgesehene 
Schleifenregister verwendet, s.o.

> Gerade das schöne an Assembler geht verloren ... Man hat die 100%ige
> Kontrolle über das, was passiert.

Gerade das ist ja der Grundgedanke meines Vorschlags, dass der 
Assembler-Programmierer volle Kontrolle über alle Register und Bits hat!

> Ob man jetzt Assembler + s-avr oder gleich eine Hochsprache lernt ...
> Mei, ist eigentlich total egal :)

Es macht meines Erachtens schon einen großen Unterschied, ob man "nur" 
strukturierte Sprachelemente (wie die vorgeschlagenen) über ein (echtes) 
Assembler-Programm legt oder in C schreibt.

> *edit*: Noch eine Frage ... Was macht die "Lite" zur lite? Gibt es auch
> eine nicht-Lite?

LITE ist die im Handbuch beschriebene und hier vorgestellte Version, die 
auch für die (alten) ATtinys immer zuverlässigen (wenn auch nicht immer 
100% optimalen) Code erzeugt, indem z.B. keine JMP-Befehle gerneriert 
werden. Allerdings werden (wie erklärt) an einigen Stellen Branch- und 
RJMP-Befehle verwendet, wo man per Skip- und Branch-Befehl etwas 
optimieren könnte, wenn denn die Sprungweite klein genug ist.

Aber das steht alles im Handbuch.

Eine FULL-Version hatte ich zwar von Anfang an vorgesehen, aber nach den 
bisherigen Rückmeldungen werde ich mir den extra Aufwand sparen können.

Für die FULL-Version hatte ich an einige Erweiterungen gedacht, bei der 
man  u.a. gezielt lange Sprünge per JMP (dann eben nicht mehr für die 
alten ATtinys) und kurze Branch-Befehle statt RJMP erzwingen kann (wenn 
dann nicht der Assembler zu große Sprungweite reklamiert). Auch 
16-Bit-Abfragen (statt bisher 8-Bit-Abfragen) hatte ich angedacht.

Solche Details für Verbesserungen und Erweiterungen hätte ich in der Tat 
gerne hier diskutiert (deshalb urspünglich in "Projekte & Code" 
gepostet) anstatt meinen Vorschlag hier rechtfertigen zu müssen. Sei's 
drum ...

[Rainer V. (Gast)]

Hallo, meine Empfehlung ist hier eindeutig Forth, auch für Anfänger! Es 
bringt alles mit, was der TO machen möchte und einarbeiten muß man sich 
ja sowieso...also

Gruß Rainer

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

Falk B. schrieb:
> Aha, du erfindest als den Macroassembler neu.

Klingt mir eher nach PL/M.  Für den Z8 hätte mich das ja damals noch
interessiert, aber heutzutage?

Edit: PLZ meinte ich, PLZ/ASM genauer gesagt.

[Eberhard H. (sepic)]

Marc V. schrieb:

>     ;02// FOR rchk := #16 ; loop 16 times
>     LDI   rchk,16         ;* <--- rchk soll ein (unerfahrener 
> Asmprogrammierer) selbst definieren ?
>

>  Was ist wenn der (unerfahrene) Programmierer R10 als rchk definiert ?

Dieses Register hat der Assembler-Programmier (nämlich ich) als Teil 
eines umfangreichen Testprogramms festgelegt, nicht der Compiler.

Nochmals: Es geht darum, weiterhin in purem AVR-Assembler zu 
programmieren und die volle Kontrolle über das Programm zu behalten, 
aber mit strukturierten Sprachelementen (u.a. der Übersichtlichkeit 
wegen), damit man nicht unendlich viele Sprungadressen erfinden und 
nicht mehr lange überlegen muss, wie die Status-Bits bei einer 
Programmverzweigung nun richtig abgefragt werden müssen, damit der 
Sprung an die richtige Stelle erfolgt etc.

>  Weiter schreibst du:
>
> Eberhard H. schrieb:
>> höheren Programmiersprachen bekannten Sprachelemente für strukturierte
>> Programmierung**, wie z.B. IF/ELSEIF/ELSE, WHILE, REPEAT, FOR und LOOP,
>> die im Programm beliebig oft und beliebig tief geschachtelt werden
>> können.
>
>  Und das ist schon mal entweder Blödsinn oder gelogen.

Ich habe keinen Grund, Blödsinn zu erzählen oder gar zu lügen.

>  So, wie das auf deiner Webseite übersetzt worden ist, geht es
>  höchstens 16 Mal und dem Programmierer bleiben genau *Null*
>  Register übrig.
>  Zieht man die X, Y und Z Register ab, bleiben furs Programm nur noch
>  10 Register übrig und dem Programmierer bleiben ?

>  Genau, wieder gar keine...

Du hast es noch nicht ganz verstanden (und andere wohl auch noch nicht): 
Der Compiler verwendet nur die vom Programmierer festgelegten Register, 
nicht ein einziges anderes.

Aber nur Geduld, das wird schon noch ...

Hier zunächst nochmals dein strukturiertes Assembler-Programm (die 
diversen FOR-Schleifenregister müssen natürlich vorher definiert worden 
sein):

  FOR achk := #16   ; loop 16 times
    FOR brchk := #16   ; loop 16 times
      EXITIF achk==8
      FOR crchk := #16   ; loop 16 times
        FOR dchk := #16   ; loop 16 times
          FOR echk := #16   ; loop 16 times
            WHILE rchk <= #16 ; count from 1 through 16
              rcall chkok
              inc rchk
            ENDW
            rcall chkok
          ENDF
        ENDF
      ENDF
    ENDF
  ENDF
ex:  rjmp ex

chkok:
    ldi  r16, 8
    ldi  zl, 17
    clr  zh
fill:
    st  Z+, r16
    dec  r16
    brne  fill
    ret

Und hier was s'ASM daraus gemacht hat (1:1-Kopie aus der .asm-Datei von 
Atmel-Studio):

; -------------------------------------------------------------------------
; s'AVR - Precompiler for Structured AVR Assembly by Eberhard Haug (C) 2017
; Version 1.04 (BETA), compiled 05-FEB-2017.
; This is the Lite version using RJMP (+/- 2k address range) and no JMP.

; s'AVR File compiled: 06.04.2017 17:41:28
; Please report any bugs by email to [e-mail]

; No liability accepted for any code generated by s'AVR!
; -------------------------------------------------------------------------

  ;01// FOR achk := #16   ; loop 16 times
  LDI  achk,16
_L1:
  ;02// FOR brchk := #16   ; loop 16 times
  LDI  brchk,16
_L4:
  ;02// EXITIF achk==8
  CP  achk,8
  BRNE  _L5
  RJMP  _L6
_L5:
  ;03// FOR crchk := #16   ; loop 16 times
  LDI  crchk,16
_L8:
  ;04// FOR dchk := #16   ; loop 16 times
  LDI  dchk,16
_L11:
  ;05// FOR echk := #16   ; loop 16 times
  LDI  echk,16
_L14:
  ;06// WHILE rchk <= #16 ; count from 1 through 16
_L17:
  CPI  rchk,16
  BRLO  _L18
  BREQ  _L18
  RJMP  _L19
_L18:
  rcall chkok
  inc rchk
  ;06// ENDW
  RJMP  _L17
_L19:
  rcall chkok
  ;05// ENDF
  DEC  echk
  BREQ  _L15
  RJMP  _L14
_L15:
  ;04// ENDF
  DEC  dchk
  BREQ  _L12
  RJMP  _L11
_L12:
  ;03// ENDF
  DEC  crchk
  BREQ  _L9
  RJMP  _L8
_L9:
  ;02// ENDF
  DEC  brchk
  BREQ  _L7
  RJMP  _L4
_L7:
_L6:
  ;01// ENDF
  DEC  achk
  BREQ  _L2
  RJMP  _L1
_L2:
ex:  rjmp ex

chkok:
  ldi  r16, 8
  ldi  zl, 17
  clr  zh
fill:
  st  Z+, r16
  dec  r16
  brne  fill
  ret

; s'AVR lines read: 27
; Lines generated: 86
; Errors detected: 0
; Warnings/Hints noted: 0

Das ist bewusst ein flaches unstrukturiertes Assembler-Programm mit 
vielen vom Compiler erzeugten Adressen, das man aber nur im Fehlerfall 
(!) anschauen muss, nämlich um ggf. Fehlerhinweise mit zugehörigen 
Zeilennummern der in Atmel Studio gleichzeitig geöffneten .s-Datei zu 
überprüfen. Ansonsten wird es einfach von AVRASM2 assembliert, ggf. mit 
dessen eigenen Fehlermeldungen.

> Eberhard H. schrieb:
>> Die vorgestellte Version ist eine Lite-Version, da lässt sich mit einer
>> solchen Einschränkung (wenn es immer wirklich eine ist) durchaus leben.
>
>  D.h. du machst Werbung für eine Version, die angeblich viel mächtiger
>  sein soll, dafür aber nicht frei ?

Details siehe meinen vorigen Beitrag.

[c-hater (Gast)]

Eberhard H. schrieb:

> Über die "Eleganz" von Programmiersprachen/Methoden lässt sich bestimmt
> trefflich streiten.

Da brauchen wir überhaupt nicht drüber zu streiten. Der Punkt ist 
nämlich: das, was du tust ist auch nix anderes als Macroprogrammierung. 
Du nutzt dafür nur nicht die vorhandene Macrosprache des Assemblers, 
sondern brauchst ein externes Programm dafür.

Und du ziehst nichtmal Vorteile aus der Verwendung eines externen 
Programms, denn alles, was du hier gezeigt hast, geht auch mit der 
eingebauten Macrosprache des avrasm2 zu realisieren. Sogar noch etwas 
mehr, denn bei Schleifen, bei denen die Bedingungsprüfung am Ende 
passiert, könnte man sogar noch die Sprungvarianten optimieren. Also 
zumindest für diesen Teil das tun, was du erst für die 
Full-Featured-Version deines Programms versprichst...

Und dann ist da noch die Verkomplizierung des Buildvorgangs als 
eindeutigen Nachteil der Variante mit einem externen Programm als 
Macrointerpreter. Das brutal Lustige ist dabei ist übrigens: das müßte 
nichtmal so sein. Man könnte sowas relativ problemlos so in's Studio 
(5+) integrieren, das der Buildvorgang aus Benutzersicht ganz genauso 
abläuft wie ohne die Erweiterung. Damit wäre dann wenigstens Gleichstand 
beim Komfort hergestellt. Es wäre aber immer noch kein substantieller 
Vorteil für deine Lösung in Sicht.

Das einzige, was nämlich so eine Lösung leisten könnte und was mit der 
eingebauten Macrosprache definitiv nicht geht, ist die Optimierung von 
Vorwärtssprüngen, für also bei IF und allen kopfgesteuerten Schleifen. 
Das allerdings würde dann aus dem Zweipass-Assembler einen 
Vierpass-Assembler machen müssen, sprich: die Assemblierzeit verdoppeln. 
Aber OK, bei den Popelprogrammen, die deine Zielgruppe schreibt, spielt 
das sicher noch keinerlei Rolle...

[Holm T. (Gast)]

Mich erinnert das an PLZ/ASM ..gabs für Z80, Z8 und Z8000..

Gruß,

Holm

[Xenon (Gast)]

Assembler ist meine "Muttersprache", seit über 30J. Echte AssCoder sind 
Freaks, wie ich. Die so was nicht benutzen wollen werden. Freaks 
benutzen nur das was sie selber gemacht haben.

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

Xenon schrieb:
> Freaks benutzen nur das was sie selber gemacht haben.

Hast du deinen Assembler denn selbst geschrieben?  In Assemblercode? ;-)

[Carl D. (jcw2)]

Vor 30J gab's halt keine "billigen" professionellen Compiler, aber heute 
laß ich mir lieber vom GCC Sprungmarken und Register verwalten. Für 
"umme", wie man hier sagt. Der kann die von mir benutzten Architekturen 
das kleine und das große A, PC-Zeugs und wenn ich man ganz nostalgisch 
werd sogar Mainframe. All die Dinger kann ich auch in ASM programmieren, 
aber wozu?
Und das wird nicht besser durch einen neuen "Compiler", der für eine 
Plattform die Nachteile von C und ASM vereint.

[Schoko (Gast)]

c-hater schrieb:
> Aber OK, bei den Popelprogrammen, die deine Zielgruppe schreibt, spielt
> das sicher noch keinerlei Rolle..

Sag das nicht. Einige meiner Asm-Programme gehen weit über 10KB hinaus. 
Der Sinn des hier vorgestellten Programms erschließt sich mir aber auch 
nicht. Der trainierte Programmierer kann doch auf das bischen Hilfe bei 
Verzweigungen und Vergleichen locker verzichten (und spart zusätzlich 
noch an Quelltext). Selbst Makros sind verzichtbar.

[Marc V. (Firma: Vescomp) (logarithmus)]

Eberhard H. schrieb:
> Du hast es noch nicht ganz verstanden (und andere wohl auch noch nicht):
> Der Compiler verwendet nur die vom Programmierer festgelegten Register,
> nicht ein einziges anderes.

 LOL.
 Du hast es nicht verstanden.
 Wie soll das dann beliebig oft und beliebig tief verschachtelt werden ?

Eberhard H. schrieb:

  LDI  achk,16
...
  LDI  brchk,16
...
  LDI  crchk,16
...
  LDI  dchk,16
...
  LDI  echk,16

 Das sind schon 5 Register, welche der Programmierer in seinem Programm
 ruhig vergessen kann...
 Das reimt sich aber bestimmt nicht mit beliebig oft und beliebig
 tief verschachtelt.
 Bei deiner "Lösung" sind es gerade die Register R16 und höher und die
 hebt man sich als Assemblerprogrammierer für etwas besseres auf...

 Und ich will deinen Programm gar nicht mal schlecht machen, muss aber
 Falk (wenn auch nur ungern) Recht geben:
Falk B. schrieb:
> Darum geht es gar nicht, sondern ums Grundkonzept. Halb Fisch, halb
> Fleisch. Nicht mein Geschmack.

 Ein Register nur für Macros zu opfern und dann Macros zu schreiben,
 um bestimmte Befehle auszuführen ist doch viel besser und sinnvoller.
 Entweder man kann Assembler oder man kann es nicht.
 Und wenn man Assembler kann und in Assembler programmiert gibt es viel
 nützlichere Sachen die man z.B. mit Macros machen kann, anstatt nur
 Schleifen und Abfragen mit deinem Preprocessor.
 Vor allem, da man dafür die kostbaren R16-R31 opfern muss...

 Das ist natürlich nur meine Meinung...

 P.S.
 Hab gerade mal meine alten Macros durchgestöbert, hier ist etwas:

  ;*
  .macro SetRamBit ; RamAdr, Flag
      lds  MacReg, @0
      sbr  MacReg, 1<<@1
      sts  @0, MacReg
  .endmacro

 Und irgendwo im Programm:

      tst  r18
      brne  TimChk_x
      SetRamBit TimCtrlByt, TimOut    ;* Set UserFlag for Timeout...  ; 5

 Und noch weiter im Programm:

      ChkRamBit TimCtrlByt, TimOut    ;* Check UserFlag for Timeout
      brne  NoTimOut

 Das ist viel übersichtlicher als der Code der im Macro definiert ist
 und auch noch nach ein paar Monaten leicht zu verstehen.

[Possetitjel (Gast)]

Falk B. schrieb:

> "Kritik stellt für die meisten Menschen ein Problem dar."

Korrekt.

Sie sind naemlich unfaehig, die Kritik SACHLICH zu
formulieren.
Kritikkompetenz hat, wie das meiste im Leben, zwei
Seiten.

[Eberhard H. (sepic)]

c-hater schrieb:
> Eberhard H. schrieb:
>
>> Über die "Eleganz" von Programmiersprachen/Methoden lässt sich bestimmt
>> trefflich streiten.
>
> Da brauchen wir überhaupt nicht drüber zu streiten. Der Punkt ist
> nämlich: das, was du tust ist auch nix anderes als Macroprogrammierung.

Nicht wirklich. Das Gegenbeispiel mit Macros für ein sinnvolles 
Assembler-Programm steht noch aus.

> Du nutzt dafür nur nicht die vorhandene Macrosprache des Assemblers,
> sondern brauchst ein externes Programm dafür.

Stimmt.

> Und du ziehst nichtmal Vorteile aus der Verwendung eines externen
> Programms, denn alles, was du hier gezeigt hast, geht auch mit der
> eingebauten Macrosprache des avrasm2 zu realisieren.

Ich habe nirgends bestritten, dass es mit Assembler-Macros nicht geht, 
ein AVR-Assembler-Programm strukturiert zu schreiben (im Gegenteil). 
Aber wir sind nun doch wieder bei der "Eleganz". ;-)

> Und dann ist da noch die Verkomplizierung des Buildvorgangs als
> eindeutigen Nachteil der Variante mit einem externen Programm als
> Macrointerpreter. Das brutal Lustige ist dabei ist übrigens: das müßte
> nichtmal so sein. Man könnte sowas relativ problemlos so in's Studio
> (5+) integrieren, ...

Wie das gemacht wird, steht im Handbuch S. 26 beschrieben.

Nach Erstellen des strukturierten Quellprogramms mit dem 
Atmel-Studio-Editor (Dateierweiterung .s) wird mit nur zwei zusätzlichen 
Mausklicks (Tools/s'AVR) das flache Assembler-Programm erzeugt 
(Dateierweiterung .asm). Mit dem Loslassen der Maustaste ist das bereits 
erledigt.

Ab hier wird assembliert wie bisher und das Programm in den AVR 
gebrannt.

> Aber OK, bei den Popelprogrammen, die deine Zielgruppe schreibt, spielt
> das sicher noch keinerlei Rolle...

Die Zielgruppe sind grundsätzlich AVR-Assembler-Programmierer, die sich 
- nach einer kurzen Einarbeitung (das Handbuch lesen schadet selten) - 
das Leben leichter machen wollen, sowohl "Popel"-Anfänger, als auch 
solche, die z.B. ein 30-seitiges AVR-Assembler-Programm schneller 
erfolgreich zum Laufen bringen möchten - auch wenn es nur zu 95% 
optimiert ist.

Die absoluten AVR-Assembler-Gurus, die schon ihr ganzes Leben lang 
ausschließlich in Assembler-Sprache denken, programmieren und vielleicht 
sogar träumen, kann ich sicher nicht ansprechen (und will ich auch 
nicht).

Wie eingangs (und auf meiner Website) erwähnt, habe ich das Rad der 
strukturierten Assembler-Programmierung nicht neu erfunden, sondern nur 
einen Vorschlag (und dessen Umsetzung) für ein Tool zur strukturierten 
AVR-Assembler-Programmierung gemacht, da mir bis dato nicht bekannt ist, 
dass es ein solches Tool kostenlos oder für wenig Geld für die 
8-Bit-AVR-µController gibt.

[Dieter F. (Gast)]

Possetitjel schrieb:
> SACHLICH

Seit wann denn das? Hier wird emotional diskutiert. (Punkt):-)

[Eberhard H. (sepic)]

Schoko schrieb:
> c-hater schrieb:
>> Aber OK, bei den Popelprogrammen, die deine Zielgruppe schreibt, spielt
>> das sicher noch keinerlei Rolle..
>
> Sag das nicht. Einige meiner Asm-Programme gehen weit über 10KB hinaus.
> Der Sinn des hier vorgestellten Programms erschließt sich mir aber auch
> nicht. Der trainierte Programmierer kann doch auf das bischen Hilfe bei
> Verzweigungen und Vergleichen locker verzichten (und spart zusätzlich
> noch an Quelltext).

Das strukturiert geschriebene Assembler-Programm ist im Normalfall 
deutlich kürzer als ein flaches Assembler-Programmm, von den anderen 
genannten Vorteilen der strukturierten Programmierung (unabhängig von 
meinem Vorschlag) ganz zu schweigen.

[Dieter F. (Gast)]

Eberhard H. schrieb:
> Precompiler

Jetzt mal im Ernst - von einem "...compiler" erwarte ich, dass ich nicht

Eberhard H. schrieb:
> (die
> diversen FOR-Schleifenregister müssen natürlich vorher definiert worden
> sein)

muss - oder?

O.K - ich bin kein Assembler-Programmierer - habe damit aber schon 
rumgespielt. Wenn ich mich um die Register-Zuordnung noch kümmern muss 
kann ich auch Makros nutzen.

[Eberhard H. (sepic)]

Marc V. schrieb:
> Eberhard H. schrieb:
>> Du hast es noch nicht ganz verstanden (und andere wohl auch noch nicht):
>> Der Compiler verwendet nur die vom Programmierer festgelegten Register,
>> nicht ein einziges anderes.
>
>  LOL.
>  Du hast es nicht verstanden.
>  Wie soll das dann beliebig oft und beliebig tief verschachtelt werden ?
>
> Eberhard H. schrieb:
>

>   LDI  achk,16
> ...
>   LDI  brchk,16
> ...
>   LDI  crchk,16
> ...
>   LDI  dchk,16
> ...
>   LDI  echk,16
>

>
>  Das sind schon 5 Register, welche der Programmierer in seinem Programm
>  ruhig vergessen kann...

Nein, er kann sie nicht vergessen, denn es wird einen Grund dafür geben, 
dass er sie so festgelegt und verwendet hat.

>  Das reimt sich aber bestimmt nicht mit *beliebig oft und beliebig*
>  tief verschachtelt.
>  Bei deiner "Lösung" sind es gerade die Register R16 und höher und die
>  hebt man sich als Assemblerprogrammierer für etwas besseres auf...

Natürlich kann man nicht mehr Register verwenden, als der µController 
hat.

Wohlgemerkt: Die klare Vorgabe war, dass der Assembler-Pogrammierer die 
100%ge Kontrolle über alle Register hat und deren Verwendung festlegt, 
nicht der Compiler.

Wenn dabei etwas schief geht, hat der Programmierer versagt.

>  Ein Register nur für Macros zu opfern und dann Macros zu schreiben,
>  um bestimmte Befehle auszuführen ist doch viel besser und sinnvoller.

Das Festlegen des Macro-Registers macht auch der Programmierer und nicht 
das Macro.

>  Entweder man kann Assembler oder man kann es nicht.
>  Und wenn man Assembler kann und in Assembler programmiert gibt es viel
>  nützlichere Sachen die man z.B. mit Macros machen kann, anstatt nur
>  Schleifen und Abfragen mit deinem Preprocessor.
>  Vor allem, da man dafür die kostbaren R16-R31 opfern muss...

Nochmals: Der Compiler verwendet nur die vom Assembler-Programmierer 
festgelegten Register. Keine anderen.

[c-hater (Gast)]

Eberhard H. schrieb:

>> Da brauchen wir überhaupt nicht drüber zu streiten. Der Punkt ist
>> nämlich: das, was du tust ist auch nix anderes als Macroprogrammierung.
>
> Nicht wirklich.

Doch. Wenn du das nicht begreifen kannst, fehlen dir einfach nur die 
fachlichen Grundlagen...

> Das Gegenbeispiel mit Macros für ein sinnvolles
> Assembler-Programm steht noch aus.

Das ist aber "full-featured". Mit Ausnahme dessen, was mit der 
eingebauten Macrosprache einfach mal nicht geht, siehe voriges Posting, 
dort schreibe ich sehr exakt, was der einzige Punkt wäre, bei dem du mit 
deinem Ansatz punkten könntest.

Aber eben doch "full-featured" im Rahmen der theoretischen 
Möglichkeiten. Wieviel möchtest du also für die Quelltextlizenz 
bezahlen?

> wird mit nur zwei zusätzlichen
> Mausklicks

Zwei Mausklicks extra für ein Build? Das sind 200% Mehraufwand! Und 
dafür auch noch bezahlen? Du hast sie doch nicht alle!

[Eberhard H. (sepic)]

Dieter F. schrieb:
> Eberhard H. schrieb:
>> Precompiler
>
> Jetzt mal im Ernst - von einem "...compiler" erwarte ich, dass ich nicht
>
> Eberhard H. schrieb:
>> (die
>> diversen FOR-Schleifenregister müssen natürlich vorher definiert worden
>> sein)
>
> muss - oder?

Doch, denn die grundsätzliche Aufgabe des vorgestellten Tools* ist 
ausschließlich die Unterstützung der strukturierten 
AVR-Assembler-Programmierung (siehe Überschrift, Handbuch und alles 
bisher von mir Geschriebene) und zwar so, dass der Programmierer die 
100%ige Kontrolle über alle AVR-Register hat.

> O.K - ich bin kein Assembler-Programmierer - habe damit aber schon
> rumgespielt. Wenn ich mich um die Register-Zuordnung noch kümmern muss
> kann ich auch Makros nutzen.

Stimmt --> "Eleganz".

Das vorgeschlagene Konzept hat mit einem Compiler für eine höhere 
Programmiersprache überhaupt nichts zu tun.
Es geht weiterhin um 100% Assembler - strukturiert eben.

Was ist daran so schwer zu verstehen?

* Sei es der Einfachheit halber ein "Compiler" (ein sehr allgemeiner 
Begriff), ein Precompiler oder was auch immer.

[Dieter F. (Gast)]

Eberhard H. schrieb:
> Wohlgemerkt: Die klare Vorgabe war, dass der Assembler-Pogrammierer die
> 100%ge Kontrolle über alle Register hat und deren Verwendung festlegt,
> nicht der Compiler.
>
> Wenn dabei etwas schief geht, hat der Programmierer versagt.

Da sich unsere Post's scheinbar überschnitten haben nochmal:

Dieter F. schrieb:
> Eberhard H. schrieb:
>> Precompiler
>
> Jetzt mal im Ernst - von einem "...compiler" erwarte ich, dass ich nicht
>
> Eberhard H. schrieb:
>> (die
>> diversen FOR-Schleifenregister müssen natürlich vorher definiert worden
>> sein)
>
> muss - oder?
>
> O.K - ich bin kein Assembler-Programmierer - habe damit aber schon
> rumgespielt. Wenn ich mich um die Register-Zuordnung noch kümmern muss
> kann ich auch Makros nutzen.

[Rauher Geselle (Gast)]

c-hater schrieb:
> Zwei Mausklicks extra für ein Build? Das sind 200% Mehraufwand! Und
> dafür auch noch bezahlen? Du hast sie doch nicht alle!

Marc V. schrieb:
> Und das ist schon mal entweder Blödsinn oder gelogen.

Beschimpfungen, Beleidigungen....

Ein wirklich feiner Umgang miteinander. Alle Achtung.

Ich bin aus gutem Grund abgemeldet.

[Possetitjel (Gast)]

Eberhard H. schrieb:

> Das vorgeschlagene Konzept hat mit einem Compiler für
> eine höhere Programmiersprache überhaupt nichts zu tun.
> Es geht weiterhin um 100% Assembler - strukturiert eben.
>
> Was ist daran so schwer zu verstehen?

Die Willkuer Deiner Zielstellung.

Du betreibst aus meiner Sicht im Wesentlichen etwas Kosmetik.
Ich sage gar nicht mal, dass Deine Kritikpunkte nicht
zutreffend waeren - aber fuer die Mehrzahl der hier vertretenen
Diskussionsteilnehmer stimmt das Aufwand-Nutzen-Verhaeltnis
Deiner Ideen offensichtlich nicht.

Das, was Du loesen willst, wird augenscheinlich von den
wenigsten als ein so groszes Problem wahrgenommen, dass der
Einsatz eines separaten Tools gerechtfertigt waere.

Es gibt aus meiner Sicht einige wirklich substanzielle Kritik-
punkte an den ueblichen Assemblersprachen, aber um die machst
Du einen Bogen. Du beschraenkst Dich auf Windows, auf AVR, auf
Steueranweisungen ("strukturierte Programmierung").

Und wer jetzt "C existiert!" einwerfen moechte, dem entgegne
ich: Der Faustkeil existiert auch.

[Marc V. (Firma: Vescomp) (logarithmus)]

Eberhard H. schrieb:
> Wohlgemerkt: Die klare Vorgabe war, dass der Assembler-Pogrammierer die
> 100%ge Kontrolle über alle Register hat und deren Verwendung festlegt,
> nicht der Compiler.

 Wenn er aber dafür für jede verschachtelte Schleife einen Register
 opfern muss - wo ist da der Vorteil und 100%ige Kontrolle ?

Eberhard H. schrieb:
> Nicht wirklich. Das Gegenbeispiel mit Macros für ein sinnvolles
> Assembler-Programm steht noch aus.

 Eine IF-Abfrage mit Macros ist trivial aber nutzlos, eine WHILE, REPEAT
 und FOR Schleife dagegen nicht, da hast du Recht.
 Mit Macros sind Schleifen natürlich nicht zu schaffen. Inwieweit so
 etwas aber überhaupt sinvoll ist, ist eine andere Frage.

 Man kann sich auch angewöhnen, komplizierte Schleifen übersichtlicher
 zu schreiben, etwa so:

l1:             ldi  MacReg, 16
Loop_1:         push  MacReg
;...   Platz für beliebigen CODE [Alle Register, sogar MacReg können frei benutzt werden]
;...   Platz für beliebigen CODE [Alle Register, sogar MacReg können frei benutzt werden]

L1_x:           pop  MacReg
                dec  MacReg
                brne  Loop_1

 Später kommt noch eine verschachtelte Schleife dazu:

l1:             ldi  MacReg, 16
Loop_1:         push  MacReg
;...   Platz für beliebigen CODE [Alle Register, sogar MacReg können frei benutzt werden]

l2:             ldi  MacReg, 24
Loop_2:         push  MacReg

;...   Platz für beliebigen CODE [Alle Register, sogar MacReg können frei benutzt werden]

L2_x:           pop  MacReg
                dec  MacReg
                brne  Loop_2

;...   Platz für beliebigen CODE [Alle Register, sogar MacReg können frei benutzt werden]

L1_x:           pop  MacReg
                dec  MacReg
                brne  Loop_1

 Und das kann wirklich beliebig tief verschachtelt werden.
 Aber, wie schon gesagt, inwieweit ist das überhaupt sinnvoll ?

 P.S.
 Natürlich darfst du diesen Code benutzen und Code für deinen
 Preprocessor dementsprechend ändern ;-)

[Marc V. (Firma: Vescomp) (logarithmus)]

Rauher Geselle schrieb:
> Marc V. schrieb:
>> Und das ist schon mal entweder Blödsinn oder gelogen.
>
> Beschimpfungen, Beleidigungen....

 Nein.
 Nur habe ich, im Gegensatz zu dir, Ahnung von Assembler.


> Ich bin aus gutem Grund abgemeldet.

 Fehlende Kenntnise um etwas sinnvolles schreiben zu können ?

[Dr. Sommer (Gast)]

Gibt's dann auch einen Compiler der OOP für ASM nachrüstet... und ein 
Typ System, und Metaprogrammierung?

[Patrick J. (ho-bit-hun-ter)]

Hi

Marc V. schrieb:
> Wenn er aber dafür für jede verschachtelte Schleife einen Register
>  opfern muss - wo ist da der Vorteil und 100%ige Kontrolle ?

Das Problem sehe ich hier aber nicht wirklich.
Selber habe ich die Makros zur strukturierten Programmierung zusammen 
gesaugt (aber noch nicht wirklich benutzt), dort gibt man beim Aufruf 
auch das Register an, was für diese Schleife benutzt werden soll.

Hier ist's nicht anders - sehe Da jetzt keinen Nachteil drin.

Worin ich aber Nachteile sehe:
- eine EXE aus unbekannter Quelle - auch wenn der Progger nichts Böses 
im Sinn hat, muß Das nicht für Dessen System stimmen
- eine EXE läuft auf Windows - wurde das Programm auch mit wine (Linux) 
getestet? (wobei ich ein Win in der Box nutze)
- meine Schleifen-Makros machen, meiner Meinung nach, das Gleiche, sind 
aber im Studio simulierbar (ok, auch wieder Win - Das aus 'der Box)
- wenn ich mein .s-Programm vor-compiliert habe, bekomme ich ein 
'unstrukturiertes' ASM-Listing zum Debuggen, wo zur Fehlersuche 
sämtliche Vorteile wieder weg sind, weder die (Schleifen-)Register noch 
die Sprungmarken dazu haben 'sprechende' Namen

Ich respektiere die Arbeit und den eingesetzten Hirn-Schmalz, sehe aber, 
für mich, keinen Vorteil meiner jetzigen Lösung mit den Makros (sollte 
ich Diese Mal verwenden) - noch komme ich mit 0-8-15 Schleifen aus, Die 
zu 99% Allesamt rückwärts zählen.

MfG

[Marc V. (Firma: Vescomp) (logarithmus)]

Patrick J. schrieb:
> Das Problem sehe ich hier aber nicht wirklich.

 Ich aber sehe genau da ein Riesenproblem.

 Auch die Aussage:
Eberhard H. schrieb:
> Programmierung**, wie z.B. IF/ELSEIF/ELSE, WHILE, REPEAT, FOR und LOOP,
> die im Programm beliebig oft und beliebig tief geschachtelt werden
> können.

 stimmt selbstverständlich nicht.
 Und wenn ich schon die Register für Schleifen selbst definieren muss,
 ist jeglicher Vorteil dahin.

Patrick J. schrieb:
> - meine Schleifen-Makros machen, meiner Meinung nach, das Gleiche, sind
> aber im Studio simulierbar (ok, auch wieder Win - Das aus 'der Box)

 Diese Schleifen-Makros würde ich gerne sehen...

[Dieter F. (Gast)]

Patrick J. schrieb:
> - eine EXE aus unbekannter Quelle - auch wenn der Progger nichts Böses
> im Sinn hat, muß Das nicht für Dessen System stimmen
> - eine EXE läuft auf Windows - wurde das Programm auch mit wine (Linux)
> getestet? (wobei ich ein Win in der Box nutze)

Hast Du irgend etwas nicht verstanden? Wir diskutieren über die 
AVR-Ebene - wo gibt es da .EXE?

[Patrick J. (ho-bit-hun-ter)]

Hi

Nur einen Klick entfernt:
http://www.schramm-software.de/tipps/makros.htm
(hat also doch was, wenn man die Quelle des Makro in die Datei aufnimmt)

Das kam mir heute 'vor die Flinte' und möchte Mal genauer betrachtet 
werden
Beitrag "Re: Strukturierte AVR-Assembler-Programmierung"

Dürfte hier wohl bekannt sein:
https://www.mikrocontroller.net/articles/AVR_Assembler_Makros

Zusammen kopiert: ja
Alles davon bereits Mal produktiv genutzt: nein, bei Weitem nicht :)

MfG

[Carl D. (jcw2)]

Dieter F. schrieb:
> Patrick J. schrieb:
>> - eine EXE aus unbekannter Quelle - auch wenn der Progger nichts Böses
>> im Sinn hat, muß Das nicht für Dessen System stimmen
>> - eine EXE läuft auf Windows - wurde das Programm auch mit wine (Linux)
>> getestet? (wobei ich ein Win in der Box nutze)
>
> Hast Du irgend etwas nicht verstanden? Wir diskutieren über die
> AVR-Ebene - wo gibt es da .EXE?

Noch mal lesen, nachdenken und neu bewerten!

[Patrick J. (ho-bit-hun-ter)]

Eberhard H. schrieb:
> * Alle Versionen von WIN98SE bis WIN10 werden unterstützt.

Eberhard H. schrieb:
> *** Kostenlos natürlich. Dann bitte angeben, welches Dateiformat
> gewünscht ist: ca. 600kB als EXE, nur halb so groß als ZIP (oder 7Z).

So wie ich hier gelesen habe, wird zwischen ASM-Programmieren und 
Assemblieren ein Zwischenschritt eingefügt, damit die strukturelle 
Programmierung 'compiliert' wird - Das macht, meinem Verständnis nach, 
'die EXE'. (Nicht die 600kB-Exe, Die wird zur Installation des 
Pre-Compilers dienen)

Sollte ich damit falsch liegen, bitte ich um Korrektur.

MfG

[Axel S. (a-za-z0-9)]

Jörg W. schrieb:

> Klingt mir eher nach PL/M.  Für den Z8 hätte mich das ja damals noch
> interessiert, aber heutzutage?
>
> Edit: PLZ meinte ich, PLZ/ASM genauer gesagt.

Ha! PL/M hatte ich auch noch im Hinterkopf, aber die allwissende
Müllhalde präsentierte unter diesem Namen etwas anderes.

PLZ/ASM wird es wohl sein. Gab es auch für Z80^W U880, früher als
ich noch mit CP/A rumgemacht habe ;)

[Feldstecher (Gast)]

Marc V. schrieb:
>  Auch die Aussage:
> Eberhard H. schrieb:
>> Programmierung**, wie z.B. IF/ELSEIF/ELSE, WHILE, REPEAT, FOR und LOOP,
>> die im Programm beliebig oft und beliebig tief geschachtelt werden
>> können.
>  stimmt selbstverständlich nicht.
>  Und wenn ich schon die Register für Schleifen selbst definieren muss,
>  ist jeglicher Vorteil dahin.
Die (Haupt-) Funktionalität bei diesem Konstrukt besteht m.E. darin, 
dass die Schleifenlabels automatisch generiert werden. Wenn man ein 
modulares Program mit 100 verteilten Schleifen hat, muss man sich schon 
überlegen, wie man die systematisch und einfach benennt um nicht dauernd 
in Fehlermeldungen mit doppelten Labels zu rasseln. Für diesen geringen 
Luxus ein extra Programm?

Ein Hilfsprogramm, welches ich mir mal programmiert habe, listet für 
jede Funktion die verwendeten Register, alle veränderten und alle 
gepushten/gepopten Register auf. Das war für mich recht hilfreich, weil 
ich doch ab- und zu den Überblick verloren hatte, und Register 
überschrieben wurden. Mit etwas Routine relativiert sich dieses Problem 
aber auch schnell...

[Carl D. (jcw2)]

Axel S. schrieb:
> ... Z80^W U880 ...

Herrlich, wieviele sowas wohl heute noch verstehen ;-)

Wobei ich zugeben muß, daß ich zu Z80 Zeiten keine Ahnung hatte,
daß es einen U880 gibt. Der war zu gut bewacht ;-)

[Marc V. (Firma: Vescomp) (logarithmus)]

Patrick J. schrieb:
> Alles davon bereits Mal produktiv genutzt: nein, bei Weitem nicht :)

 Eben.
 Die wenigsten haben das, weil die meisten nutzlos sind.
 STORE, LOAD, SETB, CLRB, SKBS, SKBC ausgenommen.
 Ansonsten wird, falls nötig, ein Macro speziell für diesen Fall
 geschrieben.

 Dazu kommen aber immer die üblichen Nachteile von Macros - jedesmal
 wird der volle Code reingeschrieben.

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

Feldstecher schrieb:
> Wenn man ein modulares Program mit 100 verteilten Schleifen hat, muss
> man sich schon überlegen, wie man die systematisch und einfach benennt
> um nicht dauernd in Fehlermeldungen mit doppelten Labels zu rasseln.

Man könnte ja auch den GNU-Assembler benutzen und dessen lokale
Labels. ;-)  Da stören die Mehrfachbenennungen dann nicht mehr.

Carl D. schrieb:
> Wobei ich zugeben muß, daß ich zu Z80 Zeiten keine Ahnung hatte, daß es
> einen U880 gibt.

Dafür gab's auf der anderen Seite neben den vielen U880 auch genügend
Zilog-Schaltkreise, die im Original herumfluktuierten.  In meinem
Eigenbau-CP/M-Computer steckt mittlerweile auch einer drin, aber das
war ursprünglich ein Erfurter.  Der Zilog flog mir dann irgendwie nach
1990 zu.

Zu Z8-Zeiten war ich auf PLZ/ASM schon irgendwie neidisch, weil ich
dafür keinen Assembler da hatte, aber am Ende ging's auch so, und heute
ist mir meine Lebenszeit zu schade, irgendwelche ausgiebigen
Assemblerquellen manuell pflegen zu wollen.  Compiler beherrschen diese
Tätigkeit viel besser als ich.

[Carl D. (jcw2)]

Marc V. schrieb:
>
>  Dazu kommen aber immer die üblichen Nachteile von Macros - jedesmal
>  wird der volle Code reingeschrieben.

liegt dann daran, daß der Macroassembler keine ausgefeilte Macrosprache 
hat. Wer mal Buchhaltungsprogramme geschrieben in Mainfraim-ASM gesehen, 
der weiß was ich meine.

[Patrick J. (ho-bit-hun-ter)]

Hi

Marc V. schrieb:
> Dazu kommen aber immer die üblichen Nachteile von Macros - jedesmal
>  wird der volle Code reingeschrieben.

Bei den bedingt assemblierten Makros (z.B. out_ und in_, nutze ich 
eigentlich seit Dem immer) steht das Makro für genau den einen passenden 
Befehl.
Bei dem Delay-Makro wird aus dem Konstrukt auch nur sehr wenig Code 
generiert, halt jedes Mal ein eigener Block, Dieser ist aber das Minimum 
für die Delay-Zeit (keine 10 Befehle).

Sprünge in Makros kann man mit PC (Programm-Counter) definieren.
So lange die Befehle alle gleich lang sind, reicht ein simples Zeilen 
zählen für das Sprungziel - hätte aber auch noch kein Label in einem 
Makro benutzt, könnte auch möglich sein, daß Diese dort anders 
gehandhabt werden - ungetestet.

MfG

[Marc V. (Firma: Vescomp) (logarithmus)]

Patrick J. schrieb:
> Bei den bedingt assemblierten Makros (z.B. out_ und in_, nutze ich
> eigentlich seit Dem immer) steht das Makro für genau den einen passenden
> Befehl.

 Selbstverständlich, das ist bei mir STORE und LOAD, habe ich auch
 oben geschrieben...


> So lange die Befehle alle gleich lang sind, reicht ein simples Zeilen
> zählen für das Sprungziel - hätte aber auch noch kein Label in einem
> Makro benutzt, könnte auch möglich sein, daß Diese dort anders
> gehandhabt werden - ungetestet.

 Ja, werden anders gehandhabt, nämlich gleich umgerechnet.
 Deswegen kannst du 20 Makros welche ein Label "SameLabel" enthalten,
 definieren und es würde trotzdem ohne Fehler durchgehen, weil alle
 Labels nur innerhalb eines Makros gelten.


> Sprünge in Makros kann man mit PC (Programm-Counter) definieren.

 Braucht man aber nicht, s.o.

 Problem sind Sprünge aus dem Makro nach aussen und die ganzen
 hässlichen Konstrukte wo man selber die Register definieren muss.

 Wenn ich schon selber die Register merken und aussuchen muss, dann
 brauche ich auch kein Makro dafür.
 Und wenn der Assembler (oder Preprocessor) das für mich machen soll,
 dann will ich aber nicht die Register dafür selbst aussuchen und von
 da an auf diese Register verzichten müssen.
 Es ist doch ganz einfach - entweder / oder.

 Deswegen ist eine Schleife welche mit einem Makro funktionieren soll
 (wie auch immer zusammengeschustert) ganz einfach Blödsinn.
 Und übersichtlich und nützlich ist das Ganze dann auch nicht mehr.
 Eine Zeile mehr mit Kommentar ist viel übersichtlicher und nützlicher.

;***  LOOP_1 Anfang [ Abfrage auf Taster PINB.2] *********
...
...
;***  LOOP_1 Ende   [ Taster PINB.2 nicht gedrückt]  *****

[ThomasDa (Gast)]

Ich bin heute um 5 Uhr Morgens aufgestanden und hatte dann 1 Std. Zeit 
bevor ich raus musste.
Diesen Thread habe ich angefangen zu lesen bis ich dachte "Stopp! 
Verschwende ich nicht meine kleine Freizeit vor der Arbeit für so ein 
Unsinn mit Anfeindungen".

Das kann man auch als Metapher für seine gesamte Lebenszeit auffassen. 
Next Topic!

[c-hater (Gast)]

Marc V. schrieb:

>  Mit Macros sind Schleifen natürlich nicht zu schaffen.

Unsinn, natürlich geht das.

Für die vom OP angedachte Anwendung sowieso, denn da muss ja nichtmal 
tatsächlich eine Schleife in der Macrosprache programmiert werden. Es 
genügt völlig, sich im Schleifenkopf ein paar Dinge zu merken, auf die 
man dann im Schleifenfuss wieder zugreift. Die eigentliche Schleife 
passiert ja zur Laufzeit, nicht zur Assemble-Zeit.

Man kann darüber hinaus aber sogar wirkliche Schleifen zur Assemble-Zeit 
schaffen, allerdings keine Endlos-Schleifen. Das wäre auch einigermassen 
kontraproduktiv, irgendwann möchte man ja mit Assemblieren auch fertig 
werden. ;o)

[c-hater (Gast)]

Feldstecher schrieb:

> Die (Haupt-) Funktionalität bei diesem Konstrukt besteht m.E. darin,
> dass die Schleifenlabels automatisch generiert werden.

Das kann allerdings auch die eingebaute Macrosprache des Assemblers 
leisten...

[c-hater (Gast)]

Marc V. schrieb:

>  Dazu kommen aber immer die üblichen Nachteile von Macros - jedesmal
>  wird der volle Code reingeschrieben.

Wenn so ein FOR-ENDF-Macropaar richtig geschrieben ist, dann landet am 
Ende im Flash genau nur das, was auch bei manueller Programmierung dort 
landen würde. Einzige Ausnahme: Optimierung für Vorwärtssprünge ist 
nicht möglich, wenn man sich zur Umsetzung der Macros auf die eingebaute 
Macrosprache des Assemblers beschränkt. Mit dem Ansatz des OP wäre aber 
prinzipiell auch das möglich, würde allerdings durch einen zweimaligen 
Lauf des Assemblers erkauft werden müssen.

[Winfried M. (win)]

Man könnte mal umgedreht fragen: Was kann die eingebaute Macrosprache 
nicht oder nicht so elegant, was der hier vorgestellte Präprozessor 
kann?

Und dann wäre auch die Frage, warum nutzt diese eingebaute Möglichkeit 
kaum jemand? Ich hab noch kein Programm gesehen, was die eingebaute 
Macrosprache im Sinne einer strukturierten Programmierung nutzt. 
Zumindest ist das nicht typisch.

In C war es ja schon immer auch ein Graus, exzessiv mit dem Präprozessor 
zu hantieren. Das hat den Code und vor allem fremde Bibliotheken 
regelmäßig unleserlich und unverstehbar gemacht. Oder man brauchte viel 
Zeit. Stroustrup wollte mit C++ auch diese schlechte 
Programmierangewohnheit zurückdrängen. Ich hab mal irgendwo gelesen, er 
hätte ihn am liebsten ganz abgeschafft.

[Jobst M. (jobstens-de)]

Marc V. schrieb:
> Wie soll das dann beliebig oft und beliebig tief verschachtelt werden ?

Wie soll überhaupt beliebig oft und beliebig tief verschachtelt werden?
RAM ist auch begrenzt. Gut, eine sinnvolle Anwendung fällt mir dafür 
auch nicht ein. Ist aber begrenzt.


Jörg W. schrieb:
> Hast du deinen Assembler denn selbst geschrieben?  In Assemblercode? ;-)

Ja. Nein, in einer Scriptsprache.
In Assembler habe ich nur Interpreter geschrieben.
64 Bit Fixkomma Orthodrome auf einem 8051 waren aber aufwändiger.


Eberhard H. schrieb:
> FOR achk := #16   ; loop 16 times
>     FOR brchk := #16   ; loop 16 times
>       EXITIF achk==8
>       FOR crchk := #16   ; loop 16 times
>         FOR dchk := #16   ; loop 16 times
>           FOR echk := #16   ; loop 16 times
>             WHILE rchk <= #16 ; count from 1 through 16
>               rcall chkok
>               inc rchk
>             ENDW
>             rcall chkok
>           ENDF
>         ENDF
>       ENDF
>     ENDF
>   ENDF

Echte ASMänner machen sowas rekursiv! Da wird dann die jeweilige 
Variable auf dem Stack abgelegt. ;-)
(Allerdings weiß ich noch immer nicht, was ich mit diesem konstruierten 
Konstrukt anfangen soll.)


Gruß

Jobst

[c-hater (Gast)]

Winfried M. schrieb:

> Man könnte mal umgedreht fragen: Was kann die eingebaute Macrosprache
> nicht oder nicht so elegant, was der hier vorgestellte Präprozessor
> kann?

Genau das habe ich den OP vor gefühlten 1000 Postings in diesem Thread 
bereits gefragt (und später auch selber detailliert beantwortet)...

> Und dann wäre auch die Frage, warum nutzt diese eingebaute Möglichkeit
> kaum jemand? Ich hab noch kein Programm gesehen, was die eingebaute
> Macrosprache im Sinne einer strukturierten Programmierung nutzt.

Weil's einfach nix wirklich erleichtert.

Ich selber habe meine Macros für strukturierte Programmierung nur aus 
einem einzigen Grund geschrieben: um die Arbeitsweise des des überaus 
schlecht dokumentierten Macrointerpreters des avrasm2 zu erforschen. Sie 
sind also ein reines Abfallprodukt. Mir war von vornherein klar, dass es 
Bullshit sein würde, den niemand braucht. Mein heutiges Wissen um die 
Möglichkeiten und Beschränkungen des Macrointerpreters war das 
eigentliche Ziel der Operation. Denn den die Macrosprache kann man 
tatsächlich deutlich sinnvoller nutzen als für eine öde Teilsimulationen 
strukturierter Programmierung. Wenn ich sowas haben will, dann schreibe 
ich den Code einfach in C, DEM ultimativen Macroassembler...

> In C war es ja schon immer auch ein Graus, exzessiv mit dem Präprozessor
> zu hantieren.

Das ist in Assembler ganz genauso. Aber eben, genau wie in C, oft sehr 
hilfreich...

> Stroustrup wollte mit C++ auch diese schlechte
> Programmierangewohnheit zurückdrängen. Ich hab mal irgendwo gelesen, er
> hätte ihn am liebsten ganz abgeschafft.

Das ist ihm allerdings nicht gelungen und konnte auch nicht gelingen. 
Jedenfalls nicht ohne eine massive Einschränkung der Möglichkeiten. Er 
hat das begriffen. Du auch?

[Wolfgang S. (ws01)]

Falk B. schrieb:
> @Eberhard H. (sepic)
>
>>weiterhin grundsätzlich in Assembler-Sprache, verwendet aber statt
>>Verzweigungs- und Vergleichsabfragen per Assembler-Befehlen die von
>>höheren Programmiersprachen bekannten Sprachelemente für strukturierte
>>Programmierung**, wie z.B. IF/ELSEIF/ELSE, WHILE, REPEAT, FOR und LOOP,
>>die im Programm beliebig oft und beliebig tief geschachtelt werden
>>können.
>
> Aha, du erfindest als den Macroassembler neu.

Er erfindet eine mögliche Anwendung eines Makroassemblers neu.

Das Problem dabei, die Idee hat man schon vor Jahrzehnten ausgiebig 
durchprobiert und weitgehend verworfen. Darüberhinaus gibt es genau 
dort, wo man sich das vielleicht zurückwünscht, keine brauchbaren 
Makroassembler. Been there, done that. So 1975ff herum.

Eine Kollegin hatte einen "LET/IF-Makrosatz" geschrieben, mit dem wir 
unter Verwendung des IBM ASM/H für Grossrechnerbetriebssysteme so eine 
Art CSP-Implementation*) als Alternative zu den damaligen eher 
eindimensionalen Kommandosprachen (pipes, shells) implementierten.

Pfiff der Geschichte war, daß der IBM ASM/H bereits vor dem Makrophase 
in einen vorhergehenden Pass eine komplette Symboltabelle aufbaute 
(komplett mit Offsets, Datentypen, Längen und Alignments), die in der 
Makrophase dann für Fallunterscheiden im Makro schon zur Verfügung 
standen. Natürlich bedurfte es so einer gewissen Disziplin bei der 
Programmierung dieser Makros, um keine Widersprüche zu produzieren, 
jedoch kam man so recht nahe an das heran, was eine höhere 
Programmiersprache ausmacht.  Beispielsweise konnte der LET-Makro auf 
Basis der Datentypen der Operanden die jeweils richtigen bzw. günstigen 
Maschinenbefehle generieren, so daß lästige Typannotationen verzichtbar 
wurden.  Später habe ich dann in einem anderen Projekt diesen Makrosatz 
um Parameterlistenmakros ergänzt (praktisch Prozedurpro- und epilog), 
mit denen man im Makroaufruf z.B. festlegen konnte, wie einzelne 
Parameter zu verstehen waren: Input, Output, Reference, Copy/Return.

Das war aber dann auch schon fast der Abgesang. Die wesentliche 
Anwendung war nämlich die Portierung des Krams nach Siemens BS2000.  Der 
dort verfügbare Assember war zwar weitgehend IBM-kompatibel, aber leider 
nur auf F-Niveau, also reine Textsubstitution.

Der Makrosatz ließ sich portieren, mein Job war dann, aus dem 
Assemblerlisting noch auf der IBM mit einem dafür geschriebenen 
PL/1-Programm die Typannotationen extrahieren und in den Quellcode zu 
übernehmen. Das und auch das resultierende Zielsystem funktionierten 
dann auch ganz ordentlich und wurden termingemäß fertig. Jedoch war das 
ursprünglich recht elegante System durch die fehleranfällig händisch zu 
verwaltenden Typannotationen weitgehend eine Farce geworden.

Jedenfalls war die Luft raus, das oben erwähtne nächste Projekt (eine 
Neuauflage eines Datenbanksystems mit GUI für BS2000) wurde zwar 
zunächst mit den Strukturmakros glattgezogen und so ins Verständliche 
übersetzt, jedoch hat man sich schließlich entschieden, in C einen 
Neuanfang zu manchen. Das hatte zwar eher politische als fachliche 
Gründe und war, soweit ich das noch mitbekommen habe, nicht wirklich ein 
Erfolg, jedoch war es unter den gebotenen Bedingungen (zu denen eben 
auch ein eher untauglicher Makroassembler gehörte) die richtige 
Entscheidung.

Und nein, ein besserer Preprozessor ist nicht die Lösung, außer er 
implementiert den ganzen Assembler gleich mit, den ohne dessen Mithilfe 
steht die Symboltabelle bzw. das Memorylayout nicht zur Verfügung.

IMHO macht man, wenn man Assemblerprogramme wie C zu schreiben versucht, 
heutzutage einen groben Fehler. Wer in die Richtung will, sollte sich 
eher überlegen, wo und wie man die Tauglichkeit von Rust (da spielt die 
Musik, aber es gibt auch andere Ansätze) für embedded development 
verbessern kann.  Das heißt nicht, daß man mit einer 
programmiersprachlich moderneren UND mit der Maschinencodegenerierung 
verschränkten Makrophase in einem Assembler das vielleicht hier und da 
noch nötige Programmieren in Assembler nicht wesentlich eleganter und 
weniger fehleranfällig machen könnte.

*) https://en.wikipedia.org/wiki/Communicating_sequential_processes

[c-hater (Gast)]

Wolfgang S. schrieb:

> Er erfindet eine mögliche Anwendung eines Makroassemblers neu.
>
> Das Problem dabei, die Idee hat man schon vor Jahrzehnten ausgiebig
> durchprobiert und weitgehend verworfen.

NEIN

Das Ergebnis des Durchprobierens der Idee war nämlich immerhin: C.

[Winfried M. (win)]

c-hater schrieb:
> Er
> hat das begriffen. Du auch?

Nö, ich bin nur die Putzfrau. Kapier nix.  ;)

[Marc V. (Firma: Vescomp) (logarithmus)]

c-hater schrieb:
>>  Mit Macros sind Schleifen natürlich nicht zu schaffen.
>
> Unsinn, natürlich geht das.

 Ja, der ursprüngliche Satz ging verloren, edit ging nicht mehr...
 Ist ja egal, eine Schleife mit Macros ist und bleibt Blödsinn -
 Macros sind weder dafür gedacht, noch geeignet - der ganze Krampf
 bringt einfach nix gescheites und nützliches.

 Ich hab seinerzeit einen Preprocessor genau für so etwas geschrieben,
 habe ihn ein paar Mal benutzt und dann nie mehr, obwohl richtige
 Schleifen drin waren:

#for x=8 to 15
...
#next x

 Und es war wirklich beliebig tief zu verschachteln - natürlich durch
 RAM begrenzt aber nicht durch die Anzahl der vorhandenen Register.
 Es bringt aber ganz einfach nichts - weder an übersichtlichkeit noch
 sonstwie, verbraucht Platz am Stack und ist langsamer.
 Ob im Programm brne MyLoop steht oder ENDF ist normalerweise
 so etwas von SCH... EGAL ...
 Ausserdem muss ich bei ENDF erst suchen wo diese Schleife anfängt,
 aber bei brne MyLoop brauche ich das natürlich nicht - soviel zur
 Übersichtlichkeit.

 Dafür habe ich den Postprocessor-Teil behalten, prüfe heute noch
 längere Programme damit, allerdings nur auf benutzte Register, PUSH,
 POP, rcall, branches nach compare oder inc/dec und Anzahl der Takte.

 So etwas finde ich ungemein nützlich - übersichtlicher Listing mit
 allen Routinen, Registern die drin benutzt werden und jede Menge
 Warnungen auf mögliche Konflikte.

 Aber künstliche Schleifen, die dazu kostbare Register R16-R31
 lahmlegen, sind für mich genauso sinnvoll wie ein Sandkasten in der
 Sahara...

[Wolfgang S. (ws01)]

c-hater schrieb:
> Wolfgang S. schrieb:
>
>> Er erfindet eine mögliche Anwendung eines Makroassemblers neu.
>>
>> Das Problem dabei, die Idee hat man schon vor Jahrzehnten ausgiebig
>> durchprobiert und weitgehend verworfen.
>
> *NEIN*
>
> Das Ergebnis des Durchprobierens der Idee war nämlich immerhin: C.

Warum schreibst Du NEIN, wenn Du JA meinst?

Aber Du irrst. C war i.W. als Gegenentwurf zu PL/I motiviert, in Form 
der Reduktion der Ambitionen auf das Machbare, und das auf Basis der 
Erfahrung mit einer ganzen Reihe weiterer und z.T. besserer höherer 
Programmiersprachen. Einige Ideen kamen sogar aus Algol 68.  C ist ganz 
sicher nicht als aufgepeppter oder nachgebauter Strukturmakrosatz oder 
als Alternative zu einem preprocessor entstanden. Wäre das anders, hätte 
der C-eigene macroprocessor sicherlich am Anfang der Entwicklung 
gestanden. Hat er aber nicht.

[c-hater (Gast)]

Wolfgang S. schrieb:

> C ist ganz
> sicher nicht als aufgepeppter oder nachgebauter Strukturmakrosatz oder
> als Alternative zu einem preprocessor entstanden.

Doch, genau das ist der Fall. Mit Ausnahme des "Alternative zu einem 
preprocessor".

Du hast scheinbar nicht verstanden, dass Assemblermacros sehr viel 
mächtiger sind als der C-Präprozessor. Der ist nur reine Textersetzung 
und eine Möglichkeit zur bedingten Kompilierung. Assemblermacros aber 
sind eine Interpretersprache, die zur Assemblierzeit abgearbeitet wird.

Und genau mit so etwas wurden die ersten Inkarnationen eines C-Compilers 
gebaut. Ob du das nun wahrhaben willst oder nicht.

Natürlich wurde das frisch gebaute Werk dann (wie auch heute noch 
üblich) als erstes dazu benutzt, sich selbst zu kompilieren...

Aber es bleibt die unveränderliche Tatsache: Stammvater ALLER 
C-Compiler ist ein Makroassembler. Und es bleibt weiterhin die Tatsache: 
Auch heute noch ist ein C-Compiler im Kern nix anderes als ein 
Makroassembler. Bloss dass er nicht mehr über die mächtige Macrosprache 
seines Stammvaters verfügt. Tja, haploide Vermehrung ist halt potentiell 
degenerativ...

[Carl D. (jcw2)]

c-hater schrieb:
>
> Aber es bleibt die unveränderliche Tatsache: Stammvater *ALLER*
> C-Compiler ist ein Makroassembler. Und es bleibt weiterhin die Tatsache:
> Auch heute noch ist ein C-Compiler im Kern nix anderes als ein
> Makroassembler.

Junge, du sollst nicht soviel Kurt Bindl lesen, das kann labile 
Gestallten krank machen.

[Wolfgang S. (ws01)]

c-hater schrieb:
> Wolfgang S. schrieb:
>
>> C ist ganz
>> sicher nicht als aufgepeppter oder nachgebauter Strukturmakrosatz oder
>> als Alternative zu einem preprocessor entstanden.
>
> Doch, genau das ist der Fall. Mit Ausnahme des "Alternative zu einem
> preprocessor".
>
> Du hast scheinbar nicht verstanden, dass Assemblermacros sehr viel
> mächtiger sind als der C-Präprozessor. Der ist nur reine Textersetzung
> und eine Möglichkeit zur bedingten Kompilierung. Assemblermacros aber
> sind eine Interpretersprache, die zur Assemblierzeit abgearbeitet wird.

Du hast ganz offensichtlich meinen Text in 
Beitrag "Re: Strukturierte AVR-Assembler-Programmierung" nicht gelesen. Oder 
Du hast ihn gelesen, aber nicht verstanden. Oder es ist Dir egal.

>
> Und genau mit so etwas wurden die ersten Inkarnationen eines C-Compilers
> gebaut. Ob du das nun wahrhaben willst oder nicht.

Lies doch einfach, was der Designer und Autor der Sprache dazu 
geschrieben hat.

[Unwissender (Gast)]

Hallo,

ich habe selber nie ASM programmiert (nur in der Ausbildung) und schon 
damals (Ende der 90er) meinten die Entwicklungsingenieure damals zu mir: 
"Assembler wird in der Industrie kaum genutzt (wir benutzen es auch 
nicht), aber es kann zur Optimierung timingkritischer Anwendungen 
manchmal hilfreich sein".

Seitdem bin ich nie in die Situation gekommen Assembler nutzen zu 
müssen. Ich habe aber immer die Fähigkeiten von ASM-Programmierern 
bewundert.

Letztlich scheint mir der Ansatz zusätzliche Abstraktionsebenen auf ASM 
aufszusetzen (wie der TO es tut) darauf zu basieren, dass ASM teils 
einfach zu wenig Abstraktion mitbringt (kann das sein?).

Nur dann stellt sich mir die Frage: Ist es dann nicht sinnvoll gleich 
auf eine Hochsprache zu wechseln? Bringt die dann zuviel Abstraktion 
mit?

Meinem Verständnis nach ist der Trend ganz klar Richtung mehr 
Abstraktion. Dies wird durch höhere Rechenleistung begünstigt. Die "Time 
to Market" wird dadurch deutlich reduziert. Und Zeit ist Geld, während 
Rechenleistung praktisch nichts mehr kostet.

[Mampf F. (mampf)]

Unwissender schrieb:
> Nur dann stellt sich mir die Frage: Ist es dann nicht sinnvoll gleich
> auf eine Hochsprache zu wechseln? Bringt die dann zuviel Abstraktion
> mit?

Hmm ... Das ganze sAVR-Dingens lässt sich doch wieder darauf 
zurückführen, dass der Urheber die Fähigkeiten des Makro-Assemblers 
nicht kannte und aus Bequemlichkeit(?) sich nie mit C-Compilern für 
AVR-Controller beschäftigt hat.

Stattdessen wird halt das Rad neu erfunden ...

Wieviele SD-Karten-Libraries gibt es, weil jemand die Doku nicht lesen 
konnte und/oder glaubte, es besser machen zu können ... Gleiches 
Phänomen :)

[S. R. (svenska)]

Unwissender schrieb:
> Seitdem bin ich nie in die Situation gekommen Assembler nutzen zu
> müssen.

Ich darf Assembler (mit Rechnerarchitektur) unterrichten, gebe aber 
direkt ein paar Hausnummern mit:
- "Assembler programmieren können" ist ziemlich sinnfrei ist (*)
- "Assembler verstehen" bedeutet "Prozessoren verstehen" (**)
- "Assembler lesen können" ist verdammt nützlich, wenn
  man nicht gerade ein paar Kilometer von der Hardware weg ist.

(*) Mit Ausnahmen. Wurde hier schon hoch und runter diskutiert.

(**) Mir geht es da um ein Grundverständnis für teure und billige 
Operationen, Rundungsfehler, Overflows, etc. Das ist sowieso alles 
unabhängig von der Architektur.

[Marc V. (Firma: Vescomp) (logarithmus)]

Wolfgang S. schrieb im Beitrag #4968939:
> So könnte man meinen, wenn man die Eigenschaften retardierter
> Implementationen mit dem zugrundeliegenden Konzept verwechselt.

 Wie auch immer, folgendes steht fest:

  1) Sein (was auch immer Tool) kann NICHT beliebig tief und
     beliebig oft verschachtelt werden.
  2) Sein (was auch immer Tool) benutzt äusserst kostbare (beim AVR)
     Register R16-R31.
  3) Ich als Programmierer muss mich bei seinem (was auch immer Tool)
     selbst um Registerzuweisung kümmern.

 Fazit:
  NUTZLOS und ausserdem schlecht geschrieben.

[Martin Netz (Gast)]

Marc V. schrieb:
> (was auch immer)

Du bist mir bis jetzt nur dadurch aufgefallen, das (was auch immer) von 
Anderen Leuten stammen muss per se schlecht und nutzlos ist.
Insofern ist Dein Urteil nutzlos.

Assembler ist (prinzipbedingt) übersichtlicher als z.B. "C". Die Idee, 
Befehle zur Programmsteuerung aus einer Hochsprache zu entleihen, finde 
ich wiederum genial. Darüber hinaus halte ich es nicht für möglich, daß 
er TO seine Zeit und seine Mühe in eine Sache steckt, die nicht sinnvoll 
ist.
Das sieht am u.A. auch an den auf seiner Webseite vorgestelllten Sachen.

Martin

[Marc V. (Firma: Vescomp) (logarithmus)]

Martin Netz schrieb:
> Du bist mir bis jetzt nur dadurch aufgefallen, das (was auch immer) von
> Anderen Leuten stammen muss per se schlecht und nutzlos ist.

 Nein, aber das verstehst du ja nicht, dazu musstest du erst mal
 wissen, wovon hier überhaupt die Rede ist.
 Ausserdem stimmt das schon mal nicht, es gibt hier ein paar Leute,
 die wissen meistens wovon sie reden, haben auch verschiedene Projekte
 geschickt, bzw. zur Verfügung gestellt, da habe ich kein einziges
 Wort (ausser Bravo, alle Achtung oder so) gesagt.


> Assembler ist (prinzipbedingt) übersichtlicher als z.B. "C". Die Idee,
> Befehle zur Programmsteuerung aus einer Hochsprache zu entleihen, finde
> ich wiederum genial.

 Natürlich, meine Tochter findet die Sachen die ich für sie gemacht
 habe auch genial. Hängt wahrscheinlich damit zusammen, dass Ihr beide
 in etwa dasselbe davon versteht...

 Kritik ist nicht gleichzusetzen mit schlechtmachen. Und ein Urteil
 darüber kann ich schon deswegen schreiben, weil ich etwas viel besseres
 als sein Programm geschrieben (und inzwischen aufgegeben) habe.

 Dass du aber nicht mal imstande bist, die Argumente aus:
 Beitrag "Re: Strukturierte AVR-Assembler-Programmierung"
 zu verstehen, zeigt schon auf welchem Niveau deine Kenntnise sind.

 Im übrigen ist das hier ein Forum und folgender Aussage:
Falk B. schrieb:
> Wir sind hier nicht im Kindergarten, wo es ach für die häßlichste
> Sandburg ein "hast du aber fein gemacht" gibt. Wenn der OP keine offene,
> sachliche Kritik hören will, darf er nicht danach fragen.
 kann ich mich nur 100%-ig anschliessen.

 P.S.

> Insofern ist Dein Urteil nutzlos.

 Es gibt schon einen Grund warum Denunzianten immer anonym sind und
 bleiben. Gilt für Gäste genauso - es wird schon einen Grund geben,
 warum man anonym bleiben will.

 Insofern ist dein Urteil über mich nutz- und wertlos...

[Wolfgang S. (ws01)]

Marc V. schrieb:
> Wolfgang S. schrieb im Beitrag #4968939:

[Ein Beitrag, der inzwischen als Antwort auf einen gelöschten Beitrag 
ebenfalls gelöscht wurde, nicht aber diese Antwort auf meinen als 
Kollateralschaden gelöschten Beitrag - befremdlich, daß solche 
Löschungen offenbar nicht transitiv durchgeführt werden ...]

>> So könnte man meinen, wenn man die Eigenschaften retardierter
>> Implementationen mit dem zugrundeliegenden Konzept verwechselt.
>
>  Wie auch immer, folgendes steht fest:
>
>   1) Sein (was auch immer Tool) kann NICHT beliebig tief und
>      beliebig oft verschachtelt werden.
>   2) Sein (was auch immer Tool) benutzt äusserst kostbare (beim AVR)
>      Register R16-R31.
>   3) Ich als Programmierer muss mich bei seinem (was auch immer Tool)
>      selbst um Registerzuweisung kümmern.
>
>  Fazit:
>   NUTZLOS und ausserdem schlecht geschrieben.

Whatever. Weil meine obige, aus dem Kontext gerissene und nicht 
gelöschte Bemerkung ohne Kontext keinen Sinn ergibt, hier der 
vollständige Beitrag:

[Zur Aussage "Makros sind überbewertet", die IMO durchaus 
diskussionswürdig ist]

So könnte man meinen, wenn man die Eigenschaften retardierter 
Implementationen mit dem zugrundeliegenden Konzept verwechselt.

Leider ist das Wissen bzgl. früher praktischer Anfänge dessen, was man 
heute wohl compile time metaprogramming nennt, weitgehend verloren 
gegangen. In der praktischen Informatik wird leider das Rad alle zwanzig 
bis dreissig Jahre neu erfunden. :-/  Das wäre soweit nicht schlimm, 
vieles ist aus gutem Grund vergessen. Allerdings führt dies auch dazu, 
daß dieselben Irrtümer immer wieder auftauchen, und das ist zumindest 
ziemlich nervig, wenn es um Dinge geht, die man aus eigener Anschauung 
besser weiss.

Der dünne Hinweis "The IBM/360 and derivatives had powerful macro 
assembler facilities that were often used to generate complete assembly 
language programs[citation needed] or sections of programs (for 
different operating systems for instance). Macros provided with CICS 
transaction processing system had assembler macros that generated COBOL 
statements as a pre-processing step."  in

https://en.wikipedia.org/wiki/Metaprogramming#Macro_assemblers

nennt leider keine Details. Deswegen noch mal der Hinweis, daß IBM schon 
vor einem halben Jahrhundert mehrere unterschiedliche Macroassembler im 
Angebot hatte, von denen sich der ASM/H hauptsächlich dadurch 
unterschied, daß damit umfängliche Metaprogrammierung at assembly time 
möglich war.

Das Konzept ist heutzutage weitgehend tot, ich meine aber weiterhin, daß 
dergl. dort, wo sich heute die Leute am unteren Ende des embedded 
programming über die Vorzüge und Nachteile von 
Maschinensprachenprogrammierung vs. Verwendung von C zanken, eine 
Alternative sein könnte - wenn es denn in diesem Bereich (!) 
entsprechend fähige Makrophasen in den verfügbaren Assembler gäbe.

[Rainer V. (Gast)]

Hi, ich wiederhole mich ungern, aber...Forth...was sonst?! Das ganze 
Rumgerödel um irgendwelche Assemblergeschichten ist doch wirklich nicht 
zielführend. Auch ich habe vor gefühlten 100 Jahren die gängigen und 
geheimen "Assemblertricks" hinter vorgehaltener Hand kennengelernt und 
es war (fast immer) schlicht Mist!
Wenn du hard- und assemblernah programmieren willst, dann machst du das 
in Forth! Natürlich mußt du dabei auch den Praeprozessor im Gehirn 
anwerfen...

Gruß Rainer

[Possetitjel (Gast)]

Rainer V. schrieb:

> ...Forth...was sonst?!

... ist zwar interessant, passt aber m.E. nicht gut in
diesen Diskussionsfaden, weil es in fast jeglicher
Hinsicht anders funktioniert als andere Programmiersprachen.

[Rainer V. (Gast)]

Possetitjel schrieb:
> ... ist zwar interessant, passt aber m.E. nicht gut in
> diesen Diskussionsfaden, weil es in fast jeglicher
> Hinsicht anders funktioniert als andere Programmiersprachen.

Ja, du hast Recht. Der TO will aber Anfängern mit ein paar dubiosen 
Macros den Einstieg in die Assemblerprogrammierung erleichtern und da 
wollte ich Interessierten einfach eine Alternative nennen.
Gruß Rainer

[Roland F. (rhf)]

Hallo Martin,

> Assembler ist (prinzipbedingt) übersichtlicher als z.B. "C".

Das hätte ich gerne mal näher erklärt.

rhf

[Martin Netz (Gast)]

Roland F. schrieb:
>> Assembler ist (prinzipbedingt) übersichtlicher als z.B. "C".
>
> Das hätte ich gerne mal näher erklärt.

Ich weiß nicht, was ich da erklären soll. Schon die bloße Ansicht eines 
(z.B. AVR)-Assembler Quelltextes macht das klar.

[Possetitjel (Gast)]

Martin Netz schrieb:

> Roland F. schrieb:
>>> Assembler ist (prinzipbedingt) übersichtlicher als
>>> z.B. "C".
>>
>> Das hätte ich gerne mal näher erklärt.
>
> Ich weiß nicht, was ich da erklären soll. Schon die bloße
> Ansicht eines (z.B. AVR)-Assembler Quelltextes macht das
> klar.

Naja, mit Ausnahme von echtem Maschinencode (okay... und
brainfuck) ist nahezu jede Programmiersprache lesbarer als
das Kryptosystem C; insofern hat Deine Aussage nicht allzuviel
Beweiskraft.

SCNR

[Wilhelm M. (wimalopaan)]

Leute das ist ja Klasse hier, besser als jede sonstige Realsatire ... 
erinnert mit irgendwie an eine Mischung aus Gerhard Polt und Luis de 
Funes.

Ich beobachte das jetzt hier, damit ich nix verpasse!

Bitte, macht weiter!!!

[Eberhard H. (sepic)]

Marc V. schrieb:
> Wie auch immer, folgendes steht fest:
>
>   1) Sein (was auch immer Tool) kann NICHT beliebig tief und
>      beliebig oft verschachtelt werden.

Doch (und zwar per Design, s.u.), siehe auch Handbuch Seite 3: "s'AVR 
-Strukturen können beliebig tief geschachtelt werden. Das Maximum wird 
nur durch den Programmspeicher des verwendeten AVR-Mikrocontrollers 
bestimmt." Was sonst?

Es gibt andere Versuche (dann meist Macro-basierend), um strukturiert in 
Assembler zu programmieren, die nur wenige verschachtelte Strukturebenen 
zulassen, was natürlich eine starke Einschränkung darstellt.

Und nein, mein (was auch immer Tool) ist bewusst NICHT Macro-basierend!

>   2) Sein (was auch immer Tool) benutzt äusserst kostbare (beim AVR)
>      Register R16-R31.

Nein, wie immer wieder betont (siehe auch 3)): Ausschließlich der 
Programmierer ist für die Verwendung aller AVR-Register (also R0-R31, 
nicht nur R16-R31) verantwortlich.

>   3) Ich als Programmierer muss mich bei seinem (was auch immer Tool)
>      selbst um Registerzuweisung kümmern.

Stimmt, siehe 2). Das ist der tiefere Sinn meines (was auch immer 
Tools), denn es soll bis auf die Anweisungen zur strukturierten 
Programmierung alles reine Assembler-Sprache bleiben. Basta.
Denn sonst kann man in der Tat mit C (oder was auch immer Tools) 
programmieren.

Mein (was auch immer Tool) übernimmt u.a. die Verwaltung der 
Sprungadressen und der (vom Programmierer festgelegten) Verwendung der 
FOR-Schleifen-Register.

Und natürlich kann der AVR-Assembler-Programmierer beliebig pushen und 
poppen, denn der Stack wird von meinem (was auch immer Tool) NICHT 
angetastet.

Und nochmals und immer wieder: Dieses Konzept habe nicht ich erfunden, 
sondern viele andere Leute und Firmen haben es lange vor mir in ihren 
Mikrocontroller-Assemblern implementiert (u.a. Motorola ab ca. 1980, 
eine Zusammenstellung folgt bei Gelegenheit - wie versprochen).

>  Fazit:
>   NUTZLOS und ausserdem schlecht geschrieben.

Ich frage mich, wie du mein (was auch immer Tool) beurteilen kannst, 
ohne es je gestestet oder gar dessen (Pascal)-Quell-Code gesehen zu 
haben, der übrigens auf Compiler-Literatur von Niklaus Wirth, dem 
Erfinder so machner Programmiersprachen (insbesondere Pascal, Modula und 
Oberon) basiert.

[Dieter F. (Gast)]

Eberhard H. schrieb:
> Mein (was auch immer Tool) übernimmt u.a. die Verwaltung der
> Sprungadressen und der (vom Programmierer festgelegten) Verwendung der
> FOR-Schleifen-Register.

Wenn der Programmierer diese "unsachgenäss" verwendet - gibt es dann 
eine Warnung / einen Hinweis?

[Wilhelm M. (wimalopaan)]

Lieber Eberhardt,

merkst Du nicht, dass das zwecklos ist?

Mach einfach ein schönes F/OSS-Projekt draus, poste das auch 
comp.lang.xxxx und warte ab. Wenn es gut ist, werde sich die Leute damit 
befassen. Wenn nicht, erhälst Du kaum Rückmeldung ... evtl. eine 
höfliche Rückfrage, warum so oder so. Aber Du wirst dort nicht 
beschimpft ...

[2⁵ (Gast)]

Eberhard H. schrieb:
> Ich frage mich, wie du mein (was auch immer Tool) beurteilen kannst,
> ohne es je gestestet oder gar dessen (Pascal)-Quell-Code gesehen zu
> haben, der übrigens auf Compiler-Literatur von Niklaus Wirth, dem
> Erfinder so machner Programmiersprachen (insbesondere Pascal, Modula und
> Oberon) basiert.

Mach doch Nägel mit Köpfen: Ein Oberon Compiler für AVR, das wäre was. 
Wenn der dann halbwegs vernünftigen Code produziert und relativ Bug-Frei 
ist, dann kann man dafür auch Geld verlangen.

So "strukturiere Assembler Meta Sprachen" hat man auch schon damals beim 
Amiga (68000 CPU) probiert. Hat sich nie eine Nische erarbeiten können.
Du bist mit deiner Idee mindesten 20 Jahre zu spät dran.

So, um nochmal etwas Öl ins Feuer zu gießen: Der beste und universellste 
Makro Assembler ist halt C. Man muss es nur halbwegs beherrschen.

[chris (Gast)]

Nun was soll man sagen

Wenn man Anfängern den Einstieg in die Programmierung erleichtern will, 
sollte als erstes das Verständniss für die Hardware gelegt sein. 
Unabhängig von der Programmiersprache.

Das was ASM wirklich fehlt sind die Peripheriebibliotheken die es auch 
in den Hochsprachen gibt. Wenn diese Funktionsblöcke geschafft und auch 
verstanden worden wären, ergibt sich die Struktur fast von selbst zu 
einem Gewissen Maße.

Dies hängt aber Grundsätzlich vom Programmierer ab, ob er es zulässt 
oder nicht. Als ich angefangen habe, wollte ich auch es ursprünglich 
lassen und z.B Zahlen so zu setzen: $45
aber das hat einen gewaltigen Nachteil wenn man mal fix was ändern will.

Das mal zu Peripheriebibliotheken... Zum Programm selber muss sich der 
Programmierer halt auf die Übersicht einlassen. Selbst in Hochsprachen 
ist diese auch für den Popo. Eingefleischte verstehens auch erst 
meistens beim 2ten mal drüber gucken über fremden Quelltext...

[Eberhard H. (sepic)]

Dieter F. schrieb:
> Eberhard H. schrieb:
>> Mein (was auch immer Tool) übernimmt u.a. die Verwaltung der
>> Sprungadressen und der (vom Programmierer festgelegten) Verwendung der
>> FOR-Schleifen-Register.
>
> Wenn der Programmierer diese "unsachgenäss" verwendet - gibt es dann
> eine Warnung / einen Hinweis?

Natürlich (sofern vor dem Assembler-Lauf erkennbar), sogar mit Klartext 
und Nennung der Zeilennummern des strukturierten Quellprogramms, sowohl 
Fehlermeldungen als auch Warnhinweise und sogar zwischendurch ein paar 
Programmiertipps. Ansonsten reklamiert es spätestens der Assembler.

Mit Macros wäre das schier unmöglich.

[Marc V. (Firma: Vescomp) (logarithmus)]

Eberhard H. schrieb:
>>   1) Sein (was auch immer Tool) kann NICHT beliebig tief und
>>      beliebig oft verschachtelt werden.
>
> Doch (und zwar per Design, s.u.), siehe auch Handbuch Seite 3: "s'AVR
> -Strukturen können beliebig tief geschachtelt werden. Das Maximum wird
> nur durch den Programmspeicher des verwendeten AVR-Mikrocontrollers
> bestimmt." Was sonst?

 Ich habe es wirklich mit Argumenten versucht...
 Entweder bist du ein Lügner oder du hast absolut keine Ahnung wovon
 du redest.

 Deine Aussage:
Eberhard H. schrieb:
> Hier zunächst nochmals dein strukturiertes Assembler-Programm (die
> diversen FOR-Schleifenregister müssen natürlich vorher definiert worden
> sein):

 AVR hat nur 16 Register die bei dir als Schleifenregister definiert
 werden können (und auch müssen und zwar von Programmierer selbst).
 Das ist Lichtjahre von beliebig entfernt.
 Und selbst diese Register muss ich selbst definieren und darf die von
 da an innerhalb der Schleife nicht mehr benutzen - weil dein (was auch
 immer Tool) dazu nicht imstande ist, oder was ?

 Angenommen, ich brauche nur 8 verschachtelte Schleifen aber alle
 Register von R17-R31.
 Wie hilft mir dein (was auch immer Tool) weiter ?

 Und hör bitte auf, irgendwelche (wie auch immer) Parallelen zwischen
 WIRTH und dir, sowie PASCAL und deinem (was auch immer Tool) zu ziehen.

[Winfried M. (win)]

Marc V. schrieb:
> Ich habe es wirklich mit Argumenten versucht...
>  Entweder bist du ein Lügner oder du hast absolut keine Ahnung wovon
>  du redest.

Jemanden als Lügner zu bezeichen, ist ein persönlicher Angriff, den wir 
hier nicht brauchen.

Worum es ihm ging: Sein Programm kann beliebig tief schachteln. Von hier 
gibts keine Begrenzung. Die Begrenzung legt die Umgebung fest, in dem es 
verwendet wird.

Sollte es also mal einen AVR geben, der 1000 Register hat, dann könnte 
man 1000 Verschachtelungen machen. Das Programm müsste dafür nicht 
umgeschrieben werden.

[Lost InMusic (Gast)]

>AVR hat nur 16 Register die bei dir als Schleifenregister definiert
>werden können (und auch müssen und zwar von Programmierer selbst).
>Das ist Lichtjahre von beliebig entfernt.

Also wenn man mit push und pop arbeitet - was einem dieses hier zur 
Diskussion stehende Tool ja nicht verbietet - kommt man minimum auch mit 
nur einem Register aus und kann damit sogar eine Schachtelungstiefe 
von z. B. 85 realisieren. Man muss nur dafür bezahlen: Mit Stack, 
Programmspeicher und einer schlechteren Lesbarkeit des Quelltextes, in 
dem vor jedem FOR/IF/WHILE/REPEAT eine push- und nach jedem 
ENDF/ENDIF/ENDW/UNTIL eine pop-Instruktion steht. Je nach Anwendungsfall 
ist es vielleicht ja sogar ein gutes Geschäft.

Interessant wäre mal zu erfahren, was genau dieser Precompiler 
eigentlich macht. Das Handbuch schweigt sich darüber leider aus.

[Lost InMusic (Gast)]

Äh, ja... wie ich gerade gesehen habe, hast Du es ja selbst weiter oben 
vorgemacht :-)

[Karl (Gast)]

Gibt es irgendwelche Benchmarks?

Wieviel schneller ist dein Code als der von gcc mit -O2?

Ich würde ja fast behaupten, dass der GCC schnelleren und effizienteren 
Code als deine ASM Geschichte produziert.

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

Winfried M. schrieb:
> Jemanden als Lügner zu bezeichen, ist ein persönlicher Angriff, den wir
> hier nicht brauchen.

Da gebe ich dir völlig Recht, und möchte die Kontrahenten zur Mäßigung
aufrufen.

(push/pop)

Lost InMusic schrieb:
> Je nach Anwendungsfall ist es vielleicht ja sogar ein gutes Geschäft.

Das ist nun genau der Punkt, an dem einem ein richtiger Compiler die
Arbeit abnimmt: er analysiert die „Kosten“, weiß, welche Register
gerade in Verwendung und welche frei sind, daher kann er selbst
entscheiden, ob er nun dergestalt Variablen auf den Stack auslagern
muss oder nicht.  Dafür muss ich im Programmquelltext auch keine
besonderen Vorkehrungen treffen, er kann das per Analyse von sich aus
erledigen.  Was Leute wie Eberhard halt als Nachteil dabeim empfinden:
ich kann vom Programmquelltext her nicht mehr direkt sagen, welche
Register denn nun alle benutzt werden.  Es geht dann eben nur noch
automatisch.

Dafür beherrschen Compiler es, dass sie Zeilennummerninformationen
zum Debugger weiterreichen können.  Prinzipiell könnte das gewiss auch
so ein Präprozessor wie hier tun, aber der benutzte Assembler muss
diese Informationen verarbeiten können.  Der Atmel-Assembler kann sowas
meines Wissens nicht.

Karl schrieb:
> Ich würde ja fast behaupten, dass der GCC schnelleren und effizienteren
> Code als deine ASM Geschichte produziert.

Derlei Vergleiche hatten wir ja schon.  Je größer das Programm, um so
besser die Chance, dass ein Hochsprachcompiler (man muss ja dabei nicht
an der Sprache C kleben bleiben, wenn einem diese so unangenehm ist)
kürzeren und schnelleren Code produziert als ein handgefeiltes
Assemblerprogramm.  Wenn man noch dazu sieht, dass das Ganze hier dann
offensichtlich ein kommerzielles Produkt werden soll, fragt man sich
schon nach dem „bang per buck ratio“ des Ganzen.

[Marc V. (Firma: Vescomp) (logarithmus)]

Jörg W. schrieb:
> Da gebe ich dir völlig Recht, und möchte die Kontrahenten zur Mäßigung
> aufrufen.
 Wurde zur Kenntnis genommen, werde mich zurückhalten...

Jörg W. schrieb:
> Karl schrieb:
>> Ich würde ja fast behaupten, dass der GCC schnelleren und effizienteren
>> Code als deine ASM Geschichte produziert.
>
> Derlei Vergleiche hatten wir ja schon.  Je größer das Programm, um so
> besser die Chance, dass ein Hochsprachcompiler (man muss ja dabei nicht
> an der Sprache C kleben bleiben, wenn einem diese so unangenehm ist)
> kürzeren und schnelleren Code produziert als ein handgefeiltes
> Assemblerprogramm.

 Ja.
 Deswegen macht man zeitkritische Sachen in Assembler, den Rest aber
 in purem C (oder welcher Sprache auch immer).
 Inzwischen machen wir das auch bei unseren Steuerungen mit ATMELs als
 Slave (das meiste in ASM) und ARM als Master und Gehirn (alles in C)
 und es funktioniert mehr als nur zufriedenstellend.


> erledigen.  Was Leute wie Eberhard halt als Nachteil dabeim empfinden:
> ich kann vom Programmquelltext her nicht mehr direkt sagen, welche
> Register denn nun alle benutzt werden.  Es geht dann eben nur noch
> automatisch.

 Ohne mich wiederholen zu wollen, aber ein Programm zur nachträglichen
 Analyse ist gerade bei Assembler viel nützlicher als quasi Schleifen
 und Loops mit selbst ausgesuchten Registern.
 Wer jemals etwas länger als 2-4KB in Assembler geschrieben hat, weiss
 wovon ich rede.
 Einerseits soll es so schnell wie nur möglich sein, d. h. so viel wie
 nur irgend möglich mit Registern arbeiten, andererseits darf man die
 irgendwo anders im Programm benutzten Register in einer aufzurufenden
 Routine nicht beschmutzen.
 Wenn diese Routine aber eine andere aufruft und diese wiederum von
 einem Interrupt unterbrochen werden kann - da verliert man ganz
 schnell die Übersicht und da braucht man etwas zur Analyse.

 Der Postprocessor (Analyser ?), den ich behalten habe, kann (unter
 anderem) sowohl eine Liste mit allen Routinen und benutzten Registern
 ausgeben als auch direkt im Assemblercode einen Header über jede
 Routine mit benutzten Registern und Adressen die diese Routine
 aufrufen erzeugen.

 So etwas finde ich natürlich ungemein nützlich aber Schleifen mit
 selbst ausgesuchten und von da an lahmgelegten Registern mit
 Sicherheit nicht...

[Harald (Gast)]

Marc V. schrieb:
> Ja.
>  Deswegen macht man zeitkritische Sachen in Assembler, den Rest aber
>  in purem C (oder welcher Sprache auch immer).
>  Inzwischen machen wir das auch bei unseren Steuerungen mit ATMELs als
>  Slave (das meiste in ASM) und ARM als Master und Gehirn (alles in C)
>  und es funktioniert mehr als nur zufriedenstellend.

Quatsch. ASM nutzt man insbesondere dann embedded in C/C++/usw, wenn es 
nötig ist, dass exakt diese Befehle ausgeführt werden, z.B. bei einen 
Context Switch.

Genauso hinkt dein Argument hinsichtlich der Validierbarkeit, man kann 
von gcc auch das Assembly ausspucken lassen und genauso gut kann man den 
C Code validieren. Sprich du machst dir nur unnötig Arbeit ohne die 
mächtigen Optimierfunktionen eines aktuellen Compilers zu nutzen. Ich 
persönlich würde mir nicht anmaßen, besseren Code in ASM zu schreiben 
als ein aktueller Compiler optimieren kann. Schon gar nicht einen 
ähnlichen Compiler selbst zu schreiben.

[Marc V. (Firma: Vescomp) (logarithmus)]

Harald schrieb:
> Quatsch. ASM nutzt man insbesondere dann embedded in C/C++/usw, wenn es
> nötig ist, dass exakt diese Befehle ausgeführt werden, z.B. bei einen
> Context Switch.

 Erst Quatsch und dann mich zitieren ?


> Genauso hinkt dein Argument hinsichtlich der Validierbarkeit, man kann
> von gcc auch das Assembly ausspucken lassen und genauso gut kann man den
> C Code validieren. Sprich du machst dir nur unnötig Arbeit ohne die

 Mit wem und worüber diskutierst du überhaupt ?
 Hier geht es um Assembler und nicht um C...


> mächtigen Optimierfunktionen eines aktuellen Compilers zu nutzen. Ich
> persönlich würde mir nicht anmaßen, besseren Code in ASM zu schreiben
> als ein aktueller Compiler optimieren kann.

 Ich schon, aber natürlich nur für bestimmte Aufgaben und Steuerungen,
 bestimmt nicht für Rechnen mit Gleitkomma.


> Schon gar nicht einen ähnlichen Compiler selbst zu schreiben.

 Und nochmal: mit wem und worüber diskutierst du überhaupt ?

[chris (Gast)]

Marc V. schrieb:
> Wenn diese Routine aber eine andere aufruft und diese wiederum von
>  einem Interrupt unterbrochen werden kann - da verliert man ganz
>  schnell die Übersicht und da braucht man etwas zur Analyse.

nutzt man denn kein Simulator um nolragische Punkte zu eleminieren ? 
Gerade das ist es doch was den Leuten in Hochsprachen fehlt zu erkennen 
wann wo welche Unterfunktionen von anderen beeinflusst werden. Denn wenn 
sie es erkennen wollten, würde man sich seine/die Bibliothek anschauen 
was alles genutzt wird. Damit man das nicht tun muss erkauft man sich 
die Bequemlichkeit mit Automatismen.

Die Aussage das man in Zeitschleifen die Register nicht mehr nutzen kann 
ist auch nicht wirklich nachvollziehbar. Es gibt immer noch die Pointer 
die nutzbar sind welche für Zeitschleifen bis max 1s top sind auch mit 
IRQ's ohne Beeinflussung. Muss es sehr genau sein gibs immer noch die 
TimerEinheiten und auch darüber gibs Abhandlungen wie man die einsetzt 
um Verzögerungen hervorzu bringen.

[Winfried M. (win)]

Ich hätte jetzt gerne noch eine objektorientierte Assembler-Erweiterung. 
;)

[Marc V. (Firma: Vescomp) (logarithmus)]

chris schrieb:
> nutzt man denn kein Simulator um nolragische Punkte zu eleminieren ?

 Nicht unbedingt, nicht für alles und sicher nicht für das gesammte
 Programm.
 Mit meinem Analyser ist das Ganze in weniger als 1s erledigt.
 Mit Simulator geht das nicht immer, ausserdem muss es schon ein
 guter sein, mit Breakpoints on Register Change - und dann auch nur an
 ausgewählten Registern etc.

 Aber vielleicht ist es nur Faulheit bei mir - ich habe im linken
 Fenster Treeview mit Routinen, im rechten werden die benutzten Register
 angezeigt. Ein Rechtsklick auf die Routine zeigt sowohl die von der
 Routine selbst benutzten Register als auch die Register die von den
 aufgerufenen Routinen benutzt werden. Und ich kann Befehle, welche die
 Registerinhalte nicht verändern, ausfiltern (CP, TST, SBRx, usw.).
 Und wenn das Programm beim prüfen keine Konflikte meldet, brauche ich
 den Simulator auch nicht anzuwerfen (zumindest nicht für die Prüfung
 auf ungewollte Registerveränderung).


> Gerade das ist es doch was den Leuten in Hochsprachen fehlt zu erkennen
> wann wo welche Unterfunktionen von anderen beeinflusst werden.

 Das kann sich nur auf Variablen beziehen und selbst dann müssen diese
 global sein. Um Register selbst braucht man sich bei Hochsprachen
 bestimmt nicht zu kümmern.


chris schrieb:
> Die Aussage das man in Zeitschleifen die Register nicht mehr nutzen kann
> ist auch nicht wirklich nachvollziehbar.

 Selbstverständlich ist das nachvollziehbar - ein Register welches als
 Schleifenzähler deklariert worden ist, kann innerhalb dieser Schleife
 nicht mehr benutzt werden - zumindest nicht bei dem Programm von TO.

[chris (Gast)]

Marc V. schrieb:
> Mit meinem Analyser ist das Ganze in weniger als 1s erledigt.
>  Mit Simulator geht das nicht immer, ausserdem muss es schon ein
>  guter sein, mit Breakpoints on Register Change - und dann auch nur an
>  ausgewählten Registern etc.

> Und wenn das Programm beim prüfen keine Konflikte meldet, brauche ich
>  den Simulator auch nicht anzuwerfen (zumindest nicht für die Prüfung
>  auf ungewollte Registerveränderung).

Mit der doppelbelegung der Regist ok aber ob das Programm das tut was es 
soll weist du beim Analyser trotzdem nicht.

Marc V. schrieb:
>  Das kann sich nur auf Variablen beziehen und selbst dann müssen diese
>  global sein.

Warum soll sich das nur auf Variablen beziehen ??? Und das ist ja das 
schöne das ich vom Prinzip her nur mit globalen Registern/Variablen/ 
SRAM arbeiten kann in jedem Unterprgroamm.

>  Um Register selbst braucht man sich bei Hochsprachen
>  bestimmt nicht zu kümmern.

Und da find ich wirds schon tricki. Bei gewissen Fehlern in Bibliotheken 
fällt das in Hochsprachen gar nicht weiter auf.In ASM schon, wenn was 
nicht 100%ig passig ist. Was dann in Hochsprachen zu einbusen führt auch 
wenn das Programm anstandslos funktioniert.

Kann dem Maximilian nur beipflichten die Einfachheit macht es so strickt 
elegant in ASM.

Was in ASM fehlt sind bei vielen Familien die Hardwarebibliotheken. Vom 
Prinzip her aber lernt man dadurch das sie fehlen wo man Fehler macht.