sdcc-user — Help and Discussion for SDCC users

[Sdcc-user] Current state of ELF output support for Z80?

[Atirut W. <ati...@gm...>]

It's been years since I've seen anyone last mention it other than me, and
GNU Binutils already has support for it. Being able to use actual linker
scripts and other Binutils tools would be a huge help. Even proper GAS
syntax emission would be nice.

Re: [Sdcc-user] Why are my string constants being redundantly duplicated?

[Philipp K. K. <pk...@sp...>]

Am 02.10.22 um 21:06 schrieb Alan Cox:
> On Sat, 1 Oct 2022 12:47:51 +0100
> Basil Hussain <ba...@st...> wrote:
>
>> I have come across a problem with SDCC for some reason including
>> constant string data twice inside compiled binaries.
>
> Move them out of the function and the problem goes away. It seems to be a
> bug but SDCC has behaved this way since forever.
>

I've opened a ticket: https://sourceforge.net/p/sdcc/feature-requests/933/

Philipp

Re: [Sdcc-user] Do we want --reserve-regs-iy variants of the standard library for z80-related ports

[Philipp K. K. <pk...@sp...>]

Am 24.06.24 um 13:24 schrieb Maarten Brock:
>
> Would it be very detrimental if the libraries were always compiled with
> --reserve-regs-iy ?
> After all, they are binary compatible.

I wouldn't want to take away the freedom to use iy from the compiler by
default. Especially for ez80_z80, z80n and tlcs90, where iy is even more
useful than for z80 and z180 due to more instructions being able to use it.

Philipp

Re: [Sdcc-user] Do we want --reserve-regs-iy variants of the standard library for z80-related ports

[Adrian C. <ad...@fr...>]

On Mon, 1 Jul 2024 at 08:56, Alan Cox <al...@ll...mru> wrote:

> On Mon, 24 Jun 2024 11:25:54 +0200
> Philipp Klaus Krause <pk...@sp...> wrote:
>
> > Dear users of the z80 and related ports,
> >
> > we currently do have the --reserve-regs-iy option to make sdcc generate
> > code that does not use the register pair iy. But we do not by default
> > ship with a standard library compiled with --reserve-regs-iy.
> >
> > How useful would it be for users of z80-related ports if SDCC would ship
> > such a library for some ports?
> > Would such a library be useful to you? If yes, for which port?
>
> I have no use for it. The platform I need to reserve registers on for NMI
> is the Sinclair ZX81 and it needs IX reserved and to an extent IY
> although that one can be dealt with unlike IX
>

Yeah, +1 it needs IY preserved on the ZX platform(s).

It's a confusing mess in Z88DK's use of this because Z88DK started with a
> hack that avoids using IY and turns IX into IY in the assembler so
> reserves IY but actually really reserves IX because it modifies all your
> assembler for you.
>
> I would guess the Z88DK register mangling mayhem for the ZX81 is the
> only general use case. There are a few CP/M BIOSes with bugs that corrupt
> IX or IY on some calls but those are handled by just pushing registers
> around CP/M BDOS calls and taking the precautionary position that enough
> CP/M BIOS writers are idiots to justify it.
>

