SjASMPlus от z00m

[Ped7g]

I guess you simplified the example, but so much, that it doesn't make sense to me.

The code will in 1.13.2 emit error:
"Issue_fwd_ref_in_macro.asm(13): warning: Label has different value in pass 3: previous value 10 not equal 9"
if label2 is 9 (put "org 8" ahead of "label1 nop" line). It's no error only when the condition is always false. If you know it's always false, you can just delete the macro. If it's true sometimes, it will produce error even in older versions (didn't check how many of them, but as the code is wrong, the error should be there).

The later versions just warn you about the problem sooner and more consistently.

The forward-references can be sometimes worked out in multi-pass assemblers, but you can still produce code which will never settle down, like:

  ORG 9
  IF label = 9
    nop
  ENDIF
label nop

This will in every odd pass get "false" in IF and set label to 9, and in every even pass then the IF is "true" and label becomes 10, this will never settle down, even in multi-pass assembler = this source can't be assembled.

So I don't understand what are you trying to achieve, but as sjasmplus is only 3-pass assembler, you should write source in a way to produce stable amount of machine code through all three passes (especially second pass must produce same amount of machine code as third pass, some changes after first pass may work, if you know what you are doing).

if those label1/label2 are more like config-constants affecting which parts of code are produced, define them ahead of the first macro usage.
if they are really labels inside the code and the IF block can move them, then you should rethink your code architecture to avoid the forward-reference, as it's not clear what is the correct output in such case (even to me, and of course not to assembler).

The small examples - as is - doesn't make sense, you can just delete the macros completely, they don't do anything useful. (I guess the true purpose was lost as you tried to make it small)

[NEO SPECTRUMAN]

I guess you simplified the example, but so much, that it doesn't make sense to me.

так и есть




вот настоящий макрос

тут используется для определения ошибок типа
mvi $FFFF
которые будут заменены на mvi $FFF при компиляции

	macro mvi ch8_xxx				;Axxx	MVI xxx
		if (ch8_xxx) > $FFF
		display $," error mvi > $FFF (",ch8_xx,")"
		endif
	   defb ($A0 + ($0F and (high (ch8_xx)))), (low (ch8_xx))
	endm

вот кусок реального кода
весь на подобных макросах с проверками "правильности"

              sne          v9,0x1                           ;
              ld           v4,0x1
              add          v9,v4                            ;
              drw          v0,v9,6
              add          v0,0x9                           ; адрес след знакоместа
              mvi          SPRITE_05
              drw          v0,va,6
              sne          va,0x14
              ld           v5,0xff





SPRITE_05  
              db           00111100b             ;			; 8
              db           11000011b             ;
              db           00111100b             ;
              db           11000011b             ;
              db           11000011b             ;
              db           00111100b             ;

потом сыпется куча ошибок
которые по сути не ошибки
(это было бы ошибкой на 3 проходе
на 1-м это еще не ошибка)


среди которых тяжело увидеть более важные "настоящие" ошибки

in older versions

в старых версиях SjASMPlus Z80 Cross-Assembler v1.07 RC7 (build 02-04-2008)

это тоже было

error: [IF] Forward reference



ну и проблему можно было бы решать
временным включением opt --msg=none
которого сейчас нет
да и в принципе хотелось бы иметь возможность
менять все параметры на ходу через opt
а не только одни
--nofakes, --syntax, --zxnext, --reversepop and --dirbol.

[Ped7g]

Hm, this is quite good example when the test is safe (not emitting any machine code bytes, so forward-reference is not a problem).

possible workarounds:
- define sprites earlier in the assembling, so the labels are known ahead
- or use ASSERT instead of IF + DISPLAY to report errors

	macro mvi ch8_xxx				;Axxx	MVI xxx
	   assert ch8_xxx <= $FFF
	   defb ($A0 + ($0F and (high (ch8_xx)))), (low (ch8_xx))
	endm

I don't think I can easily change `--msg` mode for small part of source, but I can probably suppress warnings/errors (i.e. making it more silent is possible, making it more vocal like switching on listing-mode would be probably impossible) ... so I will think about it a bit more, but I'm not a great fan of this solution at this moment.

I'm sort of more interested into making "forward-reference" error automatically silent, if there is no real damage (like your example of "DISPLAY" function), that would make all the conditional assembling more powerful and useful, I'm taking note about this.

Cheers.

[NEO SPECTRUMAN]

- define sprites earlier in the assembling, so the labels are known ahead

ну это легко может быть disasm-ом чужого кода
где результат должен с точностью совпадать

- or use ASSERT instead of IF + DISPLAY to report errors

но с if + display
можно написать в какой именно команде ошибка

а assert немногословен

sjchipasm.asm(1053): error: [ASSERT] Assertion failed: $FFFF <= $FFF
sjchipasm.asm(1714): ^ emitted from here


вот как сейчас

[Ped7g]

ну это легко может быть disasm-ом чужого кода
где результат должен с точностью совпадать

