sdcc-user — Help and Discussion for SDCC users

[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

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

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

> Is notUsed() on PDK buggy, or am I missing something?

notUsed is not exact, it errs on the safe side if in doubt. This means 
that when notUsed first gets implemented for a port, it gets implemented 
"good enough" for the first few use-cases. Over time it can then be 
refined to become more accurate to allow for more optimizations.

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.

Philipp

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

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

Hi all,

I noticed that the PDK port is lacking a basic optimisation for 
conditional testing of single bits in IO registers (e.g. "if(PA & (1 << 
4))"), where it uses a sequence of "mov.io", "and", "ceqsn"/"cneqsn" 
instructions, when instead it could be using "t0sn.io"/"t1sn.io" 
instructions.

I am trying to implement a couple of peephole rules to do this, but they 
aren't being applied everywhere I would expect them to. It seems to be 
that the "notUsed('a')" condition I have is misbehaving and thinks the A 
reg is used when it isn't. If I omit the notUsed('a') but leave 
everything else the same, the rules apply everywhere I expect them to.

My rules are as follows:

replace restart {
     mov.io    a, %1
     and    a, #%3
     ceqsn    a, #0x00
     goto    %2
} by {
     t0sn.io    %1, #%4
     goto    %2
     ; peephole replaced IO reg single bit test-and-branch with 't0sn' 
(pdk13).
} if isPort('pdk13'), notUsed('a'), operandsLiteral(%3), immdInRange(0 7 
'singleSetBit' %3 8 %4)

replace restart {
     mov.io    a, %1
     and    a, #%3
     cneqsn    a, #0x00
     goto    %2
} by {
     t1sn.io    %1, #%4
     goto    %2
     ; peephole replaced IO reg single bit test-and-branch with 't1sn' 
(pdk14, pdk15).
} if isPort('pdk14' 'pdk15'), notUsed('a'), operandsLiteral(%3), 
immdInRange(0 7 'singleSetBit' %3 8 %4)

One example of a situation where the rules aren't being applied is:

void interrupt_handler(void) __interrupt(0) {
     if(INTRQ & INTRQ_T16) {
         timeout_expired = true;
         INTEN &= ~INTEN_T16;
         INTRQ &= ~INTRQ_T16;
     }
}

The assembly for that is:

_interrupt_handler:
     push    af
     mov    a, p
     push    af
     mov.io    a, __intrq
     and    a, #0x04
     ceqsn    a, #0x00
     goto    00111$
00112$:
     goto    00103$
00111$:
     mov    a, #0x01
     mov    _timeout_expired+0, a
     set0.io    __inten, #2
     set0.io    __intrq, #2
00103$:
     pop    af
     mov    p, a
     pop    af
     reti

You can see that for the lines following those that would match the 
first rule, no matter which branch is taken, the first use of A reg is 
to have something assigned to it - either "mov a, #0x01" or "pop af". 
The notUsed('a') condition should be returning true here.

Is notUsed() on PDK buggy, or am I missing something?

This is with RC2 of 4.4.0 (r14579) on Windows x64.

Regards,
Basil Hussain

[Sdcc-user] SDCC 4.4.0 release candidate 2 available

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

The second release candidate (RC2) 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-rc2/sdcc/ChangeLog

Philipp
(SDCC 4.4.0 release manager)

Re: [Sdcc-user] SDCC 4.4.0 release candidate 1 available

[Steve S. <ste...@gm...>]

Replying to myself for reference.

A simple svn switch svn://svn.code.sf.net/p/sdcc/code/tags/sdcc-4.4.0-rc1/sdcc/

>From within the top directory does the trick nicely.
Then the regular ./configure && make && make install

Thanks!
--
Steve Schnepp

On Fri, Dec 22, 2023 at 3:52 PM Steve Schnepp <ste...@gm...> wrote:
>
> How can I test it within SVN (without using the tarball) ?
> --
> Steve Schnepp
>
> On Thu, Dec 21, 2023 at 11:08 PM Philipp Klaus Krause <pk...@sp...> wrote:
> >
> > The first release candidate (RC1) 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-rc1/sdcc/ChangeLog
> >
> > Philipp
> > (SDCC 4.4.0 release manager)
> >
> >
> > _______________________________________________
> > Sdcc-user mailing list
> > Sdc...@li...
> > https://lists.sourceforge.net/lists/listinfo/sdcc-user

