SjASMPlus от z00m

[Bedazzle]

Тфу ты, перепутал.
В исходнике '\\' или ""?

[Advertiser]

[Ped7g]

Is this line 106, or why do you show this part of source? I still don't understand why do you think there is some problem with include.

I need you to show the actual failure, like what result is wrong, is there some invalid machine code, or missing machine code, etc?

Maybe switch listing file on (--lst option), and see yourself, how the code is assembled, and if there is something wrong about it, then post the part where you have problem.

[krt17]

Я тебя не понимаю человек.

# file opened: test.a80
1     0000              			org	0x8000
2     8000 5C           			db	"\\"
3     8001 5C 5C        			db	'\\'
4     8003 3E 5C        			ld	a, "\\"
test.a80(5): warning: Bytes lost (0x5C5C)
5     8005 3E 5C        			ld	a, '\\'
# file closed: test.a80

Value    Label
------ - -----------------------------------------------------------

Все правильно, что тебе не нравится?

- - - Добавлено - - -

Для порядка дока

Скрытый текст

[свернуть]

- - - Добавлено - - -

АААА я понял, асм ругается не на инклюд, как ты подумал, а предупреждает что в этом инклюде в 106 строке ты пытаешься два байта загрузить в аккумулятор, и один, естественно, будет отброшен.

- - - Добавлено - - -

Пример одного из применений MAP

			org	0x8000
			MAP	0
sub1
var1			#	1
			ld	a, (vars+var1)
			ret
sub2
var2			#	2
			ld	hl, (vars+var2)
			ret
sub3
var3			#	4
			ld	ix, vars
			ld	c, (ix+var3)
			ld	b, (ix+var3+1)
			ret
vars

Надеюсь Ped7g вернет его в ветку.

[Ped7g]

Пример одного из применений MAP

			org	0x8000
			MAP	0
sub1
var1			#	1
			ld	a, (vars+var1)
			ret
sub2
var2			#	2
			ld	hl, (vars+var2)
			ret
sub3
var3			#	4
			ld	ix, vars
			ld	c, (ix+var3)
			ld	b, (ix+var3+1)
			ret
vars

Надеюсь Ped7g вернет его в ветку.

Thank you for the example. Now this is like highly subjective opinion (feel free to disagree, hehe), but I don't see anything special about it, like that I would prefer MAP way over STRUCT, actually I personally find this more chaotic and harder to read, because map fields are all over the place in code. Imagine longer code, where "var3" is 100 lines below original MAP 0, then IMO your only chance to quickly mind-map all fields is to actually assemble the file and check the labels table in listing, because looking through the code will be prone to missing other field statements, while struct has all fields defined together in one block of code (maybe in some special case that interleaved field definition inside code is actually better, but IMO for 90% of use cases it is not).

You finish with "vars" without anything after it, not clear if you intentionally left it like that (i.e. for example INCBIN "vars_init_values.bin" follows), which would made usage of structure somewhat more ugly, let's do the struct examples:

        STRUCT S_VARS, 0    ; struct has also initial offset if needed (0 here)
var1        #   1
var2        #   2
var3        #   4
        ENDS

            org	0x8000
sub1
			ld	a, (vars+S_VARS.var1)
			ret
sub2
			ld	hl, (vars+S_VARS.var2)
			ret
sub3
			ld	ix, vars
			ld	c, (ix+S_VARS.var3)
			ld	b, (ix+S_VARS.var3+1)
			ret

vars    ; INCBIN "init_values.bin" ; can't use "vars S_VARS" easily then

So this is basically 1:1 rewrite of your example, the "+S_VARS.var1" is maybe a bit verbose, but in my personal taste, I find this actually easier to read and understand, and even if you prefer the more brief MAP variant, this should be still "edible" even in this struct form?

But I can see the MAP may feel somewhat more natural especially in cases when you are "mapping" some block of data which exists outside of context of the source, like that INCBIN.

But if you are in case where you are actually also generating the data, the STRUCT will quickly give you lot more power, consider this variant:

        STRUCT S_VARS, 0    ; struct has also initial offset if needed (0 here)
var1        DB  'x'
var2        DW  0x4000
var3        DD  'taef'  ; = "feat" in bytes
        ENDS

            org	0x8000
sub1
			ld	a, (vars.var1)    ; direct access to var1 is similar to "vars+var1"
			ret
sub2
			ld	hl, (vars.var2)
			ret
sub3
			ld	ix, vars
			ld	c, (ix+S_VARS.var3)   ; just-offset still needs "S_VARS." prefix
			ld	b, (ix+S_VARS.var3+1)
			ret

vars    S_VARS  {,0x6000}  ; use default values to init except vars2 = 0x6000

so.. I can also understand the reluctance to edit old sources, as they were "correct", and that's a real pain for user.