.. and that also still surprises me, alas :-) (It may be time for CP/M 3.1,
which doesn't lie about Z80 only support :-)




-adrian

Re: [Sdcc-user] Do we want --reserve-regs-iy variants of the standard library for z80-related ports

[Alan C. <al...@ll...>]

On Mon, 24 Jun 2024 11:25:54 +0200
Philipp Klaus Krause <pk...@sp...> wrote:

> Dear users of the z80 and related ports,
> 
> we currently do have the --reserve-regs-iy option to make sdcc generate
> code that does not use the register pair iy. But we do not by default
> ship with a standard library compiled with --reserve-regs-iy.
> 
> How useful would it be for users of z80-related ports if SDCC would ship
> such a library for some ports?
> Would such a library be useful to you? If yes, for which port?

I have no use for it. The platform I need to reserve registers on for NMI
is the Sinclair ZX81 and it needs IX reserved and to an extent IY
although that one can be dealt with unlike IX

It's a confusing mess in Z88DK's use of this because Z88DK started with a
hack that avoids using IY and turns IX into IY in the assembler so
reserves IY but actually really reserves IX because it modifies all your
assembler for you.

I would guess the Z88DK register mangling mayhem for the ZX81 is the
only general use case. There are a few CP/M BIOSes with bugs that corrupt
IX or IY on some calls but those are handled by just pushing registers
around CP/M BDOS calls and taking the precautionary position that enough
CP/M BIOS writers are idiots to justify it.

Alan

Re: [Sdcc-user] SDCC generated functions being called from legacy assembly code

[Maarten B. <sou...@ds...>]

Forest Darling wrote on 2024-06-25 15:00:
> Hello all!
> 
> I am new to using SDCC, and I am working with some legacy 8051 codebase
> that is written in assembly. I would like to port one function at a 
> time
> from assembly to C, eventually converting the entire codebase while 
> testing
> it as I go. However, I need to be in control of how the C generated 
> code
> uses registers/RAM.
> 
> There are two main issues:
> 
>    1. make the C code implement "callee" saving of registers, so that 
> the
>    calling assembly code doesn't have to be rewritten

This is handled by the callee-saves pragma. See the manual. But beware 
that
this option is not regression tested. It may even disappear in the 
future.

>    2. make sure that the C functions do not clobber the existing global
>    internal RAM variables. I either need to reserve the known used 
> areas of
>    RAM (blacklist), explicitly define the RAM that is okay to use for 
> the
>    "overlay" section (whitelist), in my case using external RAM would 
> be
>    acceptable since the assembly doesn't use it except for external bus
>    peripherals. I could also forbid using global RAM altogether (like 
> the
>    reentrant option), but I think that might use too much stack...

Either black listing or white listing will be ok. It is not possible to 
let
the compiler use external RAM only. It will always need direct memory. 
But
by using --stack-auto you can severely limit it.

> I have tried Googling things, but I can't seem to find straightforward
> documentation on function attributes that might be useful. Any insight
> would be appreciated!
> 
> Thanks,
> 
> --Forest

Maarten

[Sdcc-user] SDCC generated functions being called from legacy assembly code

[Forest D. <fda...@gm...>]

Hello all!

I am new to using SDCC, and I am working with some legacy 8051 codebase
that is written in assembly. I would like to port one function at a time
from assembly to C, eventually converting the entire codebase while testing
it as I go. However, I need to be in control of how the C generated code
uses registers/RAM.

There are two main issues:

   1. make the C code implement "callee" saving of registers, so that the
   calling assembly code doesn't have to be rewritten
   2. make sure that the C functions do not clobber the existing global
   internal RAM variables. I either need to reserve the known used areas of
   RAM (blacklist), explicitly define the RAM that is okay to use for the
   "overlay" section (whitelist), in my case using external RAM would be
   acceptable since the assembly doesn't use it except for external bus
   peripherals. I could also forbid using global RAM altogether (like the
   reentrant option), but I think that might use too much stack...

I have tried Googling things, but I can't seem to find straightforward
documentation on function attributes that might be useful. Any insight
would be appreciated!

Thanks,

--Forest

Re: [Sdcc-user] Do we want --reserve-regs-iy variants of the standard library for z80-related ports

[Tony P. <un...@ma...>]

Hello Philipp,

Monday, June 24, 2024, 12:25:54 PM, you wrote:

Speaking about GBDK-2020 we only use __preserves_regs(iyh, iyl). 
Personally i see little sense in --reserve-regs-iy command line option 
and standard library compiled that way. Z80 codegen is not perfect 
enough to make generated code even worse. :)

PKK> we currently do have the --reserve-regs-iy option to make sdcc generate
PKK> code that does not use the register pair iy. But we do not by default
PKK> ship with a standard library compiled with --reserve-regs-iy.

PKK> How useful would it be for users of z80-related ports if SDCC would ship
PKK> such a library for some ports?
PKK> Would such a library be useful to you? If yes, for which port?


-- 
Best regards,
 Tony                            mailto:un...@ma...

