SjASMPlus от z00m

[Ped7g]

NEO SPECTRUMAN:

16ki defarray... hmm... Well, this breaks multiple limits (line limit is 2048 characters and defarray ... defarray is actually linked list with O(N) access time, so defarray itself would work, it would be just a bit slow for large operations O(N*N) for 16ki data created from 16ki defarray, which is still only about ~250mil iterations, so it would very likely still assemble faster then Android Studio edits text).. ok, so this breaks line(parser) limit only, not multiple limits.

From your proposals something like "defarrayadd" seems quite reasonable.

But overall it feels to me like pushing the defarray a bit too far... it's more like string collection (being substituted in early phase of assembling similar way like any other DEFINE), i.e. quite heavy on memory storage and processing, I wouldn't think of it for 16ki array of int16_t.

Although reading your source example again, there's nothing particularly wrong about it from the coder perspective (I have just skewed perspective by knowing the implementation).

How you can work around it in current sjasmplus:

One option is to use device memory as table:

    DEVICE ZXSPECTRUM1024  ; some large memory device
    MMU 0 1, 62    ; map last memory pages into 0000-7FFF range (16ki of words = 32kiB)
    ORG 0
    ; define values as you wish (has also "fill" in the "BLOCK" (DS) pseudo instruction)

    ORG 0x8000    ; now regular code follows, using the table values
    ld   bc,{1234*2} ; = ld bc,word from address 1234*2 (i.e. index 1234 into word table)
    ; but the value read from device memory is correct only at the last pass (enough for instructions)
    ; so this will not work for early pass assembling branching like: IF {1234*2}=4

The {} operator is undocumented "read word from device memory at assembly time" (seems like it's available long time, probably before 1.07, but nobody documented it, and me neither, because I'm not 100% sure it will stay precisely like this in the future, although some similar form will surely remain, because sometimes it's handy). This one is pretty close to O(1) complexity when accessing values, so even the assembling of such source will be probably a bit faster than defarray. And after you are done with the part of code needing the table, you can reuse the device memory/slots for normal parts.

Other option depends what are the data, if you can somehow calculate them by formula, it may be possible to create some FOR loop with formula (how to create FOR-like loops: https://github.com/z00m128/sjasmplus.../fake_for2.asm

Or finally the Lua is probably powerful enough to just generate the final result you are after (i.e. whether you can calculate values by formula, or you need 16ki table of data and you can produce the final code instead of just doing the table work).

Or obviously you can use any other language to generate "asm" file for you, for more complex code generators it may be simpler to use language you are familiar with.

... I will think about some kind of "defarrayadd", but it still feels slightly "misused" to me at this moment, but that's maybe just a feel. Although I'm not sure about final performance of such code... probably no big issue with modern CPUs with O(N*M). Hm, I will probably add it (should be easy to implement, and it will help to produce shorter lines even with "small" defarray tables = easier to read source = good).

------

Bedazzle:

That's good question, and from my head I would guess there's no good way to work with strings in bare sjasmplus.

You can (similarly as above) work around it by putting the string into device memory (DZ _VERSION = zero terminated string in memory) and then read WORDs of it by {} operator, or you can process it in LUA script (Lua can read defines, i.e. _VERSION too).

I have in my TODO "operators for string manipulation", so maybe in future there will be new tools for this, but at this moment you can compare only last four characters in v1.13.0 (as if comparing numbers):

    IF _VERSION = "13.0"   ; or: IF _VERSION = 0x31332E30
        DISPLAY "version \"13.0\" detected (_VERSION=\"", _VERSION, "\")"
    ENDIF

output:

test_version.asm(1): warning: String literal truncated to 0x31332E30: "1.13.0"
> version "13.0" detected (_VERSION="1.13.0")

(it will produce also that warning, but I don't see any simple way to suppress it)

This feels like some unfinished business on the sjasmplus side, thank you for pointing it out.

(you can suppress those overflow warnings to minimum by doing "VERSIONNUM = _VERSION" very early in the source = creating symbol/label with that last-four-chars numeric value, then you can use it in remaining IF blocks: IF VERSIONNUM = "13.0" will produce no more warnings ... so only the initial conversion from string to numeric symbol will do warnings)