Kod źródłowy (dupa.s):

        blk sparta $0600

start   nop
        rts

krupa   .ds 1
strupa  .ds 1

Wygenerowaną binarkę (mads dupa.s) poddajemy działaniu komendy FSTRUCT DUPA.OBX. Wynik:

Size: $000010 (16) bytes

$000000 Head: $FFFA (StdBlk)
$000006  Seg: $0600-$0601 Len: $0002 (2)
$000008 Head: $FFFE (RelBlk)
$000010  Blk: 1, Mem: $80 Len: $0002 (2) Off: $0602

End of file

Mamy blok tu blok binarny o wielkości 2 bajtów (kod, NOP/RTS), ładowany pod $0600, plus blok alokujący 2 bajty nad memlo dla zmiennych krupa i strupa.

Dyrektywy .ds nie powinny tak zadziałać w tym miejscu. W bloku blk sparta powinny się zachować tak samo jak w normalnym bloku binarnym, czyli po prostu zarezerwować miejsce pod $0602 i $0603 dla obu zmiennych.

Blok rezerwacji pamięci powinny generować tylko wtedy, kiedy są użyte wewnątrz blk reloc.

Ostatnio edytowany przez drac030 (2016-03-15 01:11:17)

Ja mam wersję 2.0.0, nawet sprawdzałem u Ciebie na stronie, czy jest coś nowszego, ale wyglądało mi na to, że nie.

FSTRUCT powinien być na Toolkicie SDX.

po poprawce, mads 2.0.1 http://mads.atari8.info

jeszcze raz poprawka v2.0.3, wg moich testów teraz jest OK

po poprawce

mads 2.0.5 http://mads.atari8.info

MADS blednie kompiluje rozkaz DOP #

    14 4000 48                  .byte { DOP #$FF }
    15 4001 EA                  NOP
    16 4002 48 FF             DOP #$FF
    17 4004 48                  PHA

wczesniejsze wersje madsa w tym zakresie dzialaly prawidlowo.

nielegalne rozkazy działają nielegalnie ;P

Taki kod:

  blk reloc main
table:
?first .word 0
?last .word 0

table2:
  .byte [table.?last-table.?first]/4

generuje mi: "address relocation overload" !
Oficjalna dokumentacja (w historii) mówi: "błąd 'Addres relocation overload' wystąpi teraz tylko gdy wyrażenie będzie dotyczyć więcej niż jednej etykiety relokowalnej, poprzednio każde wyrażenie z udziałem etykiety relokowalnej powodowało wyświetlenie tego komunikatu błędu".
Ale jaki jest właściwie problem z etykietami relokowalnymi _w_jednym_bloku_? Bo ja rozumiem, gdybyśmy mieli etykietki w róznych blokach - wtedy nie wiadomo jaki będzie między nimi dystans, ale w przypadku jednego bloku wszystko przecież wiadomo...
Dałoby się to naprawić?

Edit: A druga choć związana z poprzednim przypadkiem rzecz jest taka - podobny kod;

  blk reloc main
table:
?first .word 0
?last .word 0
?len = [?last-?first]/4

table2:
  .byte table.?len

się kompiluje poprawnie, ale markuje table2 jako _adres_ do relokacji. A to już jest bardzo nieładne, bo:
1. w table2 mam bajt, a loader SDX zmodyfikuje mi tam 2 bajty,
2. table.?len jest jednak interwałem, który da się określić na etapie kompilacji i on się nie zmieni - nie powinien być relokowalny.
Kod wynikowy wygląda tak:

fe ff 01 00 00 00 05 00 
00 00 00 00 00 

fd ff 01 00 00 
fe 01
04 
fc

Edit2: Co myślałbyś o:
1. generowaniu "Addres relocation overload" tylko przy obliczeniach używających etykiet leżących w różnych blokach relokowalnych,
2. rzucaniu warninga kiedy do obliczeń używane są etykiety relokowalne - user ma być świadom tego co robi, a jak user sobie chce zaszkodzić, to niech sobie szkodzi :)

Ostatnio edytowany przez mono (2017-04-25 13:36:57)

Taki kod:

     opt c+

     blk reloc main

start pea #proc-1
     rts

proc nop
     rts

Program idzie w maliny, bo dla pea # nie jest generowany fixup, mimo że etykieta "proc" wskazuje adres.

To samo dotyczy rozkazów typu lda #$xxxx, ldx #$xxxx, ldy #$xxxx, adc #$xxxx, sbc #$xxxx itd. itp.

Mam take kuszi:

    opt o+ h+ ?+ c-

JCIOMAIN = $e456

    org $660
    rts

    org $bff0,$7ff0
    jmp JCIOMAIN

    run $660

    end

I to wyrzuca mi przy kompilacji MADSem 2.0.6 komunikat:

    run $660
orgtest.asx (13) ERROR: Illegal instruction at RELOC block

Kiedy wywalę definicję etykiety JCIOMAIN i żywcem zastąpię ją adresem wtedy wszystko się kompiluje jak należy.

I co tu począć?

Dziękuję, działa!

Pewnie tak, przyjrzę się temu