If you are using the virtual DEVICE memory, you can position the resulting gfx data with ORG (and after that use other ORG for code), so it is *possible* to move their definition ahead and get same binary output in the end (it's about assembling order, not about memory position).

I'm not claiming it's easy, or pretty, or that it is possible to do this with every project, but most of the time it's at least possible to use this kind of workaround. (edit: the whole point of "workaround" is, that you can use it *now*, while if I will fix anything in the sjasmplus, you must wait for my fix, and then if you don't compile sjasmplus from source, you need to wait for release, so I'm posting here possible workaround to give you at least not-nice solution for this moment, I don't want you to be stuck)

About display -> well, since v1.14.5 there is that "emitted from here" error, which brings you in editor directly on the macro invocation, like "mvi $FFFF"). Now the errors in macro produce two error lines, so I can easily switch in the editor between the lines. I guess you are using editor which doesn't parse the error output of sjasmplus, so you can't navigate through error list quickly? Then having display message would be probably better. But I would rather check how to parse the errors with your text editor, so you can use the list of errors. I could probably also show full line at the "emitted" error, but it felt to me like too much noise (for me the "display" errors are useless, as those are not parsed by the text editor, so I would definitely prefer ASSERT in my own code).

Anyway I still think relaxing the forward-reference errors a bit would be best in the end, making also your example work, but it would also support many other use-cases... The forward-reference can be a real problem, so I can't remove it completely, but making the check smarter to report only cases when some damage happens would be better.

[Ped7g]

ну это легко может быть disasm-ом чужого кода
где результат должен с точностью совпадать

So, I tried to implement smart detection of IF/IFN blocks which are unstable because of forward-reference, and I had to give up, it's too complicated in current sjasmplus architecture.

So instead I did change the error to warning, and you can suppress it explicitly with the "ok" comment at end of line, if you are sure you know what you are doing, i.e. in your example:

	macro mvi ch8_xxx				;Axxx	MVI xxx
		if (ch8_xxx) > $FFF  ; ok - forward reference warning suppressed
		display $," error mvi > $FFF (",ch8_xx,")"
		endif
	   defb ($A0 + ($0F and (high (ch8_xx)))), (low (ch8_xx))
	endm

So I'm delegating the responsibility to use the IF/IFN correctly to the programmer. After all, it's assembly, if the programmer wants to shoot himself into foot, the assembler should help to pick the biggest gun possible, not stop him...

Will be released in v1.15.0 (probably in a week or two) (and I will push it in few minutes to the github, if you want to build from sources the work-in-progress version).

[NEO SPECTRUMAN]

"ok"

может лучше
"ignore forward reference warning"
или
"warning skip"
"not error"
или что то в этом духе
такое уже нельзя будет вписать случайно
не зная что оно делает

"ok" может случайно оказаться обычным коментарием
и потом не выдать нужную ошибку

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

на случай если нельзя пробел
"errorless"

и такая функция
наверно была бы полезна
для многих других команд

[Ped7g]

the "ok" comment is already used by other warnings (low memory access, fake instruction, and something else) and I'm thinking about making it general mechanism for *all* warnings in v2.x
I will think about the choice of the word, but:
a) I don't expect that many accidental "ok" in comments of assembly source (you can search all your sources and tell me if you did find some?)
b) if you know about sjasmplus using it to suppress warnings, it's even less likely you will write it by accident

The longer words will eat more comments space, and warning-specific words will be difficult to remember (what to use to suppress the warning), so I did like "ok" for this, but I'm taking a note and will think about it more.

about searching your sources:
The regex for search can be like "(;|//)\s*ok", that may find few false positives like some string or full-line comment, but you could easily tell which is serious. I did run it over sjasmplus directory, and there are two lines "DB #FF ; OK" in BS-ROM bios source code, other "ok" comments were in tests, testing the warning suppression mechanism. Looks to me quite ok, I'm not worried about causing too much damage by this, but if few more people can search through their code base and report how many end-line comments with "ok" they have in old sources, it may change my mind.

[NEO SPECTRUMAN]

"ok" for this, but I'm taking a note and will think about it more.

например "ok" можно поставить возле отлаженной рабочей части когда
которую уже не нужно трогать

"ok" может быть что либо в самой программе

и может быть лекго поставлено в части кода
которое это "ОК" обрабатывает

есть вероятность что его напишут не зная что это отменяет ошибки


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

b) if you know about sjasmplus using it to suppress warnings, it's even less likely you will write it by accident

ну я только о нем узнал
инструкция для sjasmplus большая и часто обновляемая
для того чтобы ее хорошо знать всю

я часто туда заглядываю для дополнительных уточнений

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

вощем предлагаю подумать еще в пользу "errorless"
или другое слово
которое обозначает явную отмену или отсутствие ошибок

[zebest]

вот такайя строка

cad82   defb    'Input machine\'s name', 0

компилицца во всех приличных версиях sjasmplus без ошибок. Кроме этой ветки.
Что теперь не так в этой версии и что делать? (с)