SjASMPlus от z00m

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