Proszę nie używać liczby mnogiej, bo propozycja jest tylko moja i dziękuję za krytykę :)
Propozycję pseudorozkazu "sys" uzasadniam domniemaną trywialnością implementacji i prostotą użycia, ale po argumencie Foxa uświadomiłem sobie, że w takim rozwiązaniu zewnętrzny program wołany byłby przy każdej asemblacji, podczas gdy rozwiązanie z plikami pośrednimi sterowane make lub odpowiednikiem minimalizuje liczbę wywołań, co jest oczywistym plusem w przypadku skomplikowanych generatorów. Ostatecznie zły pomysł.

A pseudorozkaz "gen"? Ideą jest minimalizowanie liczby zastrzeżonych słów kluczowych będących nośnikami jakichś wartości, które można w przeciwnym razie mnożyć w nieskończoność, a za jego pomocą niejako rezerwujemy na nie osobną niekolidującą przestrzeń nazw.

Wciąż także nie wydaje mi się, aby podstawowe makra (data, itd) nie mogły być realizowane automatycznie np za pomocą takiego generatora. Konieczność instalowania środowiska dlatego, że autor kodu źródłowego napisał sobie linuksowego wsada generującego coś, co może być w samym asemblerze wydaje mi się nadużyciem.

Z tymi 16 bitami z pełnymi konsekwencjami to trochę przesada. Mimo szczerych chęci nie nazwałbym 65c816 w pełni 16 bitowym. To taki 8/16. Nie ma 16 bitowego "feelu". Programując go ma się raczej poczucie takiego Z80 (też ma 16 bitowe rejestry) albo 6809 (który ma bardzo zbliżony "layout"). Porównaj to sobie do takiego 8086, którego 16 bitowość jest już inherentna.
Jasne, że 816-tka ma 24-bity przestrzeni adresowej, ale to jest raczej danie 8-bitowcowi okienka na 16-to bitowy świat, przez które zagląda do większej pamięci...

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.

21. Rozbijanie płyty, ale na QuST 98. Dwóch od lewej to Solo i Tiger.
58. Rozbijania ciąg dalszy. Tleniony blondynek w środku to Solo. Z prawej jest Tiger i ja chwytający się za głowę :)
90. Po rozbiciu. Od lewej Roland, Tiger, Solo
73. Blondynek w pasiastej koszuli to oczywiście Solo
41. A tu trochę starszy, więc to na pewno jakiś późniejszy zlot.
76. Pet koduje tu Sheola :)

W robocie utrzymuję konfigurację windowsową (visual) i linuksową (gcc makefile) sporego projektu i dorobiłem się kilku automatów, ale w ogólności nie każdy projekt visuala da się trywialnie przerobić na coś strawnego na linuksie. Jeżeli to nic tajnego, to mógłbym na to zerknąć ( laoo ( at ) icomp . pl )

saulot: Pytasz o jakich dokumentach mówię? Odpowiadam, że chociażby o jedynym normatywnym, czyli "Standard for Programming Language C++" generowanym przez WG21. Zerknij sobie tu. Ostatni working draft sprzed standardu C++11 ma numer N3242. Jeśli do niego zerkniesz, to zauważysz, że na 1300 stron, 400 jest o języku, a 900 o bibliotece. Najbardziej kluczowym aspektem tej biblioteki jest nacisk na programowanie generyczne (stąd np podział na kontenery i algorytmy). Można napisać niezależne biblioteki podążające tym tropem, czego przykładem jest np boost. Qt jednak skrzętnie od wielu lat ignoruje kierunek, w którym rozwija się C++ opierając swój framework na zupełnie innych założeniach bardziej zbliżonych do języków zarządzanych, a nawet dynamicznych, które są sprzeczne z inherentną statycznością C++.

Stąd moje twierdzenie, że Qt nie używa standardowego C++.

Tak całkiem teoretycznie to nie jest takie środowiska wcale potrzebne. Program napisany pod Visual Studio używający np Qt po przekompilowaniu na linuksa powinien po prostu zadziałać, o ile napisało się go oczywiście dostatecznie przenośnie, ale Qt jest frameworkiem, który dostarcza praktycznie wszystko, więc jak ktoś chce, to nie musi poza niego wychodzić.

