jAsm

[bjonte]

Ytterligare en allvarlig lus är funnen. Med komplicerade uttryck innehållande makrokod som genererar mycket lokala variabler och en dos otur så kraschar assemblern. Jag har löst detta och ska fixa en ny release idag förhoppningsvis.

[bjonte]

Jag har släppt en ny version nu med ett par löss borttagna. Jämförelsen mellan nycklar i en map-typ var för restriktiv och krävde att typen är densamma även om värdet är lika. Copy-on-write-mekanismen är optimerad för att undvika kopiering ifall det bara finns en referens till objektet som ska kopieras. Utan den blir listor och map-objekt väldigt långsamma när de blir större. I samma veva så tas möjligheten att ha flyttal som nycklar i en map. Det beror på att man inte ska jämföra likhet mellan flyttal då det mest är förvirrande på grund av precision och positiv/negativ noll.

[bjonte]

TBC började använda språket flitigt och hittade ett par riktigt allvarliga problem i z80-versionen förutom några dokumentationsmissar. Det var krockar mellan namn på processorregister och automatiska variabler och nyckelordet ’in’ som används i for-loopar. Det gick inte heller att döpa lokala variabler till .inc till exempel. Det har aldrig gått men det är fel ändå.

Jag har styrt upp detta och släppt en ny version som gör rätt och kan använda instruktionsnamn i lokala variabler. Loopar och automatiska variabler funkar som de ska.

Hur är det möjligt att något sådant kan komma förbi 600 unittester kan man ju undra och det är för att de flesta av testerna är skrivna med 6502-kod i sig. Det blir bättre med tiden dock.

[bjonte]

En till användare har dykt upp som nu vill ha support för ZX80/ZX81-teckensträngar. Jag måste nog byta ut det här med

Kod: Markera allt

s"screen"
S"SCREEN"
p"petascii"
P"PETASCII"


Jag tror att det bästa är att gå över till att ha en funktion faktiskt för att inte syntaxen ska variera med nya varianter. Något i stil med detta.

Kod: Markera allt

string("min text", "petascii")


[bjonte]

Efter en hel del funderande har jag implementerat vad jag tycker är en rimlig lösning på problemet. Funktionen string() tar nu ett antal extra argument som anger egenskaper vid teckenkonverteringen. Först ett format som kan vara ”petscii” eller ”zx81” typ. Sedan ett valbart underformat som i petscii-fallet skulle kunna vara ”lowercase” eller ”uppercase_screen” till exempel. Man kan också ange en teckenuppsättning kopplad till språket, även om bara engelska stöds just nu.

[bjonte]

Jag snackade med min kompis Adam om det här med att sätta namn på adresser inuti instruktioner för att modifiera koden under körning. Det går ju att göra ganska smidigt redan.

Kod: Markera allt

lda addr:$1234


addr kommer att vara adressen till pekaren $1234. Om man vill ändra på höga och låga delen av pekaren så gör de flesta nog såhär.

Kod: Markera allt

sta addr
stx addr + 1


Det här med +1 är inte jättesnyggt egentligen. Jag kom på att assemblern faktiskt har information om hur stor en label är i vissa fall. I fallet att labeln är två bytes skulle jag kunna införa den här syntaxen för att komma åt låga och höga delen av pekaren.

Kod: Markera allt

sta addr.lo
stx addr.hi


[bjonte]

Nu när jag har suttit och mekat med 128:an så har jag hittat flera saker som jag vill förbättra framöver. Den första är att det inte finns en log_n-funktion som kan använda vilken bas som helst för logaritmen. Det typiska fallet är att vilja göra log2. Det går ju att trassla med att räkna fram själv men det känns inte som att det borde behövas.

Den andra saken är att när adresser är större än $ffff så funkar inte högbyte-operatorn (>) så bra längre. Den returnerar adressen dividerad med 256 och det kan ju bli större än 255, vilket vanligtvis får en del kod att inte assemblera längre.

Kod: Markera allt

const address test = $10000
lda #>test // Error 3007 : Addressing mode needs a byte size argument.

Jag har löst det hittills genom att köra adressen genom word-funktionen.

Kod: Markera allt

const address test = $10000
lda #>word(test) // OK

Men det blir ju klumpigt. Frågan är om det är rimligt att låta högbyte-operatorn returnera (addr>>8)&255 istället. Det får ju bort alla dessa fel men kan potentiellt gömma verkliga fel där adressen har ballat ur av någon annan anledning. Detta skulle också kunna aktiveras endast om bank-modet är påslaget, som en kompromiss.

