jAsm

[bjonte]

Det här med anonyma labels har jag funderat på men inte bestämt mig för om det ska finnas eller inte. Mest kanske för att jag själv aldrig använder detta. En sak som jag kommer att bygga in är automatiska loop/continue/break-labels vid variabelgränser. Man kan definiera ett variabelutrymme var som helst i programmet med krullparenteser. Inledande parentes har automatiskt loop definierad och avslutande parentes har continue och break definierad. Detta gör att man kan uttrycka vad man menar lite tydligare utan att för den skull behöva hitta innovativa namn. Det skulle i ramlinkexemplet kunna se ut såhär.

Kod: Markera allt

subroutine test
{
   lda ramlinkOpcode
   cmp #$91
   bne rlPageOpWrite
   {
      dex
      dey
      beq break
      {
         lda rlPageData,x
         sta (zp),y
         dex
         dey
         bne loop
      }
   }
   lda rlPageData,x
   sta (zp),y
   jmp rlPageOpContinue
}


[carlsson]

Den här assemblatorn kommer att ha så många finesser att det tar längre tid än normalt att skriva koden, eftersom man kommer att fundera på vilka av assemblatorns inbyggda funktioner man skulle kunna nyttja, istället för att bara mosa på med gammaldags kod.

[bjonte]

Haha, den har egentligen inte så mycket mer än andra assemblatorer. Den är annorlunda och förhoppningsvis kan den låna det bästa från alla andra. Jag ska den här veckan börja porta Bruce Lee II för att kunna jämföra hastigheten med DAsm.

[TBC]

Verkar som det är snart klart för betatesting. Måste fundera på vad jag ska programmera för något till 64:an. Vill göra ett demo känner jag, men måste fundera ut nåra fina effekter.

[bjonte]

Ja, betatestning vore jättebra. Jag har ingen dokumentation än dock. Jag tänkte skriva den efter att jag har portat Bruce Lee II.

[TBC]

Jag börjar väl programmera i Dismon så länge

[bjonte]

Gaah!

[carlsson]

TBC: Det måste väl inte vara C64. Det finns ju massor av andra skapelser med 6502!

Kanhända version 2.0 av jAsm kommer att stödja fler processorer? Mycket av makrohanteringen m.m. är ju användbar oavsett assemblerspråk. Jag vet ju inte hur modulärt bjonte byggt den, men misstänker att tanken slagit honom redan. Som exempel klarar ju DASM såväl 6502 som 68xx, 68HC11 och med hemgjort tillägg även en så udda fågel som F8.

[bjonte]

Kanhända version 2.0 av jAsm kommer att stödja fler processorer?

Ja, det kan hända. Jag har tänkt på det men det är inte fullständigt separerat. Syntaxen kommer att skilja sig så det är inte bara att plugga in, men det är inget jättejobb. Jag har mest tänkt på Z80.

[bjonte]

Assemblern har stöd för flera datatyper. Till att börja med finns boolska, heltals- och flyttalstyper. Det finns implicit konvertering från heltal till flyttal men inga andra implicita konverteringar. Det gör att det går att multiplicera flyttal med heltal utan krångel.

Kod: Markera allt

const a = 5 * sin(PI/2) // ett flyttalsresultat


Vanliga matematiska funktioner för trigonometriska beräkningar och logaritmer till exempel finns fördefinierade.

När man vill klippa bort decimalerna för att lagra flyttal som heltal i minnet så finns två alternativ. Antingen så typomvandlar man med funktionen int() eller med byte(), word() eller long(). int() kontrollerar att resultatet inte är för stort eller för litet och klipper bort decimalerna. byte(), word() och long() klipper bort decimaler och oanvändbara högre bitar utan kontroller.

Vanliga boolska operatorer är definierade exakt som i C. Enda tillägget är att operatorerna &&= och ||= existerar. Till skillnad från C tar if-satsen ett boolskt värde och accepterar inget annat. Det är en hård kontroll att värdet inte är något oväntat.

Kod: Markera allt

const a = 0
if (a) { // FEL, a är inte en ett boolskt värde
  nop
}


[bjonte]

Idag har jag tagit bort reorg-nyckelordet. Reorg används i DAsm för att assemblera kod som om den låg någon annanstans i minnet. Jag sitter och skriver om Bruce Lee II nu och jag sprang på detta i turboloaderkoden. Turboloadern ligger i c64:ans minne först och kopieras över till diskdriveminnet. Den ska ligga mellan $500-$800 där. Detta så ut ungefär såhär:

Kod: Markera allt

  org $0800
  seg code
  ...
  ; kod som kopierar drivekod till diskdrive...
  ...
  rorg $500
    ...
    ; drivekod
    ...
  rend
drive_end:
  seg.u bss
  ...
  ; drivevariabler
  ...
  if * > $800
    err
  endif
  org drive_end
  ...
  ; resten av programmet


Jag hade också en reorg-konstruktion men jag tog bort den för att förenkla det här fallet. Istället tillåts sektioner i sektioner. Detta innebär ungefär samma sak. Den yttre sektionen är den som genererar data och de inre bidrar med data som kan assembleras som från en annan plats. Det fina är att sektioner kan ha ett slut och inte bara en början. Om den har ett slut blir det ett assembleringsfel om man kommer över kanten så att säga. Det skulle se ut såhär:

Kod: Markera allt

  section code, "main", $0800
  {
    ...
    ; kod som kopierar drivekod till diskdrive...
    ...
    section code, "drive code", $0500, $0800
    {
      ...
      ; drivekod
      ...
      section bss, "drive vars", *, $0800
      {
        ...
        ; drivevariabler
        ...
      }
    }
    ...
    ; resten av programmet
  }


Bss-sektionen använder * som startadress och det betyder som vanligt nuvarande programräknare så att man kan börja sektionen direkt där man är.

[TBC]

Om man vill göra motsvarigheten till:

ds.b 1,2,3

blir det alltså:

define byte[] b = {1,2,3}

Eller finns det nåt bättre sätt där man slipper namnge varje array med bytes?

[bjonte]

define byte[] unnamed = { 1, 2, 3 }

[bjonte]

unnamed är ett nyckelord som gör att ingen symbol skapas. Det funkar på reserve också. Det här är pratigt men jag tycker att det är tydligare att läsa. Jag hade svårt att fatta skillnaden mellan dc.b och ds.b.

[TBC]

I dina tidigare exempel i denna tråd hade du inga krullparenteser i listorna, har du ändrat den syntaxen?