Re: [Sdcc-user] SDCC 4.4.0 release candidate 1 available

[Steve S. <ste...@gm...>]

How can I test it within SVN (without using the tarball) ?
--
Steve Schnepp

On Thu, Dec 21, 2023 at 11:08 PM Philipp Klaus Krause <pk...@sp...> wrote:
>
> The first release candidate (RC1) 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-rc1/sdcc/ChangeLog
>
> Philipp
> (SDCC 4.4.0 release manager)
>
>
> _______________________________________________
> Sdcc-user mailing list
> Sdc...@li...
> https://lists.sourceforge.net/lists/listinfo/sdcc-user

[Sdcc-user] SDCC 4.4.0 release candidate 1 available

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

The first release candidate (RC1) 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-rc1/sdcc/ChangeLog

Philipp
(SDCC 4.4.0 release manager)

[Sdcc-user] Which SDCC backends and devices supported them do you use?

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

I was wondering how many users the SDCC backends have, and for which
devices they are used, so I created a simple survey:

https://terminplaner4.dfn.de/EQgiMIYKQafCQLtr

If you would like to see support in SDCC for a device not yet supported
or if you use the mcs51 backend for a device that has support for dual
dptr, please state so (and which device it is) in a comment.

Philipp

P.S.: This is the second time I ask this question on this list. But it 
has been over 4 years, so I guess the situation might have changed since.

Re: [Sdcc-user] Merge _HOME and _CODE sections.

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

Am 08.10.23 um 21:39 schrieb Kamila Szewczyk:
> I am building a Z80 program for the TI-83+ calculator.
> If I force the C compiler to not optimise out some floating point
> operations to try them out, e.g. as such:
> 
>      volatile float a = 1.0;
>      volatile float b = 2.0;
>      volatile float c = a + b;
> 
> The generated code calls ___fsadd, which in turn is imported from one of
> the libraries supplied with SDCC for z80. However, the size of my binary
> explodes almost ten times, which happens due to the linker placing _CODE
> at 0x4000 (where it should go), while the ___fsadd function is placed at
> 0x8000, where the DATA area starts, as the linker command is:
> 
> sdcc -mz80 --no-std-crt0 --code-loc 0x4000 --code-size 0x4000 --xram-loc
> 0x9D95 --xram-size 0x6060 ...
> 
> Is there a way to merge _HOME and _CODE? I have noticed that I can force
> the compiler to move _HOME to a different memory location, but that
> would force me to set a fixed size for either _HOME or _CODE (and then
> never be warned if either overflows), which I don't want.
> 
> Yours,
> Kamila Szewczyk

The linker picks the order of segments in the order it first encounters 
them. So you can list your custom crt0 has first object to be linked, 
and have the linker get the order from there (like in the default crt0, 
which you can use as an example).

Philipp

[Sdcc-user] Merge _HOME and _CODE sections.

[Kamila S. <ksp...@gm...>]

I am building a Z80 program for the TI-83+ calculator.
If I force the C compiler to not optimise out some floating point
operations to try them out, e.g. as such:

    volatile float a = 1.0;
    volatile float b = 2.0;
    volatile float c = a + b;

The generated code calls ___fsadd, which in turn is imported from one of
the libraries supplied with SDCC for z80. However, the size of my binary
explodes almost ten times, which happens due to the linker placing _CODE
at 0x4000 (where it should go), while the ___fsadd function is placed at
0x8000, where the DATA area starts, as the linker command is:

sdcc -mz80 --no-std-crt0 --code-loc 0x4000 --code-size 0x4000 --xram-loc
0x9D95 --xram-size 0x6060 ...

Is there a way to merge _HOME and _CODE? I have noticed that I can force
the compiler to move _HOME to a different memory location, but that
would force me to set a fixed size for either _HOME or _CODE (and then
never be warned if either overflows), which I don't want.