Re: [Sdcc-user] Do we want --reserve-regs-iy variants of the standard library for z80-related ports

[Maarten B. <sou...@ds...>]

Philipp Klaus Krause schreef op 2024-06-24 11:25:
> Dear users of the z80 and related ports,
> 
> we currently do have the --reserve-regs-iy option to make sdcc generate
> code that does not use the register pair iy. But we do not by default
> ship with a standard library compiled with --reserve-regs-iy.
> 
> How useful would it be for users of z80-related ports if SDCC would 
> ship
> such a library for some ports?
> Would such a library be useful to you? If yes, for which port?
> 
> Philipp

Would it be very detrimental if the libraries were always compiled with 
--reserve-regs-iy ?
After all, they are binary compatible.

Maarten

[Sdcc-user] Do we want --reserve-regs-iy variants of the standard library for z80-related ports

[Philipp K. K. <pk...@sp...>]

Dear users of the z80 and related ports,

we currently do have the --reserve-regs-iy option to make sdcc generate
code that does not use the register pair iy. But we do not by default
ship with a standard library compiled with --reserve-regs-iy.

How useful would it be for users of z80-related ports if SDCC would ship
such a library for some ports?
Would such a library be useful to you? If yes, for which port?

Philipp

[Sdcc-user] SDCC 4.4.0 Release

[Philipp K. K. <pk...@sp...>]

The official release for SDCC 4.4.0 is available in our SourceForge
File release system:
https://sourceforge.net/projects/sdcc/files/

In addition to the source package, binaries are available for x86 
Windows, amd64 macOS, and amd64 GNU/Linux.

In addition to various bug fixes, notable features added since the
4.3.0 release are:

* Optimizations for rotations.
* struct / union parameters for hc08, s08 and mos6502.
* Many bug fixes for -ms08 --stack-auto.
* struct / union return support for hc08 and s08 (caller side only).
* Generalized constant propagation.
* New command line option --syntax-only to only parse the input.
* Added C99 header inttypes.h
* Added library functions imaxabs, imaxdiv, llabs, strtoimax, strtoll, 
strtoull, strtoumax, wcsncmp, wcstoimax, wcstol, wcstoll, wcstoul, 
wcstoull, wcstoumax
* New r800 port to better support the ASCII Corp R800 and Zilog Z280.
* Changed the default calling convention for r2k, r2ka, r3ka, tlcs90, 
ez80-z80 from version 0 to 1 (this is an ABI break, and will require 
changes to user-written asm functions or their declarations).
* Improved optimizations for code speed for stm8, pdk, z80 (and related).
* New mos65c02 port to better support the WDC 65C02.

A full list of changes can be found in the ChangeLog:
https://sourceforge.net/p/sdcc/code/HEAD/tree/tags/sdcc-4.4.0-/sdcc/ChangeLog

Philipp
(SDCC 4.4.0 release manager)

Re: [Sdcc-user] sdas8051 bug?

[Fritz M. <fr...@fr...>]

> On Jan 26, 2024, at 12:12 AM, Maarten Brock <sou...@ds...> wrote:
> Can you please file this as a bug in our Bug tracker on SourceForge?

