1

Temat: bugi w mads

Właśnie natknąłem się na błąd (tak mi się wydaje) w mads 1.8.5. Assemblacja:

cmp #

kończy się generowaniem:

C9 00

Poprosiłbym może o jakiś syntax error? Albo przynajmniej warning jeśli to jest usprawnienie.
Używam madsa kompilowanego fpc na ubuntu 9.04 (x86_64).

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

2

Odp: bugi w mads

ale to nie jest blad.

http://atari.pl/hsc/ad.php?i=1.

3

Odp: bugi w mads

moze nie blad, ale na jakas uwage imho to zasluguje.
skad wiadomo, ze ktos nie zapomnial tam liczby wstawic?

4

Odp: bugi w mads

Tak właśnie mi się zdarzyło.

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

5

Odp: bugi w mads

to jest zamierzone, domyślnie przyjmie wartość 0 (zero)

lda #   = lda #0
cmp #  = cmp #0

asl   = asl @

inc    = inc @ (dla 65816 - opt c+)

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

6

Odp: bugi w mads

Mads 1.9.8, kod:

  opt ?+ h+ o+

  blk reloc main
  nop
  rts

  blk reloc extended
dupa1 .ds 10
dupa2 .ds 10

  end

generuje strukturę:

001: @$0000 SDX $0000   #01: $0002           RELOC MAIN
002: @$000A SDX $0002   #02: $0000           RELOC EXTENDED
003: @$0012 SDX $0002   #03: $0014           EMPTY EXTENDED
     @$001A EOF

W binarce wygląda to tak:

0000000: fe ff 01 00 00 00 02 00 ea 60 fe ff 02 02 02 00  .........`......
0000010: 00 00 fe ff 03 82 02 00 14 00                    ..........

Czy jest sposób uniknięcia pustego bloku reloc extended? Blok empty extended nie bardzo się nadaje do użycia kiedy chciałbym mieć w ciągłym bloku kilka buforów.

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

7

Odp: bugi w mads

Natknąłem się na błędne działanie:

  blk reloc main
rutynal = *+1
  ldx #<rutyna
rutynah = *+1
  ldy #>rutyna
  rts

rutyna:
  nop
  rts

Wystąpiło coś takiego w plemniku no i mimo, że w statycznym (blk sparta) bloku te bajty były wyliczane i aktualizowane na poprawny adres rutyny, to coś się w kodzie psuło (w tym przypadku nie chciało działać z biblioteką ENV.SYS, ale nie wiem czemu).
Jeśli dobrze zrozumiałem drac030, to winne były fixupy dla rutyna.
Ponieważ dochodzenie co się stało (nie widać błędów w listingu programu -l, a kod pod emulcem często wygląda poprawnie), to może dałoby się spowodować, żeby konstrukcja #<. #> i #^ nigdy nie generowała fixupa? Albo przynajmniej niech rzuca błędem, że tak nie można...

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

8

Odp: bugi w mads

Ja wcale nie jestem pewien, czy to była ta przyczyna, bo pod disasemblerem wszystko wyglądało zdrowo. W każdym razie mads nie powinien akceptować składni w rodzaju <etykieta i >etykieta (włączając w to #<etykieta i #>etykieta), jeśli "etykieta" jest adresem zdefiniowanym wewnątrz blk reloc albo blk empty.

I przyłączam się do sugestii mono, że .ds następujące od razu po blk reloc nie powinno generować podwójnych nagłówków, tylko wytworzyć pusty blok o odpowiedniej wielkości (i z zadanym w blk reloc atrybutem).

Ostatnio edytowany przez drac030 (2013-12-29 22:28:37)

KMK
? HEX$(6670358)

9

Odp: bugi w mads

W programach relokowalnych dla SDX potrzeba czasem znać indeks bloku (w pliku), w którym znajduje się obiekt (procedura, dane).
Czy w związku z tym można by mieć możliwość np. nazywania bloków za pomocą etykiety:

kod1: blk reloc main
  ...
kod2: blk reloc extended
  ...

dzięki temu mógłbym sobie adresować tablicę EXTENDED+3 w taki sposób:

  lda EXTENDED+3+kod1
  jsr JEXT_ON
  ...
  jsr JEXT_OFF

  lda EXTENDED+3+kod2
  jsr JEXT_ON
  ...
  jsr JEXT_OFF

co gwarantowało by mi dostęp do odpowiedniego bloku pamięci.

Problematyczne jest też wykorzystanie blk empty, ponieważ rzadko zachodzi potrzeba rezerwacji pojedynczego bufora, jako osobnego bloku pamięci (tym bardziej, że loader ogranicza ilość bloków relokowalnych), a bardzo często pojedynczy blok empty dzielony jest na kilka różnych buforów lub zmiennych. Czy można by dodać taką konstrukcję:

  blk empty main/extended/$xx
dane1: .ds 20
dane2: .ds 30
adres: .ds 2

która generowałaby odpowiedni blok empty (pojedynczy). W połączeniu z nazywaniem bloków blk pozwalałoby to na ładny dostęp do pamięci w programach dla SDX.

Edit: Oczywiście nie upieram się przy etykiecie - może to być nazwa bloku deklarowana np:

blk empty main/extended/$xx nazwa
blk reloc main/extended/$xx nazwa

czy jak by tam było wygodnie.

Ostatnio edytowany przez mono (2013-12-30 16:36:29)

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

10

Odp: bugi w mads

użycie  w relokowalnym kodzie składni

ldx #<cos
ldy #>cos

zostanie zinterpretowane jako tryb absolutny # z wartością młodszy/starszy jednak ta wartość nie będzie relokowana

dopiero kod

ldx <cos
ldy >cos

zostanie zinterpretowany jako młodszy/starszy bajt adresy i będzie relokowany

proszę pamiętać że mads, xasm są dziećmi QA, nie rozumiem tej chęci pisania znaku dodatkowego, zapomnieliście QA

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

11

Odp: bugi w mads

tebe napisał/a:

zostanie zinterpretowane jako tryb absolutny #

WTF?

https://www.youtube.com/watch?v=jofNR_WkoCE

12

Odp: bugi w mads

a takie tam, natychmiastowy #

p.s.
Fox opisz jeszcze interlace Rybagsa, będzie kolejny artek, może w końcu wypuścisz je z szuflady

Ostatnio edytowany przez tebe (2014-01-02 11:15:48)

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

13

Odp: bugi w mads

tebe napisał/a:

a takie tam, natychmiastowy #

p.s.
Fox opisz jeszcze interlace Rybagsa, będzie kolejny artek z przykładowym kodem, może w końcu wypuścisz je z szuflady

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

14

Odp: bugi w mads

mads.atari8.info napisał/a:

Jeśli chcemy użyć trybów adresowania 65816, musimy o tym poinformować asembler przez 'OPT C+'.

Jakoś nie bardzo: mads mimo opt c+ nie akceptuje rozkazów w rodzaju ora ($01,s).

KMK
? HEX$(6670358)

15

Odp: bugi w mads

To całkiem zrozumiałem zważywszy, że najbliższy tryb adresowania do tego co chcesz osiągnąć to ora ($01,s),y :)

16

Odp: bugi w mads

Racja, zapomniałem :) NVM, zatem.

KMK
? HEX$(6670358)

17

Odp: bugi w mads

Nie nie... MVN służy do czegoś zupełnie innego :cool: ;)

18

Odp: bugi w mads

:p

KMK
? HEX$(6670358)

19

Odp: bugi w mads

ktoś Tu pije na stanowisku pracy ;)

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

20

Odp: bugi w mads

mads 1.9.9 build 7 (28 Jan 14)

nie wnikajac w szczegoly mads nielegalnie kompiluje np. NPO $ffff ( TOP - 3-bajtowy nop) jako BPL *

http://atari.pl/hsc/ad.php?i=1.

21

Odp: bugi w mads

Sam widzisz, że ten nielegalny rozkaz czasem zawiesza procesor. ;)

https://www.youtube.com/watch?v=jofNR_WkoCE

22

Odp: bugi w mads

wczesniejsza wersja mads dobrze kompilowala. teraz to nawet strach postawic podwojnego nopa bo wychodzi PHP ;-)

http://atari.pl/hsc/ad.php?i=1.

23

Odp: bugi w mads

Program:

        blk reloc main

start   nop
        rts

        blk reloc $42

ext     nop
        rts

        .ds $0200

Generuje coś takiego:

     1  FE FF 01 00                     blk reloc main
     2
     3 0000,0002> EA            start   nop
     4 0001 60                          rts
     5
     6 0002 FE FF 02 42                 blk reloc $42
     7
     8 0002,0002> EA            ext     nop
     9 0003 60                          rts
    10
    11 = 0004                           .ds $0200
    12
    12 0004 FE FF 03 C2 04 00 + BLK EMPTY

Nagłówek wygenerowany przez .ds ma ustawiony bit 'page align' ($C2 = %11000010), dziedziczy go po ostatniej dyrektywie blk reloc. Bug polega na tym, że nie ma (chyba?) sposobu na uniknięcie tego dziedziczenia, tzn. jeśli chcę, żeby blok binarny był wyrównany do granicy stron, a późniejszy .ds nie, nie mogę tego zrobić[1].

[1] oprócz stosowania średniowiecznej metody liczenia offsetów na palcach od dyrektywy blk empty, co w przypadku skomplikowanych programów, mających dziesiątki pól .ds, po prostu nie wchodzi w rachubę.

KMK
? HEX$(6670358)

24

Odp: bugi w mads

Dorzucam błąd

mads kompiluje bez błędów poniższy kod:

    org ekr
    dta b(0)
    ini ekr
ekr equ *

Wygenerowana binarka to:

00000000  ff ff e4 02 e4 02 00 e2  02 e3 02 e4 02           |.............|
0000000d

Wydaje mi sie ze w przypadku takiej referencji powinien byc zglaszany blad (org powinien byc znany w pierwszym przebiegu, ewentualnie w drugim jesli nie zalezy od labelki do ktorej sie odnosi) Tymczasem mads wesolo przyjmuje ze ekr to 02e4 - czyli jako adres asemblacji przyjmuje adrez z makra ini (2e2)+PC

Wylazlo to przy testach mojego asma :) (w ramach pracy 'pseudonaukowej' implementuję "Compiler Design" ;)
Mads w wersji nanjowszej

"Was powinny uzbrojone służby wyciągać z domów do punktów szczepień, a potem zamykać do pi* za rozpowszechnianie zagrożenia epidemicznego" - Epi 2021
"Powinno się pałować tylko tych co tego nie rozumieją. No i nie szmatki i nie chirurgiczne tylko min FFP3, to by miało jakiś sens. U mnie we firmie, to jak przychodzi bezmaskowiec, to stoi w deszczu przed firmą" - Pin 2021

25

Odp: bugi w mads

ini adr
to w rzeczywistosci
org $02e2
.word adr

czyli... wszystko gra.

Ostatnio edytowany przez xxl (2016-01-12 20:59:17)

http://atari.pl/hsc/ad.php?i=1.