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.
Ответить с цитированием