Done (https://sourceforge.net/p/sdcc/bugs/3703/) — thanks!

      --FritzM.

Re: [Sdcc-user] sdas8051 bug?

[Maarten B. <sou...@ds...>]

Hello Fritz,

Can you please file this as a bug in our Bug tracker on SourceForge?
https://sourceforge.net/p/sdcc/bugs/

Thanks,
Maarten


Fritz Mueller schreef op 2024-01-25 23:13:
> Hi folks,
> 
> I’ve run into what I think might be a bug in sdas8051 as distributed
> with cdcc 4.3.0.  The following test code:
> 
>         .AREA   CODE1 (ABS)
>         .ORG    0x0000
>         JZ      0x0000
>         JB      0x00,0x0000
>         ACALL   0x0000
>         .ORG    0x8000
> L1:
>         LJMP    L1
> 
> ...produces:
> 
>     $ sdas8051 -l -o test.s
>     test.s:7: Error: <p> phase error: label location changing between
> passes 2 and 3
>     ?ASxxxx-Warning in line 8 of test.s
>                    large constant 0xff808000 truncated to 16 bits
>     removing test.rel
> 
> ...and the issue can also be seen in the .lst:
> 
>                                       1         .AREA   CODE1 (ABS)
>       000000                          2         .ORG    0x0000
>       000000 60 00            [24]    3         JZ      0x0000
>       000002 20 00 00         [24]    4         JB      0x00,0x0000
>       000005 00 00            [12]    5         ACALL   0x0000
>       FF808000                          6         .ORG    0x8000
> p     FF808000                          7 L1:
>       FF808000 02 80 00         [24]    8         LJMP    L1
> 
> Advice or workarounds appreciated?  I ran into this when trying to
> re-assemble some dumped ROMS from a DEC vt220; this is the simplest
> source sequence to which I seem able to reduce the issue.
> 
>         --FritzM.

[Sdcc-user] sdas8051 bug?

[Fritz M. <fr...@fr...>]

Hi folks,

I’ve run into what I think might be a bug in sdas8051 as distributed with cdcc 4.3.0.  The following test code:

        .AREA   CODE1 (ABS)
        .ORG    0x0000
        JZ      0x0000
        JB      0x00,0x0000
        ACALL   0x0000
        .ORG    0x8000
L1:
        LJMP    L1

...produces:

    $ sdas8051 -l -o test.s
    test.s:7: Error: <p> phase error: label location changing between passes 2 and 3
    ?ASxxxx-Warning in line 8 of test.s
                   large constant 0xff808000 truncated to 16 bits
    removing test.rel

...and the issue can also be seen in the .lst:

                                      1         .AREA   CODE1 (ABS)
      000000                          2         .ORG    0x0000
      000000 60 00            [24]    3         JZ      0x0000
      000002 20 00 00         [24]    4         JB      0x00,0x0000
      000005 00 00            [12]    5         ACALL   0x0000
      FF808000                          6         .ORG    0x8000
p     FF808000                          7 L1:
      FF808000 02 80 00         [24]    8         LJMP    L1

Advice or workarounds appreciated?  I ran into this when trying to re-assemble some dumped ROMS from a DEC vt220; this is the simplest source sequence to which I seem able to reduce the issue.

        --FritzM.

[Sdcc-user] SDCC 4.4.0 release candidate 3 available

[Philipp K. K. <pk...@sp...>]

The third release candidate (RC3) for SDCC 4.4.0 is available in our
SourceForge File release system:
https://sourceforge.net/projects/sdcc/files/

In addition to the source package, binaries are available for amd64 
Windows, amd64 macOS, and amd64 GNU/Linux.

If you have time, please verify it and report your positive or negative
results.

In addition to various bug fixes, notable features added since the
4.3.0 release are:

* Optimizations for rotations.
* struct / union parameters for hc08, s08 and mos6502.
* Many bug fixes for -ms08 --stack-auto.
* struct / union return support for hc08 and s08 (caller side only).
* Generalized constant propagation.
* New command line option --syntax-only to only parse the input.
* Added C99 header inttypes.h
* Added library functions imaxabs, imaxdiv, llabs, strtoimax, strtoll, 
strtoull, strtoumax, wcsncmp, wcstoimax, wcstol, wcstoll, wcstoul, 
wcstoull, wcstoumax
* New r800 port to better support the ASCII Corp R800 and Zilog Z280.
* Changed the default calling convention for r2k, r2ka, r3ka, tlcs90, 
ez80-z80 from version 0 to 1 (this is an ABI break, and will require 
changes to user-written asm functions or their declarations).
* Improved optimizations for code speed for stm8, pdk, z80 (and related).
* New mos65c02 port to better support the WDC 65C02.

A full list of changes can be found in the ChangeLog:
https://sourceforge.net/p/sdcc/code/HEAD/tree/tags/sdcc-4.4.0-rc3/sdcc/ChangeLog

The change from RC2 two RC3 are bugfixes for the s08 and r800 ports.

Philipp
(SDCC 4.4.0 release manager)

Re: [Sdcc-user] PDK calling convention

[Basil H. <ba...@st...>]

On 14/01/2024 14:40, Philipp Klaus Krause wrote:
> The adjustStack helper function in code generation uses add. It works 
> for both negative and nonnegative stack pointer adjutsments, no point 
> writing a version that uses sub.

Fair enough. Was just curious. :)

