The pic ports use gputils (both the ports and gputils are currently unmaintained)
Other ports use sdas (by default), which is a fork of an older asxxxx, then released under a GPL-compatible license. Later asxxxx changed to a GPL-incompatible license, and sdas and asxxxx started diverging. When asxxxx switched to GPL, the differences were substantial enough to make a merge non-trivial. Today, e.g. both sdas and asxxxx have independently-developed stm8 ports.
Some ports (z80 and related) have some limited support for using other assemblers.
The sdas situation is far from optimal. Possible ways forward include:
Merge current asxxxx into sdas
Switch to GNU binutils. However, GNU binutils does not support all SDCC targets. This might still be an option for some ports. It would also make it easier to get the link-time dead code elimination¹ requested by many users.
¹ Apparently some users put unused functions into their source files, and expect the linker to optimize them out (they also don't want to use .lib libraries, for which sdas can do it already).
This is a list of the current state, extensions, differences with 5.40 and progress:
Assemblers missing in upstream:
Assemblers being close to upstream state:
asrab:
.r4k
(Rabbit 4000 support)asz80:
.zxn
(ZX Spectrum Next), .ez80
(Zilog eZ80).8080
(Intel 8080), .8085
(Intel 8085), .8085x
(extended instructions)ASxxxx core: (incomplete)
.optsdcc
.bank
and .end
directivesASLINK: (incomplete)
O
Upstreaming progress:
Tips:
--no-optsdcc-in-asm
to be able to assemble with upstream ASxxxxmake -C asxmak/linux/build/
(read readme.txt)assembler=as6500; diff -d -B -w --suppress-blank-empty ~/projects/sdcc-code/sdcc/sdas/${assembler} ~/projects/asxxxx/${assembler} | less
can be used for listing the differences
Wiki: Home
Wiki: SDCC 4.3.0 Release
Wiki: SDCC 4.4.0 Release
Wiki: SDCC 4.5.0 Release
The current sdasz80 is lacking of undocumented z80 instructions due to a bug. More in general its z80 mnemonics do not respect the common conventions used by Zilog and by other assemblers. This is a problem when I try to include my existing ASM code (audio players, math libraries, graphic libraries) in the SDCC projects.
Maybe replacing sdasz80 with something more advanced and standard could make easier the integration of the existing code base in the SDCC projects.
Last edit: Ragozini Arturo 2022-03-15
It is indeed relevant for “possible ways forward include”
-mz80
claims to supportz80asm
andgas
, but that would be obviously be without built-in peep hole rules.Switching to a completely different assembler might require splitting z80/z180/z80n/ez80 from rabbit/sm83/tlcs90. Definitely for peep hole rules. (They currently share general rules)
More should be discussed in [feature-requests:#791]
Related
Feature Requests:
#791