SjASMPlus от z00m

Цитата:

---

Сообщение от Sayman

а если набор таких функций и процедур несколько десятков? сидеть и пилить в основном коде серию дефайнов? что-то забыл задефайнить и код не рабочий или не собирается - сиди потом разгребай, ищи, тестируй. А библиотека это всё решает.

---

что забыл задефайнить?
приведи пример
что может не работать?

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

Цитата:

---

Сообщение от Sayman

Кроме того, когда в исходнике будет сотня всяких ифов, то читаемость такого исходника падает.

---

какие ифы?

все ифы в библиотеке
с cорцe только call procedure
а в инклуженной библиотеке
при использовании procedure
создается метка procedure и комплилится код

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

Цитата:

---

Сообщение от Sayman

включая прочие зависимости. всё что не нужно, останется в файле, а не в собираемом бинаре.

---

ну если зависимости между 2+ библеотеками
то тогда придется крепить к сорцу каждую библиотеку самому
или же будет как раз куча костылей
по самоинклуживанию
что не вариант

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

Цитата:

---

Сообщение от Sayman

твой любимый Core I.

---

нету у меня такого
терпеть ненавижу єту линейку процов

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

Цитата:

---

Сообщение от Sayman

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

---

да вижу эти преимущества
чтоб скомпилить чужой сорец
тебе надо выкачать пол интернетов библиотек определенных версий
и плясать с бубном чтоб что то собрать...
тк сорец идет без ничего

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

а щас можно ложить сджасм в комплекте с сорцом
и все собирается из коробки в 1 клик

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

Цитата:

---

Сообщение от Sayman

и ничуть не тупит при компиляции тяжёлых файлов. а ты переживаешь, что ужасм поставит на колени твой любимый Core I.

---

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

Цитата:

---

Сообщение от NEO SPECTRUMAN

нету у меня такого
терпеть ненавижу єту линейку процов

---

ну значит amd fx/amd ryzen, не суть важно.

Цитата:

---

Сообщение от NEO SPECTRUMAN

все ифы в библиотеке

---

в какой библиотеке? то, о чём ты говоришь не библиотека, а просто исходник, который ты инклудишь. опять таки - пачка ифов портит читаемость.
я твой посыл понял, тебе это удобно, а мне было бы удобно иметь объектный файл. никаких ифов и прочей фигни. и исходники чистые, особенно если эта библиотека собирается не из одного мегаисходника, а их серии мелких. это ещё один недостаток твоего метода - всё нужно засовывать в один большой файл или делать с десяток инклудов.
хочется примеров? да пожалуйста. я вот под трдос не делаю что-либо, а кодю под спринтера. всякие fopen, fread, fwrite, всякие page_alloc, функции печати аля printf (да да, есть и такая, как для си, только писанная на асме без поддержки float). порядка 40 системных вызовов завернул бы в одну либу. а сейчас это всё в одном мегаисходнике. аж воротит туда заглядывать. вот пилю щас новый fdisk и такая либа была бы очень кстати.

Цитата:

---

Сообщение от NEO SPECTRUMAN

и чем это отличается от ifused?

---

В библиотеке может быть 10 процедур, при вызове одной только она и возьмется, в этом и есть отличие

Цитата:

---

Сообщение от Sayman

в какой библиотеке? то, о чём ты говоришь не библиотека, а просто исходник, который ты инклудишь. опять таки - пачка ифов портит читаемость.

---

как они портят читаемость?

они несколко портят читаемость лог-а\готового листинга

в основном исходнике же
только только call
и 1 инклуд 1 библиотеки

Цитата:

---

Сообщение от Sayman

а кодю под спринтера. всякие fopen

---

а как процедуре должны передаваться параметры?

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

Цитата:

---

Сообщение от Vadim

В библиотеке может быть 10 процедур, при вызове одной только она и возьмется, в этом и есть отличие

---

та глянь пример
при вызове одно процедуры
ТОЛЬКО ОДНА ПРОЦЕДУРА И СОБЕРЕТСЯ ЖЕ!!!!!!!!1

Цитата:

---

Сообщение от NEO SPECTRUMAN

45 8012 ifused dup1 46 8012~ dup1 47 8012~ dup 5 48 8012~ ld c,c 49 8012~ ret 50 8012~ edup 51 8012 endif

---

вот те цитата
dup1 не вызывался
и не попал в сорец



вот с параметрами для процедуры
могут быть проблемы
это я не учел

если вы их хотите передавать в виде
procedure 444,444,44
это нужно городить макросы с костылями
и тут тогда я не совсем прав

Цитата:

---

Сообщение от NEO SPECTRUMAN

