[PICASM]? Wir das kommen?

Andreas wird so etwas einbauen, wenn er feststellt, daß daran ein 
nennenswertes Interesse besteht, was unter anderem an der Anzahl der 
PICs in Assembler programmierenden Forenmitglieder hängen dürfte.

Ich fürchte aber, daß das ein Exotenwunsch ist, ist doch die Anzahl der 
in Assembler programmierenden Forenmitglieder insgesamt recht 
überschaubar, selbst wenn man alle Prozessorarchitekturen zusammenzählt.

Flo schrieb:
> Ist es geplant, dass ein Syntax Highlighting für PIC asm irgendwann im
> Forum kommt? Hat jemand einmal darüber Nachgedacht?

Welcher PIC? PIC18? PIC24/dsPIC? PIC32 aka MIPS?

Du siehst das Problem?

fchk

Naja, auch wenn das Syntaxhighlighting "avrasm" heißt, am Ende ist es
ein ziemlich generisches Syntaxhighlighting für beliebigen 
Assemblercode.
Wir brauchen da nicht extra picasm, armasm, beinasm und wie sie alle
heißen. ;-)

Hier ein Ausschnitt aus einem meiner AVRASM Codes.

1

start:

2

  ;Stackpointer initialisieren

3

  ldi temp, low(RAMEND)

4

  out SPL, temp

5

6

  ldi temp, high(RAMEND)

7

  out SPH, temp

8

9

10

  ;Pins/Ports konfigurieren

11

  ldi temp, (1 << SCLR) | (1 << SCK) | (1 << RCK) | (1 << G) | (1 << SI)

12

  out DDRSPI, temp

13

14

15

  ;SPI initialisieren

16

  sbi PORTSPI, SCLR

17

  cbi PORTSPI, G

18

19

20

endlos:

21

22

  in temp, PORTA

23

  andi temp, (1 << taster)

24

  eor vorher, temp

25

  breq tasterabfrage_1

26

    inc counter

27

  tasterabfrage_1:

28

  mov vorher, temp

29

30

  ldi temp, 0x55

31

  push temp

32

  rcall fu_spi_byte_senden

33

  pop counter

34

35

  nop

36

  nop

37

38

  rjmp endlos

Gruß Kai

Flo schrieb:
> Nur ein Test mit [ avrasm ]
>
>

1

> init

2

> ...

3

>

Verkraftet dein Assembler keine Doppelpunkte nach den Labels?  Die
scheinen der Schlüssel für das Syntaxhighlighting zu sein.  Hier ein
Stück alten PIC-Codes von mir:

1

isr:

2

        movwf   save_w

3

        swapf   status, w

4

        movwf   save_st

5

        movf    fsr, w

6

        movwf   save_fsr

7

8

        bcf     intcon, t0if    ; clear pending int

9

        movf    tmconst, w

10

        movwf   tmr0            ; reload timer 0

11

12

        btfss   flags, fl_spkr

13

        goto    isr1

14

        movlw   (1 << spkr1) | (1 << spkr2); toggle speaker pins

15

        xorwf   portb, f

16

17

isr1:

18

        decfsz  tmr100ms

19

        goto    isrexit

20

        movlw   tm100const      ; tmr100ms rollover

21

        movwf   tmr100ms

22

        bsf     flags, fl_100ms

23

        ;; flash LED (turn off)

24

        movlw   (1 << ledrd) | (1 << ledgn)

25

        iorwf   portb, f

26

;

27

;

28

isrexit:

29

        movf    save_fsr, w

30

        movwf   fsr

31

        swapf   save_st, w

32

        movwf   status

33

        swapf   save_w, f

34

        swapf   save_w, w

35

        retfie

Flo schrieb:
>> Verkraftet dein Assembler keine Doppelpunkte nach den Labels?
> Keine Ahnung. Ich habe es ohne : gelernt und mache es deshalb immer so.

Scheint ein relativ altmodischer Assembler zu sein, der die einzelnen
Syntaxelemente nach ihrer Spaltenanordnung erkennt statt anhand der
Notation.  Sowas kenne ich eigentlich nur von Primitivassemblern vom
Z80 (vor-CP/M-Ära).  Den meisten aktuellen Assemblern sind die Spalten
reichlich egal, da geht dann auch sowas:

1

label:

2

ldi r24, 23

Probier doch mal, ob du den Doppelpunkt auch schreiben kannst, dann
müsste das ja alles für die PIC-Assembler genauso nutzbar sein.

Flo schrieb:
> Meinem MPASM ist es egal ob ich Labels mit :, ohne:, mit Spalten oder
> ohme Spalten mache.

Wie unterscheidet er dann einen Label von einer Instruction?

> Spalten nutze ich wegen der Übersichtlichkeit und
> habe es ohne : gelernt und mache es deshalb immer so.

Wenn es dem Assembler egal ist, wäre es für den Blick übern Tellerrand
sinnvoll, dass du dir den Doppelpunkt für die Labels angewöhnst, denn
so gut wie alle anderen Assembler brauchen ihn.

132 schrieb:
> Bevor sowas eingeführt wird (und ich hätte daran auch Interesse) bedarf
> es hier im Forum noch einiger bedeutend wichtigerer Programmieraufgaben
> ...

Nenn doch mal ein Beispiel?

Mark Brandis schrieb:
> 132 schrieb:
>> Bevor sowas eingeführt wird (und ich hätte daran auch Interesse) bedarf
>> es hier im Forum noch einiger bedeutend wichtigerer Programmieraufgaben
>> ...
>
> Nenn doch mal ein Beispiel?

(Nicht mehr funktionierende) Links bei Bauteilen ändern.