I have been attempting to make a user defined library for an FPGA based TS2068 that has additional bells and whistles. It seems that the documentation for the assembler is out of date since the XLIB pseudo op has been removed in favour of PUBLIC. I found this by searching through the documentation file and it was in release notes The remaining instructions for compiling libraries also don't seem to match what the assembler/linker is expecting.
The old directives XLIB, LIB, XDEF, XREF are deprecated (/gone now?) and are replaced with PUBLIC, EXTERN (and GLOBAL).
PUBLIC means this label should be made visible outside the file (replacing XLIB and XDEF).
EXTERN means this label is defined outside the file someplace else (replacing LIB and XREF).
GLOBAL should not normally be used - it means if this label is defined in this file make it PUBLIC otherwise make it EXTERN. We needed this for sdcc which uses it extensively but its use can lead to silent linking errors. Stick to PUBLIC and EXTERN wherever possible.
In addition to these, SECTIONs were introduced (see a few paragraphs into
https://www.z88dk.org/wiki/doku.php?id= ... y_language ). You can continue to use z80asm as a plain assembler without sections but be aware that the c libraries are all sectioned now so if your code should be usable from the c compile line or with z88dk's crts, it should also be assigned to appropriate sections so that it gets included into the output binary. Sections are named containers into which assembled bytes are poured and at binary generation phase, the linker will sequence sections in memory according to a supplied memory map. Sections allow z88dk to generate ROMable code; an unnamed section or a section not known to the memory map may not be included in the output binary or may be appended to the binary rather than placed appropriately (eg in ram rather than rom).
If you're not sure which sections to place code and data into, safe sections are "code_user" (read only code), "rodata_user" (read only data), "smc_user" (self modifying code), "data_user" (non-zero data) and "bss_user" (initially zero data). There's also a "code_crt_init" section if you want to wedge in initialization code before main() is called (assign code there without a RET) or "code_crt_exit" for code executed after main returns but before files are closed (again no RET). In an all asm project, _main can be an assembly label indicating the asm program's start point.
First:
I want to have one file that handles printing to an ANSI style terminal that includes seven functions. The file is pretty small so I don't see the sense in separating out the various functions.
I have included PUBLIC declarations for each of the functions such as: PUBLIC term_selTerm
Ok, something like:
Code: Select all
SECTION code_user
PUBLIC _term_selTerm
_term_selTerm:
....
PUBLIC _foo
_foo:
.....
SECTION bss_user
someText: defm "hello world"
defb 0
The routines are small or interdependent so you want to link the whole file if any PUBLIC symbol is referenced.
I put a leading underscore on the names so that they can be made visible to the c compilers. With sccz80 you can give C items a special __LIB__ attribute which allows it to see names without leading underscores (this was used to make a kind of scope for system functions separate from user functions of the same name) but sdcc is unable to do this so we now do everything without __LIB__ and all names visible to C must have a leading underscore.
I am assembling with this command line: z80asm -d -xTsTxtAnsi @TsTxtAnsi.lst and am getting an obj file as expected. I copy the obj file and rename it as a .lib file in the libs/clibs directory.
When I attempt to use the function *term_selTerm*, the linker says that the .lib file is not a library file. I am not sure where to go from here.
z80asm may be assembling all the files listed in the .lst file to .o object files first and then generating the actual lib file TsTxtAnsi.lib out of the .o files. Have a look to see if the .lib file is also there.
.o and .lib are not the same thing - an object file is partially assembled, only waiting to have physical addresses patched when it becomes part of a binary. A library file is an indexed set of linking units, out of which the linker will pull individual units as needed by the current compile. So renaming is out.
If you get the .lib file you can use z80nm to have a look at what's inside. You can do the same for .o files
If you're not getting the .lib as output what comes to mind is when you performed your last update (See
https://github.com/z88dk/z88dk#installation to get a current nightly build or git clone). If it was recent and the problem still occurs are you able to share some source code so we can test directly?
I will mention that you can also build libraries using zcc with the advantage that zcc is able to swallow any sort of input like .c, .asm, .asm.m4, etc.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org!
http://sdm.link/slashdot