как они портят читаемость?

---

тем, что все библиотечные процедуры и функции сидят в одном мегаисходнике, который потом инклудится. если дробить на мелкие файлы, то в основном исходнике уже не 1 инклуд, а пачка, что тоже не удобно.

Цитата:

---

а как процедуре должны передаваться параметры?

---

не понял вопроса. какой процедуре? в библиотеке? точно так же как и всегда - хоть через регистры, хоть через буфера, хоть через стэк. как сам напишешь.

макрос это макрос. у ужасма макросы параметрические, как и у всех асм компиляторов, даже у старого М80.

Цитата:

---

Сообщение от Sayman

тем, что все библиотечные процедуры и функции сидят в одном мегаисходнике, который потом инклудится. если дробить на мелкие файлы, то в основном исходнике уже не 1 инклуд, а пачка, что тоже не удобно.

---

а что тогда из себя представляет библиотека в твоем понимании?

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

Цитата:

---

Сообщение от Sayman

не понял вопроса. какой процедуре? в библиотеке? точно так же как и всегда - хоть через регистры, хоть через буфера, хоть через стэк. как сам напишешь.

---

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

ld a,parameter
call procedure

?

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

а так ты ужо столько настрочил

мог бы 100 раз привести строчек 10 псевдокода
чтоб донести идею

Цитата:

---

Сообщение от NEO SPECTRUMAN

или параметры хочешь ложить при помощи обычных инструкций перед вызовом

ld a,parameter
call procedure

?

---

именно так. иначе это уже си какой то. хотя если будет дериктива procedure для обозначения процедуры/функции, то не откажусь.

Цитата:

---

Сообщение от NEO SPECTRUMAN

а что тогда из себя представляет библиотека в твоем понимании?

---

может я ранее как-то не верно сформулировал, попробую сейчас пояснить, "перефразируюсь"...
вот смотри - есть часто прикручиваемые к разным прогам функции и процедуры. открыть файл, прочитать файл, записать файл, запрос памяти у доса, вернуть досу память, печать текста (простая печать и более сложная функция printf выдернутая из си и адаптированная под свои нужды), мат.функции, вроде 8/16/32 бита умножение и деление и другие. лично мне содержать в одном большом файле это всё не удобно. да. 1 инклуд, я знаю, но в случае правки кода в этой "библиотеке", перемещаться становится там всё сложнее. плюс гора этих ифов. я бы разбил это всё на мелкие исходнички, которые потом скомпилировал бы в одну статичную либу/объектный файл/rel файл. при сборке основного кода в качестве доп.аргумента указал бы имя этой либы. каждая вызываемая процедура/функция подключалась бы к процессу компиляции. при этом, к примеру, на си когда компилишь, то порядок перечисления исходников. объектов и библиотек будет соблюдаться и при линковке кода из этих объектов и библиотек. но у нас ужасм, значит можно было бы добавить директиву, по которой можно было бы указать место размещения кода из библиотеки. может даже указать внутри основного кода имя этой библиотеки. это было бы равносильно инклуду с той разницей, что нет нужны ковыряться в большом мегаисходнике-библиотеке или инклудить с десяток мелких.
надеюсь так понятнее будет, если не запутал...

как вариант

сорец
ld a,66
call procedure1
call procedure3
call procedure1

include "libs.asm"



libs.asm
display "version"
include "libs\a1.asm"
include "libs\a2.asm"
include "libs\a3.asm"
include "libs\a4.asm"
include "libs\a5.asm"

a1.asm
ifused procedure1
procedure1
rra
ret
endif


либасм и папку подкидывать в каждый нужный сорец


include "libs.asm"
можно вообще наверно сослаться на
include "с:\фигзнаетчточтониукогон� �т\libs.asm"
и использовать одну библиотеку для всего
но после єтого тебя будут вспоминать...

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

Цитата:

---

Сообщение от Sayman

надеюсь так понятнее будет, если не запутал...

---

нутак

а как происходит вызов функций из сорца?
сомневаюсь можно ли их чем то заменить

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

Цитата:

---

Сообщение от Sayman

которые потом скомпилировал бы в одну статичную либу/объектный файл/rel файл. при сборке основного кода в качестве доп.аргумента указал бы имя этой либы. каждая вызываемая процедура/функция подключалась бы к процессу компиляции.

---

но а потом получить читаемый сорец будет проще из дизасма
чем из твоего исходника
пушо будет упоминание левых процедур
а самих процедур не будет

мало того тут асм а на си
используются реги проца
некоторые постоянно
некоторые весь фрейм висят ждут пока из них прочитают

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