[Redreamer]

Om <adress ger den lägre adressen
Borde inte högopperatorn
>adress ge nästa byte? Jag hängde inte med på det där med delat 256?
Skulle man inte kunna ha
>>adress för den tredje adressbyten?

Fast jag har kanske missupfattat allt

Skickat från min ANE-LX1 via Tapatalk

[bjonte]

Om <adress ger den lägre adressen
Borde inte högopperatorn
>adress ge nästa byte? Jag hängde inte med på det där med delat 256?
Skulle man inte kunna ha
>>adress för den tredje adressbyten?

Det är i princip så nu i och med att > betyder shifta 8 bitar. Då kan operationen göras igen så som du beskriver. Det är inte vanligt för mig att behöva göra det. Däremot är det vanligt att göra detta:

Kod: Markera allt

lda #<addr
sta addr_ptr
lda #>addr
sta addr_ptr


Kruxet är att om addr är $12345 så kommer tredje instruktionen inte att assemblera. lda #>addr kräver en byte och $123 får inte plats.

[Redreamer]

ok. Well, jag tror du kommer på hur det löses bäst. Har aldrig kört 128an så att jag behövt fundera i dessa banor.

Skickat från min ANE-LX1 via Tapatalk

[bjonte]

På Datastorm så snackade jag och Syntax om tricket för att läsa slutliga värdet av en variabel var som helst i programmet. En variabel kan ju ändras allt eftersom i programmet så värdet är ju var det är för tillfället.

Kod: Markera allt

var a = 0
++a; // 1
++a; // 2

Tricket är att tilldela till en konstant för de kan ju läsas var som helst.

Kod: Markera allt

print(”{}”, b) // 2
var a = 0
++a; // 1
++a; // 2
const b = a

Syntax föreslog en genväg i form av ett funktionsanrop likt detta.

Kod: Markera allt

final(”a”)

Tyvärr måste namnet anges som en sträng för att kunna tillåta att man pusslar ihop namnet med strängoperationer.

[bjonte]

Jag har nu släppt en ny version som har legat i startgropen väldigt länge. Den innehåller några små förbättringar som att det går att ha noll-tecken i strängar och att det finns en flagga för att konvertera strängar så att de får 7:e biten satt på sista tecknet. Jag har fixat så att högbyte-operatorn (>) returnerar ett 8-bitstal ifall bankmodet är påslaget. Jag korskompilerar nu Windowsbinärer så att jag slipper att starta Windows bara för att bygga en release. Det kommer sannolikt innebära tätare släpp med mindre förändringar.

Jag ska göra klart spelet som jag håller på med och sedan köra ett längre pass och förbättra jAsm med alla saker jag har samlat på mig under lång tid.

[bjonte]

Idag sprang jag på en störande sak. Jag hade en bit kod som var tajmingkritisk och den kan inte ligga över en 256-bytes sidkant. Jag hade inte gjort någon assert på detta så saker gick bara sönder. Lösningen blev att göra en ’align 128’ före koden för att garantera att den inte spiller över en kant.

Problemet med detta är att onödigt mycket utrymme spills för koden behöver ju egentligen inte ligga först OCH vara alignad till 128. Det skulle behövas ett nyckelord för att beskriva att en bit kod eller data behöver flyttas fram bara om den hamnar över en kant. Ungefär såhär:

Kod: Markera allt

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


Om koden är för stor för att rymmas i 256 bytes så genereras ett fel. Detta skulle också kunna användas för att tvinga in kod i block för olika banker i en cartridge.

Namnet på nyckelordet behöver förbättras lite bara.

[bjonte]

Nu har jag hållit på och reserverat och definierat data som är 24 bitar en massa gånger. Jag måste införa en datatyp för detta. Det kluriga är att hitta på ett vettigt namn. Jag har funderat på 'xword' eller 'eword' med tanke på att det ligger mellan word (16 bit) och long (32 bit). Såhär i efterhand kanske det hade varit bättre att välja typnamn som indikerar bitdjup, som word8, word16 och så vidare, men nu är det ju inte så. 'short' är också ett alternativ, men det låter så kort med tanke på att det är den näst längsta typen. 'long24' kanske, fast det blir lite blandad namngivning kan jag tycka.

[Redreamer]

Jag har aldrig kommit på tanken att köra 24 bitar i 64an så det låter väldigt främmamde. Antar att det är lite av ett specialfall eftersom du själv inte tänkte tanken tidigre?

Skickat från min ANE-LX1 via Tapatalk