SjASMPlus от z00m

[NEO SPECTRUMAN]

трижды извиняюсь
нашел у себя багу

когда собирал несколько сорцов в один

один из них содержал

device zxspectrum48

в мало заметном месте

в итоге в какой то момент все компилировалось не так как надо
и сохраняло даже в 48к снапшоте...

[Advertiser]

[NEO SPECTRUMAN]

ну а английском могу вспомнить разве что
мануал по АТМ-у
http://alonecoder.nedopc.com/zx/books/ATMHW.rar

[Ped7g]

For those who know how to build from github, can you please try the current version in master branch?
https://github.com/z00m128/sjasmplus/commits/master

It's now what will become "v1.14.0" during next week, I think I'm done with the development (just want to edit docs and prepare everything for release).

And this is, as I wrote earlier, one of the last "v1.x" versions of sjasmplus, where I was trying to keep backward compatibility as high as possible.

So if you can test it with your Z80 projects and see if everything still works (or requires only very minor changes), I would love to hear from you (also of course if you run into some problem).

After this I'm planning to start work on "v2.x", which will change some of the syntax rules, and most of the old sources will require some small changes to be compilable with v2.x, so I want the v1.14.x to be very solid, stable and good assembler, because it may be the last version usable for some legacy sources (if you don't want to update them to new changes). Thank you girls and guys.

(preliminary changelog for v1.14.0 from my work notes)
- INCLUDE bugfix, now searching paths according to original documentation (may break some projects)
- UNDEFINE had undocumented feature of removing also labels, removed (seemed broken beyond repair)
- R800 MULUB was producing wrong opcode all those years... fixed.
- MODULE names can't contain dot any more, MODULE/ENDMODULE resets non-local label to "_"
- expression evaluator was not stricly 32 bit (64b binaries could have produced different results than 32b binaries)
- accessing low memory addresses 0..255 directly emits warning
- several tests added to improve the code coverage: https://coveralls.io/github/z00m128/...?branch=master
- as tests were added, minor bugs were found and squashed (errors wording, etc)

[Ped7g]

https://github.com/z00m128/sjasmplus...es/tag/v1.14.0

v1.14.0 changelog:
- INCLUDE bugfix, now searching paths according to original documentation (may break some projects)
- UNDEFINE had undocumented feature of removing also labels, cancelled (was broken beyond repair)
- R800 `MULUB` was producing wrong opcode all those years... fixed
- MODULE names can't contain dot any more! MODULE and ENDMODULE resets non-local label to "_"
- --syntax option: "m" (switch off low-mem access warning) and "M" added, "A" removed
- macro expansion can be inhibited by using "@" in front of instruction
- expression evaluator was not stricly 32 bit (64b binaries could have produced different results than 32b binaries)
- reading memory addresses 0..255 directly emits warning, use "; ok" comment to suppress it.
- several tests added to improve the code coverage: https://coveralls.io/github/z00m128/sjasmplus
- as tests were added, minor bugs were found and squashed (errors wording, etc)

Documentation http://z00m128.github.io/sjasmplus/documentation.html (or in the package/cloned source).

Last time I wrote there will be no 1.14, but some bugfixes did change the behaviour of the assembler a bit more than I wished (may even break some old projects, although unlikely or they can be fixed very easily), so I moved from 1.13.

But the idea is still the same, this is one of the last 1.x versions and there will be bugfix-only on 1.x in the future. And I'm going soon to start the "2.x" branch (which will probably start as 1.90.0, releasing changes feature by feature, so you will be able to follow the development all the time, the 2.0 will be released when the changes with regard to syntax and behaviour will be finished and stabilized).

If you have some project which did work with v1.10+ and is broken with v1.14, let me know about the issue. It may still require some changes on the project (it was not my goal to stay 100% backward compatible), but the changes should be very small and simple to do.

If you have some non-upgrade issues, or feature requests, feel free to ask here, or add feature request in github.

Thank you for your support everyone, have a great time.

[Ped7g]

https://github.com/z00m128/sjasmplus...es/tag/v1.14.1

... just small bugfixes/polish, documentation refresh, etc... nothing important, if v1.14.0 is working for you, the v1.14.1 should do the same.

