jAsm

[bjonte]

Om man pluggar in extraminne blir det aktuellt för adresser och i fysikkoden jag har används ibland 24 bitar för heltal och decimaler.

[TBC]

En tetrahex kanske?

[bjonte]

En tetrahex kanske?

Det blir kanske konstigt att associera med 4 och 6 men du är inne på ett intressant spår! ’tribyte’ känns inte helt knasigt.

[bjonte]

’dubbeldussin’, haha!

[Redreamer]

Kör på't

Skickat från min ANE-LX1 via Tapatalk

[bjonte]

Nu kom jag på en till obskyr egenskap som jag vill ha. Jag vill kunna definiera ett block där det inte är tillåtet att använda stackoperationer. Det här blir användbart i C128-programmering när stacken har flyttats temporärt för att användas till att manipulera minne. Ett hopp till en subrutin kladdar ju ner området då så det kan inte tillåtas. Det vore fint att kunna uttrycka det och få assemblern att tvinga en att inte göra fel där. Typ såhär:

Kod: Markera allt

nostack {
  lda #0 // ok
  jsr test // error
  pha // error
  pla // error
  sta sak // ok
}


[bjonte]

Jag har nu börjat koda in nya saker i assemblern. Jag har funktioner för att ändra strängar till versaler eller gemener och jag har lagt till en logn-funktion. Nu går det också att adressera låg- och högbyte i ett ord genom att lägga på .lo eller .hi till variabelnamnet.

Kod: Markera allt

// dessa får samma resultat
lda addr.hi
lda addr + 1

define word addr = 1000

Ett kanske vanligare scenario om självmodifierande kod används:

Kod: Markera allt

lda #$00
sta .addr.lo
lda #$c0
sta .addr.hi

...

lda .addr:$ffff,x


[bjonte]

Jag klurar nu på hur jag ska lösa att hålla en bit kod inom ett 256-byte-block i minnet. Jag tänker att det finns potentiellt två fall att hantera. Dels att varna för att koden spiller över en block-kant och dels att fylla ut minnet med något tills koden ligger helt inom blocket.

Kod: Markera allt

no_crossing 256
{
   ... kod här ...
}

no_crossing_align 256, $ea
{
   ... kod här ...
}


[Redreamer]

Något som jag alltid blandar ihop (av oerfarenhet) är
Lda #<label

där hade
lda #label. hi passat fint. Men jag är kanske ett undantag. Eller fungerar det att göra så?

Skickat från min ANE-LX1 via Tapatalk

[bjonte]

Bra fråga. Nej, det skulle inte funka just nu. Orsaken är att om label är en define som pekar på ett word så går det inte att skilja på label.hi som blir adressen till minnesplatsen för höga byte:n och label.hi som skulle vara höga delen av labeladressen.

Du kan komma runt detta genom att en gång för alla göra ett macro som hämtar rätt del av adressen.

Kod: Markera allt

macro low(.addr)
{
  return <.addr
}
macro high(.addr)
{
  return >.addr
}

lda #low(label)
ldx #high(label)


[bjonte]

Nu har jag släppt en ny version med en del av det som jag har pratat om redan. Nu går det att anropa en subrutin som om det vore ett macro utan argument.

Kod: Markera allt

subroutine test
{
    ...
}

test() // genererar ’jsr test’

Jag har också lagt till alias för bcs och bcc för att det lättare ska gå att fatta hur de ska användas i jämförelser.

Kod: Markera allt

bhs label // hoppa om högre eller lika med
blt label // hoppa om lägre än

[Redreamer]

Får ladda ner och testa lite sen då, men jag kör inte så avancerade manövrar i mitt jasm utövande.
Kör lite dubbelt just nu, jasm för nytt projekt och cbm studio i det gamla. Knackade lite tangentbords inläsningskod i jasm igår dock (av enklaste sort).

[Redreamer]

Det här med ":" efter en label, är det för ökad läsbarhet?
Hade inte sådana i cbm studio så jag glömmer dem ständigt. Ok, inte ständigt, men ofta. Men de sitter nog snart lika naturligt som en kaka till kaffet.

[bjonte]

Det här med ":" efter en label, är det för ökad läsbarhet?

Nej, det är faktiskt för att det är svårare att lista ut vad källkoden betyder annars. jAsm är ganska fritt på det sättet att saker inte behöver vara på en rad, det går att ha blanktecken lite här och var och en label behöver inte heller vara längst till vänster eller ens först på en rad. Men det gör det svårare att skilja ut en label-definition från en label som används i ett uttryck.

Här är ett krystat exempel:

Kod: Markera allt

label:
++räknare


Om kolonet inte krävdes skulle detta kunna tolkas som:

Kod: Markera allt

label++
räknare


Det är nog möjligt att ta bort kravet men koden för att lista ut vad en rad betyder blir krångligare eftersom den måste läsa vidare längre för att utröna om det kan vara en labeldefinition eller något annat och det blir fler möjliga feltolkningar. Koden kommer att bli något långsammare också.

[bjonte]

Jag har fixat hexdump sida vid sida med källkoden. Det kan ibland vara bra för att se att assemblern pruttar ut det som förväntas.

Nu i helgen gjorde jag klart en refaktorering som jag har jobbat på ett bra tag. Skillnaden blir att tokenisering och syntaxanalys skjuts framåt tills en källkodsfil ska läsas in. Denna förändring gör det möjligt att inkludera filer som inte finns och assembleringen lyckas om filen aldrig behövdes. Det kan användas för att inkludera kod bara om ett visst villkor var uppfyllt. Tidigare inkluderades alltid alla filer. Nu är det också möjligt att pussla ihop filnamnet som ett vanligt uttryck så själva filnamnet kan genereras av kod.

Jag ska börja kolla på möjligheten att byta processor i källkoden istället för att ha separata exe-filer för varje processortyp. Det kluriga är hur det ska uttryckas. Jag ville först att det skulle göras med ett vanligt variabelscope. Typ såhär.

Kod: Markera allt

processor ”6502”
{
   ...
}


Men detta behöver vara ett nyckelord i tokeniseringen (för att den ändras beroende på processor) och då är det oklart vilken klammer som skulle vara slutet. Jag tror att det blir utan klamrar och så får processorbytet gälla till slutet av filen. Includefiler ärver processorn från filen som inkluderar men den inkluderande filen påverkar inte den som inkluderade. Då blir det minst strul med att någon fil petar om men vet inte vad det ska petas tillbaks till. I de flesta fall behövs bara processorn sättas en gång högst upp i mainfilen.