Yours,
Kamila Szewczyk

Re: [Sdcc-user] differences in ELF and IHEX output

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

Maximilian Schneider schreef op 2023-09-02 16:06:
> While trying to create a custom IVT for a bootloader I noticed that
> the ELF and IHEX output differ when converted to binary.
> 
> example:
> 
> echo "int main() { }\n" > main.c
> sdcc -DF_CPU=16000000UL -mstm8 --std-sdcc11 -c main.c -o main.c.rel
> sdcc -DF_CPU=16000000UL -mstm8 --std-sdcc11 --out-fmt-elf main.c.rel -o 
> out.elf
> objcopy -I elf32-big -O binary out.elf out.elf.bin
> sdcc -DF_CPU=16000000UL -mstm8 --std-sdcc11 --out-fmt-ihx main.c.rel -o 
> out.ihx
> objcopy -I ihex -O binary out.ihx out.ihx.bin
> readelf -S out.elf
> hexdump -C out.elf.bin | head
> cat out.ihx | head
> hexdump -C out.ihx.bin | head
> 
> 
> The output is:
> 
> There are 9 section headers, starting at offset 0x214:
> 
> Section Headers:
>   [Nr] Name              Type            Addr     Off    Size   ES Flg 
> Lk Inf Al
>   [ 0]                   NULL            00000000 000000 000000 00      
> 0   0  0
>   [ 1] SSEG              PROGBITS        00000001 000034 000001 00   A  
> 0   0  0
>   [ 2] HOME              PROGBITS        00008000 000035 000007 00   A  
> 0   0  0
>   [ 3] GSINIT            PROGBITS        00008007 00003c 00001a 00   A  
> 0   0  0
>   [ 4] GSFINAL           PROGBITS        00008021 000056 000003 00   A  
> 0   0  0
>   [ 5] CODE              PROGBITS        00008024 000059 000001 00   A  
> 0   0  0
>   [ 6] .symtab           SYMTAB          00000000 00005a 000090 10      
> 7   1  0
>   [ 7] .strtab           STRTAB          00000000 0000ea 000051 00      
> 0   0  0
>   [ 8] .shstrtab         STRTAB          00000000 00013b 000039 00      
> 0   0  0
> Key to Flags:
>   W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
>   L (link order), O (extra OS processing required), G (group), T (TLS),
>   C (compressed), x (unknown), o (OS specific), E (exclude),
>   p (processor specific)
> hexdump -C out.elf.bin | head
> 00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  
> |................|
> *
> 00007ff0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 82  
> |................|
> 00008000  00 80 07 cc 80 24 ae 00  00 27 07 72 4f 00 00 5a  
> |.....$...'.rO..Z|
> 00008010  26 f9 ae 00 00 27 09 d6  80 23 d7 00 00 5a 26 f7  
> |&....'...#...Z&.|
> 00008020  cc 80 04 81                                       |....|
> 00008024
> cat out.ihx | head
> :048000008200800773
> :1D800700AE00002707724F00005A26F9AE00002709D68023D700005A26F7CC800451
> :03800400CC802409
> :0180240081DA
> :00000001FF
> hexdump -C out.ihx.bin | head
> 00000000  82 00 80 07 cc 80 24 ae  00 00 27 07 72 4f 00 00  
> |......$...'.rO..|
> 00000010  5a 26 f9 ae 00 00 27 09  d6 80 23 d7 00 00 5a 26  
> |Z&....'...#...Z&|
> 00000020  f7 cc 80 04 81                                    |.....|
> 00000025
> 
> The out.elf.bin has 0x7fff zeros prepended to the output and is not
> correctly aligned.
> 
> I could understand why it might have been 0x8000 but 0x7fff just seems 
> wrong.
> 
> Why do these outputs differ like this?
> 
> Best regards,
> 
> Maximilian Schneider

Hello Maximilian,

Unless someone responds soon that you are doing something wrong, can you 
please open a bug report about this?

Btw. You don't need to supply "-DF_CPU=16000000UL --std-sdcc11" when 
linking.

Maarten