как ты будешь отлавливать что затерло?
ты не сможешь быстро перейти в код библиотеки и пофиксить
хотя как всегда
оно будет работать годами что то затирая и не вызывая подозрений
а потом в один день наступят грабли

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

если не пушить их в самой процедуре библиотеки
то будут грабли с затиранием чем то чего то нужного
неизвестно когда


тут не си
регистры общие для всего


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

как эту всю байду оптимизировать?


а потом дизасмишь игры
а там часто такое...
call l1
l1 jp l4
l4 jp l7
l7 ld a,b
jp l44
l44 ret

I will try to be very brief (as I'm busy and my "brief" posts tend to be 3 pages long, while "non-brief" would aspire for a book chapter).

sjasmplus does assemble directly into machine code. There is no support for object file currently. If you want support for some specific object file, create issue on github with documentation about the object file format... but it better should be mostly as-machine-code with just some meta data added on top of it, otherwise it would need another assembler inside the assembler = I don't think somebody will find time to do that.

For my personal projects (and for all SW I use) I strongly prefer sources, "libraries" like libSomething-dev.deb are convenient to install (I can turn fresh linux installation into developer's machine in ~5 minutes, having all compilers and stuff installed), but sooner or later one always needs also sources to fix or modify something, or just verify how the author did implement it. I mean, I don't build from sources everything I use, but I always make sure I can obtain source of everything I use (and if the source is not available, I usually go great lengths to find alternative or write my own).

With assembly programming it's even worse, almost always I need to slightly adjust particular code per-project, there's rarely something I just copy/paste without any modification, so having "libraries" in sources works nicely for me (in assembly especially).

Aside my personal preferences, there are these tools available:

** Way of "include source":

`INCLUDE` to include source files, you can set include paths on command line, if you want to keep all utility sources at one place outside of project (by using quotes/angle-brackets around file name you can specify if the sjasmplus should search first system includes, or current source directory). (and if you will use the "IFUSED" in the library source, only the used subroutines will emit machine code)
(this also makes it easier to relocate Z80 machine code, because Z80 CPU doesn't provide good support for "position independent code", so relocating binary without source is usually big pain).

These source lines are of course visible in listing file, and in labels table.

About listing file: in upcoming sjasmplus (v1.13.2+) there will be new option to suppress listing file temporarily, so you can use that to make library "invisible" in listing.

About labels table: the sjasmplus does support "MODULES" (for a long time), so you can use particular module namespace for your library to avoid accidental collisions with labels used by your project code. These will be still visible in listing of all labels (you can delete module labels quickly in any text editor by search+replace, if that would become a real problem)

** Way of "include binaries":

You can also create "export" file - in library source use `EXPORT function_name` to put the symbol into export file, then at command line while assembling use `--exp=export_file_name.asm` to store these symbols in small ASM source file. You can then include this export list in project source, and use symbols to call the library code. And you can use INCBIN to include the library code itself or load it separately from code (listing and labels table will show only the exported symbols).

------

I have very difficult time to imagine real world ZX Spectrum project written in ASM which would be too large to manage in the "source" way above, so I never thought too much about the "binary" way. From a quick glance it seems viable too (although I would expect it to be more cumbersome and not as powerful as tailoring sources to specific needs of particular project).

If you have on mind some large project, where maintaining sources would be too difficult, you can also check other projects like z88dk compiler suite (contains two C compilers for Z80, assembler and linker).

I personally have no plans to extend sjasmplus so much, that it would compete with these (and I'm not aware of anyone else willing to contribute toward this goal at this moment).

Actually the small-size and self-containment of sjasmplus is something what I **like**. If you want just to try some small Z80 assembly on ZX Spectrum, like some short piece of code from book, sjasmplus should be simple to download, and use even by somebody new to the assembly programming (and if it is not, let me know what is problematic, so we can improve it).

Yet I believe it is very powerful tool (already in current version, and I have some plans how to extend it even a bit more), with most of the bugs fixed and quality assured, I have no hesitation to recommend current v1.13.1 even for "production-quality" large projects.

But if you are used to other tools, you should invest some time into reading through documentation and checking out the accompanying "examples" and "tests" folders, to get more familiar with sjasmplus options and features.

Цитата:

---

Сообщение от NEO SPECTRUMAN

а потом дизасмишь игры
а там часто такое...
call l1
l1 jp l4
l4 jp l7
l7 ld a,b
jp l44
l44 ret

---

You know, so you decide to optimize it, replace `call l1` with `ld a,b` and suddenly the game stops to work correctly, because the new timing will uncover some bug somewhere else which didn't show up with the slower code before... :P ... I know you all, you will not trick me so easily ... this time... :D (/joke)