But also I want to advance the assembler a bit and for contributor the view is quite different, some things which in ASM source may look almost identical (like this MAP vs STRUCT, i find the differences in these examples minimal), pose in the C++ source of sjasmplus quite some difference (MAP-field parsing+detection code was copied on three different places in the code, while STRUCT implementation is lot more self-contained and isolated from regular parsing = easier to understand/maintain/test).

... thinking about it, I probably miss some way to init some label as "struct" type, but yet not to emit the default values, just setting up address. Maybe something like `vars S_VARS = 0x1234` -> that would make `ld a,(vars.var1)` point to 0x1234 ... if I would add something like this, I really can't think of any further major MAP vs STRUCT difference (that "ix+S_VARS.var3" is for me like syntax sugar difference, and if you pick struct name and field name well, such syntax will still produce easy-to-read source line). (EDIT: with such feature the example with INCBIN above would be possible to write as `vars S_VARS = $ : INCBIN ...` and then `ld a,(vars.var1)` would be possible too)

So at this moment I have no plans to add MAP back, it really feels redundant to STRUCT, which can be used to produce identical machine code with very similar ASM source, but STRUCT has also extra features (struct nesting, default values) and in my (subjective) opinion STRUCT leads to better (easier to read) ASM source.

[krt17]

В том и дело что расположение полей будет хаотичным и не нужно следить где именно в коде они распологаются. Это некий аналог сегментов. Лично мне просто не понятно зачем удалать функционал, пусть и не используемый достаточно часто, но иногда нужный. Воспринимать MAP как аналог STRUCT, по моему, не совсем правильно.
В любом случае хозяин барин и для пользователей всегда есть выбор, весь вопрос лишь в совокупности необходимого функционала.

[Ped7g]

I think this is mostly matter of personal taste, what is "pretty source", so I will definitely keep your comment on mind as +1 for MAP return (in my personal view it is like on -3, so you are balancing it toward zero), thank you for the feedback, it's very important for me, because otherwise I'm in my own world only, not even aware of others.

(it's just low priority at this moment for *me*, because I can fix all your sources from MAP to STRUCT within few minutes if you will send me some "zip", while implementing MAP back into sjasmplus AND fixing any bugs in it, and creating tests to cover it = would take probably couple of hours ... but maybe one day, it's just SW, it can be amended any way any time, if there's time and will to do it)

I'm working on the designed address setup of struct, i.e. `vars S_VARS = $` will be possible (creating only labels vars.<field_label>, but not emitting bytes of the structure) ... that will be in github in few minutes (code and tests are done, need to add documentation).

Also maybe somebody can check how the MAP was resolved by macro in Mastermind's thread, maybe it works as 1:1 replacement and would work as compatibility-helper for old sources, although by thinking about 30s about it, I can't see how macros can catch # and ## in source? So it probably requires some small changes to source any way, and if you are editing old source, the modification to struct is very likely same effort).

(probably this one: https://zx-pk.ru/threads/447-sjasmpl...=1#post1002203 - that requires old source edits too, so I would rather consider just using STRUCT, but you can definitely do macros similar to this, even taking second argument with size of new field)

[NEO SPECTRUMAN]

А если я хочу запихнуть в defarray 16K значений
то что мне их запихивать в одну строку?

defarray the_array $0000,$0001,.. ...$3FFD,$3FFE,$3FFF

надо бы как то так

defarray the_array $0000,$0001... ...$000E,$000F
                   $0010,$0011... ...$001E,$001F
                   ...
                   $3FF0,$3FF1... ...$3FFE,$3FFF
edefarray

или хотя бы

defarray**** the_array $0000,$0001... ...$000E,$000F
defarray**** the_array $0010,$0011... ...$001E,$001F
                   ...
defarray**** the_array $3FF0,$3FF1... ...$3FFE,$3FFF
edefarray****

или так

defarray the_array $0000,$0001... ...$000E,$000F
addarray the_array $0010,$0011... ...$001E,$001F
                   ...
addarray the_array $3FF0,$3FF1... ...$3FFE,$3FFF

есть еще какието варианты как еще можно сделать подобное?
...


так же нужен fillarray <array_id> <from>, <to>, <value>

[Bedazzle]

А как правильно делать проверку на версию?
В документации

   IF _VERSION = "1.07"
     ;code for 1.07
   ELSE
     ;code for other version
   ENDIF

пробую распечатать при помощи

	display "version:", _VERSION

	IF _VERSION = "1.13.0"
		DEFINE X
	ENDIF

	IF _VERSION = "20190306.1"
		DEFINE Y
	ENDIF

получаю переполнение:

[NEO SPECTRUMAN]

такое тоже не работает

defarray fcknsht_tab /*
 */1,1,1,/*
 */0,0,0,/*
 */0,5,0

ничья ветка sjasm-a не взяла...
а жаль...

- - - Добавлено - - -

ld /*
but this won't be ld a,3!
*/ a,3

ТАК КАКОГО ХРЕНА ДОСИХ ПОР?

[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)