If you did want to build sjasmplus from sources (or debug it), with MS Visual Studio, then upgrade to v1.14.1 for sure, there were serious bugs in older versions, making VS builds crashing on some features. Now it should work mostly identically to official exe (built with MinGW GCC8.2), except few minor differences in `--fullpath` handling, etc..

edit: I'm very interested into any bug reports or issues, as the plan is still to make this one of the last v1.x releases, so I hope it will be rock solid stable, and everyone who needs Z80 assembler can use this version for many years without running into some trivial bug or getting damaged machine code from correct ASM source.

Checking my TODO: there is one open issue when you would try to assemble STDIN and literally input source code manually from console, then it needs many many Ctrl+D presses to finish the assembling (should work well when you just redirect some output of previous command to sjasmplus), and otherwise I am not aware of any "bug", everything else is "feature" :P

[Sayman]

Вопрос: условия в макросах добавили или нет ещё?

[Ped7g]

Вопрос: условия в макросах добавили или нет ещё?

What do you mean precisely? The reasonably simple cases work for me, like:

; conditions_in_macro.asm
testCond    MACRO arg1?, arg2?, arg3?
                IF arg1?
                    DB  arg2?
                    IF !arg1?
                        never happens
                    ENDIF
                ELSE
                    DB  arg3?
                    IF $8004 <= $
                        DB  "..."
                    ELSE
                        jr  nc,.localLabelInCondition + '!'
                    ENDIF
.localLabelInCondition
                ENDIF

            ENDM
    
        DEVICE ZXSPECTRUM48 : ORG $8000
        OUTPUT "conditions_in_macro.bin"
        testCond 1, 'A', 'B'    ; A
        testCond 0, 'A', 'B'    ; B0!
        DB " "                  ; " "
        testCond 0, 'C', 'D'    ; D...
        OUTEND

The binary contains expected "AB0! D..."

Maybe if you would combine them also with DUP and emit macro inside macro which has conditionals, etc... I'm not claiming it's 100% bug free, but AFAIK it works.

If you have some example of something what doesn't produce correct result, just post it here or open issue on github, thank you.

-----------------------------------------------------------------

EDIT: one thing "obviously" (if you know how sjasmplus works, hehe) does NOT work, you can't only start/end conditional block in macro, i.e. the whole block must belong to the same macro.. i.e. things like:

MyEndIf MACRO
        ENDIF
    ENDM

    IF 1
        nop
    MyEndIf

will NOT work, and I don't have any plan to support them, not even in v2.x (I mean, they may happen by accident if I rewrite the parser in certain way and I was toying with that idea for a short while, but I don't find these important, actually opposite, seems like code smell).

edit2: unfortunately, similar logic does apply DUP/EDUP blocks and others, basically any block (dup-edup, if-endif, macro-endm) should be nested in other block fully, interleaving start/end of different types of blocks will in 99% not work... and that's something I'm thinking about for v2.x, to allow things like conditional EDUP, but it's very complicated, so rather do not expect this ever working. I'm also not completely convinced this is real limitation, so far I had never issues to organize my code around these rules, but as always, by posting real-world issue with real project helps tremendously to shift my bias...

[Ped7g]

slowly going toward 1.14.2 release... so far the changelog looks like this:

- added i8080 mode (--i8080 CLI option) (it's still Z80 Zilog syntax, just limited instruction set)
- small improvements/polish/extra-info in docs, INSTALL, README, few new tests added
- cmake script fix of SYSTEM_LUA=ON option, CirrusCI configs added for macOS and FreeBSD
- few fixes of memory leaks, invalid memory access, double free/delete, ...

Basically nothing important for ZX coder, no bugs affecting code were found in 1.14.1, so no fixes. Sayman also didn't respond, so I guess everything works well for him... (the code is now really well covered with tests, so I don't expect too many new bugs to be found, maybe in the parts which are not covered well like TRD and HOB functions, but I don't know anyone using those and I'm not familiar enough with those formats to write tests by myself, so if somebody is bored enough, sending me test similar to TAP/NEX may help to cover it more)

I think the release will be done in couple of weeks or a month, something like that (unless there will be some unexpected activity worth a delay).

[NEO SPECTRUMAN]