> Well, padding of unspecified value. Practially, it will often flag 
> bits, since push af tends an efficient efficient way to push a byte as 
> 16-bit value with unspecified upper byte. But this is not guaranteed, 
> and the callee shouldn't rely on it.

Oh, of course. I can't even imagine why anyone would want to look at 
flags previously saved on the stack. So yes, effectively padding, albeit 
of typically non-arbitrary value.

Hmm... what you said made me wonder if, given the flag register is 
writeable, whether you could actually use "push af" to store an 
arbitrary 16-bit value on the stack. But no, the top 4 bits of flag 
aren't writeable, and the docs say they always read as '1', so I presume 
any value in that register will be 0b1111xxxx when saved to the stack. 
An interesting thought experiment nonetheless.

Regards,
Basil Hussain

Re: [Sdcc-user] PDK calling convention

[Philipp K. K. <pk...@sp...>]

Am 13.01.24 um 19:42 schrieb Basil Hussain:
> By the way, one thing I have noticed about SDCC's PDK code generation is 
> that it seems to prefer "add"-ing a negative number rather than using 
> the "sub" instruction. Why is that? Do not all PDK instruction sets have 
> "sub"? I'm pretty certain they do.

The adjustStack helper function in code generation uses add. It works 
for both negative and nonnegative stack pointer adjutsments, no point 
writing a version that uses sub.

>> sp-3 point to the padding byte that we need to ensure that sp is 
>> always even, sp-4 points to the data byte of the argument.
> 
> Are you sure? Won't SP-3 be a copy of the flag register, not padding? 
> The push af instruction pushes two bytes: the a register and the flag 
> register.

Well, padding of unspecified value. Practially, it will often flag bits, 
since push af tends an efficient efficient way to push a byte as 16-bit 
value with unspecified upper byte. But this is not guaranteed, and the 
callee shouldn't rely on it.

>> You mean using that byte at adress 1 in some assembler code? That 
>> could work, but you'd have to reset it back to zero before it is used 
>> by any SDCC-generated code. So you'd have to disable interrupts before 
>> using the byte (and then reeenable them again after zeroing the byte).
> 
> Yes, precisely. I hadn't thought about interrupts attempting to use P, 
> thanks for that tip. So other than that, it's all good?

Yes, should be.

Philipp

Re: [Sdcc-user] PDK peephole rules - notUsed('a') seems to give bogus results

[Basil H. <ba...@st...>]

I downloaded and compiled the current 'next' branch to try out the 
modifications you made to notUsed().

I can report that SDCC is now successfully applying the rules in places 
I would expect. It's now applying in 6 places whereas before it was only 
2. There are still a couple of places in my code where it's not applied, 
but I believe it is justified in not doing so for those; when the 
peephole optimiser is following the code I believe it is running into 
inline assembly (a simple "wdreset"), which aborts the scan and causes 
notUsed() to return false.

It's a shame that SDCC does not natively generate code to use 
t1sn.io/t0sn.io for single-bit IO register tests, because I don't 
believe the peephole optimiser's behaviour in respect of inline assembly 
causing rules not to be applied can (or should) be changed, and yet in 
my code I need these snippets of inline assembly.

Is there any scope for changing the PDK code generation to use 
t1sn.io/t0sn.io?

Regards,
Basil Hussain

Re: [Sdcc-user] PDK calling convention

[Basil H. <ba...@st...>]

On 13/01/2024 16:30, Philipp Klaus Krause wrote:
> idxm a, M reads a byte from an adress; that address does not need to 
> be a word address. It is a byte address, and both even and odd 
> addresses work. However, that address itself needs to be located at a 
> word address (i.e. here p needs to be at an even address, which is 
> true, since p is always at address 0, but p might hold an odd value, 
> also the upper byte of that word (i.e. here the byte at address 1) 
> needs to be 0 for pdk13, pdk14 and pdk15).

