i moze jeszcze przelacznik na budowanie plikow binarnych z pelnym naglowkiem a nie skroconym - bo teraz mozna zapisac standardowy plik binarny ktory sparta zle interpretuje

chyba nie rozumiem. ktory z problemow to rozwiaze:

1. -M          - standardowa wielkość bufora wyjściowego (standard (252 bytes) buffer out size) - z ustawiana wielkoscia
2. po (lub przed) kazdej akcji oproznienia "bufora wyjsciowego" madsa kompilacja jakiegos makra
3. przelacznik na budowanie plikow binarnych z pelnym naglowkiem a nie skroconym

ale ja nie chce uzywac ORG, to by bylo zupelnie bez sensu... (punkt 1) asembler sam poszatkuje kod wynikowy naglowkami, nie chce ani liczyc kiedy wypada koniec bloku (o podanej wielkosci) ani uzywac align...

Mads 1.9.7 taki kod:

  blk reloc main
  jmp *+3
  jmp @+
@:
  jmp ?
?:
  rts

jmp *+3 nie tworzy relokowalnego kodu, pozostałe tworzą.
Zrzut z monitora:

1022: 4C 03 00  JMP $0003   ;CASINI+1
1025: 4C 28 10  JMP $1028
1028: 4C 2B 10  JMP $102B
102B: 60        RTS

Nie zawsze jest jmp 3 - czasem są tam dziwne adresy.

Skoro nawet wg Ciebie xasm nie jest obecnie porządny, to mads jest lepszy. 2+2=4 :) Jak napiszesz to będzie :D (kiedy deadline? :D )

syscall: Tak się składa, że każdy koder pisze w którymś momencie swojej kariery jakiegoś asemblera. 90% nie kończy, a z tych ukończonych tylko dwa używa ktoś poza autorem.
Wiem, bo sam teraz piszę swojego trzeciego z rzędu asemblera, ale się z tym nie obnoszę, bo pewnie znowu trafi do tych 90% :)
Zalecam więc trochę pokory, bo jaki mads jest każdy widzi, ale jest ukończony i działający na tyle, że używa go większość atarowskiego światka.

Dziękuję. Teraz działa poprawnie.

Miałem odpisać na maila, ale widzę wątek, to napiszę tutaj. Może ktoś będzie miał lepszy pomysł.

Zastanowiłem się nad tym i jest w tym trochę racji, żeby udostępnić taką wbudowaną funkcjonalność.
Narzędzia, z którymi się spotkałem zawierają takie makra. Przykłady

- C/C++: http://gcc.gnu.org/onlinedocs/cpp/Stand … acros.html
- NASM: http://www.nasm.us/xdoc/2.11/html/nasmd … ction-4.12
- Coś podobnego ma nawet Free Pascal: http://www.freepascal.org/docs-html/prog/progap7.html

Pewnie wiele innych też.

Zaproponowane przez Ciebie rozwiązanie ma taki problem, że nie jest przenośne: nie jestem w stanie zrobić projektu, w którym będę wstawiał np. datę assemblacji tak, aby każdy mógł to skompilować na dowolnym systemie. Musiałbym pisać osobny zestaw skryptów dla Windowsa i dla Linuksa.

Nie wiem ile w tym jest sensu, ale przyszło mi do głowy pewne generyczne rozwiązanie: pseudorozkaz GEN("description"), który pełniłby rolę uniwersalnego generatora zastępującego swoje ciało wygenerowanym napisem na podstawie podanego opisu. Można byłoby dla pełności zaimplementować w nim część istniejących pseudorozkazów:

gen("rnd(0,33,256)")  ;losowa liczba
gen('date("F j, Y, g:i a")')           ;data, np. formatowana jak w PHP: March 10, 2001, 5:16 pm
gen("line")           ;aktualny numer assemblowanego wiersza
gen("count")          ;kolejna liczba zwiększana o jeden przy następnym wywołaniu

Idąc za ciosem można byłoby dodać drugi pseudorozkaz, który nawet przydałby się mi:  SYS("command", [args...]), który odpalałby nowy proces o podanej nazwie i wstawiał w miejsce swojego ciała zawartość zwróconego standardowego wyjścia:

.he sys("SuperTableGenerator", 42)

Rezultat: wynik jakiegoś programu generującego super tablice ("SuperTableGenerator.exe") jako ciąg wartości szesnastkowych przyjmującego jeden argument.

Oczywiście "sys" byłby zależny od systemu, ale stanowiłby niezłą furtkę dla prostego generowanie zawartości. Ja często piszę skrypty w ruby, które generują mi jakieś dane, tylko teraz generuję plik binarny, któremu robię "ins", a tu można byłoby generować dane wprost.

W przypadku wielu przebiegów można byłoby cachować wartości wygenerowane przy pierwszym przebiegu.

A dlaczego wszystko chcecie mieć w assemblerze, a nie chcecie korzystać z zewnętrznych narzędzi? IMHO assembler powinien w zasadzie tylko assemblować mnemoniki i generować kod relokowalny dla linkera, a linker na podstawie modelu pamięci i rodzaju pliku wynikowego powinien wygenerować co trzeba (nierelokowalne lub relokowalne).
Jak Fox powiedział - generowanie dodatkowych danych załatwia make, włączanie tego do kodu załatwia preprocesor, kompilację assembler. Tebe ma mniej roboty, mads działa lepiej bo jest łatwiejszy w utrzymaniu i wszyscy są zadowoleni.

A ja pomysł wykorzystałem do automatycznego odkładania kopii źródła *.asm z aktualną data/czasem co każdą kompilacje. Co wieczór jest z 30 nowych backup'ów - łatwo cofnąć się do poprzednich wersji...

1. Utwór katalog Backup tam gdzie jest plik *.asm
2. dodaj linie do BATCHa na jego koniec:

For /f "tokens=1-4 delims=/-" %%a in ("%DATE%") do (
    SET YYYY=%%a
    SET MM=%%b
    SET DD=%%c
)
For /f "tokens=1-4 delims=/:.," %%a in ("%TIME%") do (
    SET HH24=%%a
    SET MI=%%b
    SET SS=%%c
    SET FF=%%d
)

if exist BACKUP copy "%1",BACKUP\"%~n1"_%YYYY%-%MM%-%DD%_%HH24%-%MI%-%SS%.asm

Zgadzam się z Laoo. Ja używam git'a i jest git:) masz unlimited undo, branche, diff'y a raz na jakis czas mozesz (nie musisz) wyslac zmiany na serwer by miec external backup (np https://bitbucket.org/ jest za free - np ja tam trzymam moje atari kody). to znacznie lepsze niz tagowanie lokalne podczas build'ow.