- added i8080 mode (--i8080 CLI option) (it's still Z80 Zilog syntax, just limited instruction set)

ура
теперь будет проще адаптировать свои поделки к 8080
если ВНЕЗАПНО появиться такое желание

еще не тестировал
но по хорошему наверно надо чтоб
компиляция продолжалась до конца
и чтоб на z80, при этом, код был рабочим
но чтоб выкидывало ошибки
и номера строк где лежат z80 only команды

или же нужно 2 варианта режима i8080
при одном только предупреждения
а при втором уже пропуск z80 команд которых нет

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

Ped7g, а поддержка православного Sharp LR35902 случаем не планируется?

[Ped7g]

Ped7g, а поддержка православного Sharp LR35902 случаем не планируется?

The i8080 mode: it's actually still the same Z80 sjasmplus under, just not adding Z80 instructions into the string map at init (instructions like `rr` = "not recognized"), limiting registers (`ld i,a` is "illegal instruction", `ld a,i` will emit machine code of `ld a,0` with "label i not found"), and few more checks narrowing possible opcodes (`in a,(c)` = `in a,(N)` with "label c not found", etc..).

All of these types of errors are non-fatal, i.e. compilation will continue (machine code is usually not emitted for them, although if they can be interpreted as legit i8080 instruction with just missing symbol/label (i, r, ix, iy, c, ...), those get evaluated as zero immediate value and machine code with this zero value is emitted).

Check the listing files in `tests/i8080` for examples how the assembler is behaving and what/how errors are reported:
https://github.com/z00m128/sjasmplus...er/tests/i8080

(you can still help to improve it with feedback, if you think something of that is really wrong and you have idea how to improve it ... I'm quite OK with the current status, if I imagine I have Z80 asm file I want to make i8080 compatible, the current state would give me enough info and errors to know what to change ... plus I don't want to spend too much time on this, for me i8080 is minimal priority, it got added because it was minimal work and with the tests in place I'm not too afraid to break the Z80/Z80N parts ... also the z80.cpp after heavy refactoring is not that difficult to modify for this i8080 support).

About LR35902 - that's a bit more difficult, as it is not only limiting Z80, but changing some small parts of it. I will take a look and try to asses the difficulty... As mentioned above, due to test coverage I'm not afraid to break Z80, so I can give it some try. But then again, sjasmplus is strongly Z80 oriented with pretty much everything hard-coded, so it may turn out to be clashing too much with current implementation, not worth the effort.

Also the i8080 was reviewed by M.Borik and Busy, who are very familiar with it, they are doing lot of work lately on the PMD-85 computer (old Czechoslovakia 8bit from the ZX era, based on i8080), having fun there.

Do you know somebody being very familiar of LR35902, like doing GameBoy games, etc, who would be able to review the sjasmplus after such change, and asses it's usability, suggest improvements, etc?

(I was doing myself GameBoy Advance games, that was already ARMv6 CPU, so I'm unfortunately not familiar with this Z80 variant)

- - - Updated - - -

Did check the differences... seems doable.. not sure about syntax of some specials (should `ld a,($FFxx)` be automagically assembled as `ldh a,($xx)` ?? I think *yes* .... but `ld a,(hl+)` would end as `ldi a,(hl)` probably, just like the same fake instruction in current sjasmplus, not supporting the "hl+" syntax? Is it "good enough"?)

And I definitely need some "guarantor", who would check all opcodes and encodings after me, as by a quick search with google I already run into few technical references which slightly disagree between themselves or there's some info missing. Also seems there're subtle differences between GB, GBP and GBC, although I guess the machine code is identical, just the HW reacts a bit differently to some instructions ("STOP 0" seems to be rather "STOP $nn" and gets extra functionality in GBC, if I'm reading it correctly)???

So, if you know about somebody deeply familiar with the GB/GBP/GBC intricacies, who's willing to "sponsor" the sjasmplus (by making thorough review of the test+listing files, and also by commenting on the proposed syntax, plus recommendations about usability, if something like OUTPUT / SAVEBIN is enough, or there's some common format which would be very helpful, etc.. i.e. what is common in other assemblers and people would really miss that if I do just crude sjasmplus conversion like i8080 is). ... This may be about 8-40h effort. If you can find somebody willing to do this, I can add the LR35902 mode too.