Oh, I misunderstood about the word alignment. I did think it rather odd 
that the address pointed to needed to be word-aligned when only a single 
byte was being read.

> sp-1 and sp-2 point to the bytes of the return address for the current 
> function.

Of course, I forgot about the return address! That's why minus 4...

By the way, one thing I have noticed about SDCC's PDK code generation is 
that it seems to prefer "add"-ing a negative number rather than using 
the "sub" instruction. Why is that? Do not all PDK instruction sets have 
"sub"? I'm pretty certain they do.

> sp-3 point to the padding byte that we need to ensure that sp is 
> always even, sp-4 points to the data byte of the argument.

Are you sure? Won't SP-3 be a copy of the flag register, not padding? 
The push af instruction pushes two bytes: the a register and the flag 
register.

> You mean using that byte at adress 1 in some assembler code? That 
> could work, but you'd have to reset it back to zero before it is used 
> by any SDCC-generated code. So you'd have to disable interrupts before 
> using the byte (and then reeenable them again after zeroing the byte).

Yes, precisely. I hadn't thought about interrupts attempting to use P, 
thanks for that tip. So other than that, it's all good?

Regards,
Basil Hussain

Re: [Sdcc-user] PDK calling convention

[Philipp K. K. <pk...@sp...>]

Am 12.01.24 um 22:58 schrieb Basil Hussain:
> On 12/01/2024 19:27, Philipp Klaus Krause wrote:
>> Currently, the calling convention does not pass arguments in 
>> registers. They are either passed at those names you mentioned, or on 
>> the stack. The latter is done for __reentrant functions and when 
>> --stack-auto is used.
> 
> I am trying to understand the stack arguments scheme. I don't understand 
> what is going on with the assembly code SDCC generates when accessing a 
> single 8-bit argument on the stack:
> 
> mov.io    a, sp
> add    a, #0xfc
> mov    p, a
> idxm    a, p
> 
> What is the addition operation for? It's subtracting 4? Why? But if idxm 
> instruction needs a word address, why not divide by two (with a shift 
> right)?

idxm a, M reads a byte from an adress; that address does not need to be 
a word address. It is a byte address, and both even and odd addresses 
work. However, that address itself needs to be located at a word address 
(i.e. here p needs to be at an even address, which is true, since p is 
always at address 0, but p might hold an odd value, also the upper byte 
of that word (i.e. here the byte at address 1) needs to be 0 for pdk13, 
pdk14 and pdk15).

sp points to the unused byte just above the stack.

sp-1 and sp-2 point to the bytes of the return address for the current 
function.

sp-3 point to the padding byte that we need to ensure that sp is always 
even, sp-4 points to the data byte of the argument.

In more complex functions, there might be additional data (local 
variables) above the return address, so the return address and argument 
byte might be further from where sp points to.

> 
>> P is an 8-bit pseudoregister, and the byte following P is always 0x00.
> 
> Ah, I assumed P was 16-bits. Given that P is allocated two bytes 
> (presumably then only for reason of alignment of subsequent data), is it 
> okay to use the upper byte of P for arbitrary purposes, so long as that 
> byte is always reset back to zero afterwards?

You mean using that byte at adress 1 in some assembler code? That could 
work, but you'd have to reset it back to zero before it is used by any 
SDCC-generated code. So you'd have to disable interrupts before using 
the byte (and then reeenable them again after zeroing the byte).

Philipp

Re: [Sdcc-user] PDK calling convention

[Basil H. <ba...@st...>]

On 12/01/2024 19:27, Philipp Klaus Krause wrote:
> Currently, the calling convention does not pass arguments in 
> registers. They are either passed at those names you mentioned, or on 
> the stack. The latter is done for __reentrant functions and when 
> --stack-auto is used.

I am trying to understand the stack arguments scheme. I don't understand 
what is going on with the assembly code SDCC generates when accessing a 
single 8-bit argument on the stack:

mov.io    a, sp
add    a, #0xfc
mov    p, a
idxm    a, p

What is the addition operation for? It's subtracting 4? Why? But if idxm 
instruction needs a word address, why not divide by two (with a shift 
right)?

> P is an 8-bit pseudoregister, and the byte following P is always 0x00.

Ah, I assumed P was 16-bits. Given that P is allocated two bytes 
(presumably then only for reason of alignment of subsequent data), is it 
okay to use the upper byte of P for arbitrary purposes, so long as that 
byte is always reset back to zero afterwards?

Regards,
Basil Hussain

Re: [Sdcc-user] PDK calling convention

[Philipp K. K. <pk...@sp...>]

Am 12.01.24 um 19:39 schrieb Basil Hussain:
> Can I get some quick clarification/confirmation of the PDK calling 
> convention? It's not documented in the SDCC manual.
> 
> Arguments:
> - First/only 8-bit argument passed in A?
> - Multi-byte arguments are passed in overlay memory. To reference in 
> inline assembly, they are assigned names of "_<func_name>_PARM_<n>", 
> where n is the 1-based left-to-right argument index.

Currently, the calling convention does not pass arguments in registers. 
They are either passed at those names you mentioned, or on the stack. 
The latter is done for __reentrant functions and when --stack-auto is 
used. When arguments of that have an odd number n of bytes are passed on 
the stack, they are passed as n+1 bytes, with an unspecified value in 
the topmost byte.

> Return values:
> - 8-bit return values are in A.
> - 16-bit return value has MSB in P, LSB in A. (Why not just both in P?)
> - 32-bit return value - ???

struct, union and any return values larger than 16 bits are returned 
using an extra hidden pointer parameter, that points to the location, to 
which the result is written.
Otherwise: 8-bit values in A, 16-bit values in PA.
P is an 8-bit pseudoregister, and the byte following P is always 0x00.

> Both A and P are expected to be clobbered by the callee, and saved by 
> the caller?

Yes.

> Functions always return using 'ret' instruction? That is, no 'goto' 
> shenanigans?

Tail call optimization can use goto.

> Are there any differences between PDK13, 14, 15?

No.

Philipp

P.S.: The helper functions for pointer reads and writes are special, and 
do not need to adhere to this calling convention.

[Sdcc-user] PDK calling convention

[Basil H. <ba...@st...>]

Can I get some quick clarification/confirmation of the PDK calling 
convention? It's not documented in the SDCC manual.

Arguments:
- First/only 8-bit argument passed in A?
- Multi-byte arguments are passed in overlay memory. To reference in 
inline assembly, they are assigned names of "_<func_name>_PARM_<n>", 
where n is the 1-based left-to-right argument index.

Return values:
- 8-bit return values are in A.
- 16-bit return value has MSB in P, LSB in A. (Why not just both in P?)
- 32-bit return value - ???

Both A and P are expected to be clobbered by the callee, and saved by 
the caller?

Functions always return using 'ret' instruction? That is, no 'goto' 
shenanigans?

Are there any differences between PDK13, 14, 15?

Regards,
Basil Hussain

Re: [Sdcc-user] PDK peephole rules - notUsed('a') seems to give bogus results

[Basil H. <ba...@st...>]

Just as an addendum, I note that a feature request for peephole 
optimisations for the scenario I have been talking about already exists: 
#801 (https://sourceforge.net/p/sdcc/feature-requests/801/).

I see that the submitter also observes that notUsed('a') is "not handled 
well at most conditions", which, apart from other issues discussed 
within the ticket, hindered the proper application of the submitter's 
rules too.

Regards,
Basil Hussain

Re: [Sdcc-user] PDK peephole rules - notUsed('a') seems to give bogus results

[Basil H. <ba...@st...>]

On 11/01/2024 11:11, Philipp Klaus Krause wrote:
> I'll try to look into making notUsed work better for your use case. If 
> there is no corresponding commit to the next branch this week, I 
> suggest to open a feature request ticket, so this doesn't get forgotten.

Okay, thanks. I will do that.

Regards,
Basil Hussain