Używam tych makr. Tutaj akurat chodzi o hint dla asemblera (deklarację) jaka jest spodziewana szerokość rejestrów w danym miejscu, tak, aby asembler mógł wygenerować błąd, jeśli obliczona przez niego szerokość będzie różna, czyli np. (w pseudokodzie):

regA 16  ;rozkaz przełączający akumulator na 16 bitów
.a8 ; deklaracja, że w tym miejscu akumulator ma rozmiar 8 bitów -> ERROR

albo

.proc Prodecura
.a16 ;deklaracja 16-bitowego akumulatora.
...
.endp

...

.a8   ;deklaracja 8-bitowego akumulatora.
jsr Procedura  ;skok do procedury z kontekstu 8-bitowego akumulatora.
                Procedura deklaruje szerokość na 16-btów -> ERROR
...

Ej. A może koledze chodzi po prostu o wgranie programu w BASICu (który ma na PC w postaci pliku tekstowego) do atari, żeby pojawił się w tam jako program (czyli LIST, RUN... te sprawy)?

O! Super! Wiedziałem TeBe, że można na Ciebie liczyć :)

Jak zrobi się opt h- (w przykładzie jest przypadkowo h+), to generowany plik jest identyczny jak z AlfAssemblera.

OK. O tym nie myślałem. Nie wiem czy stosunek trudność do zysków jest opłacalny, żeby się za to zabrać. A format COMa position-independent, którego trzeba po prostu załadować pod dowolny adres, potrzebuje przynajmniej nagłówka sygnalizującego niezależność od adresu oraz długość bloku. Czegoś takiego nie ma, bo na 6502 nie było to sensowne, a na 65c816 już tak.

Operatory < ! > wydają się sensowne. Asembler powinien tylko wypisywać warning gdy żaden operator nie jest użyty (programista oczywiście może wiedzieć o co mu chodzi, ale tutaj wg mnie lepiej być dosłownym, bo to zmniejsza okazję do błędu).

Mads ma 24 bitowe adresowanie, nie potrafi tylko ustawić adresu asemblacji na adres spoza banku zerowego. Nie potrafi tego ani dyrektywa ORG, ani .SEGDEF. Odkryłem jednak, że potrafi to blok .PROC, któremu można ustawić dowolny 24-bitowy adres. Gdy już myślałem, że jest to rozwiązanie, okazało się, że z 24-bitowego adresu nie można (albo raczej nie potrafię) wyciągnąć 16 bitowego offsetu w segmencie i taki kod się nie kompiluje:

    opt h- c+

    org $0000

    .proc test, [$010000 + *]
label    lda.w #label
    .endp

label    lda.w #label
test.asm (6) ERROR: Value out of range

O nagłówku $FBFB dobrze wiedzieć. Szukałem czegoś takiego. Sprawdziłem i działa poprzez dodanie nagłówka z dwoma 24-bitowymi adresami do każdego bloku. Aczkolwiek wydaje mi się, że adres końca wystarczyłby 16 bitowy, ale to już szczegół.

Co do asemblerów, to w grę wchodzą tylko cross-assemblery (mam już środowisko do budowania itd). Co jest w madsie, a niema tego (nie znalazłem) nigdzie indziej, to idea procedur (bloki .PROC), która po podrasowaniu bardzo dobrze może wpisywać się w schemat programowania 65c816. Blok .PROC grupuje fragment kodu w logiczną całość z lokalnymi etykietami, a przekazywanie parametrów może być zrealizowane za pomocą stosu 65c816. Np. "engine" do deklarowania parametrów procedury mógłby służyć do śledzenia zawartości stosu. Np takie procedury mogłyby być tożsame:

    .proc sum1 ( .BYTE par1,par2 )
    lda pra1
    clc
    adc par2
    rts
    .endp


    .proc sum2
    lda 2,s
    clc
    adc 1,s
    rts
    .endp

Dodatkowo procedury można byłoby wzbogacić o chociażby specyfikację stanu procesora jaki w niej obowiązuje (długość rejestrów) i asembler mógłby śledzić czy stan jest spójny pomiędzy wywołaniami (niby nie daje to żadnych gwarancji, ale pomaga przy zachowaniu konwencji, no i tak, wiem, że mechanizmy śledzenia to nic nowego :)).