sdcc-devel — Development chatter about SDCC

Re: [sdcc-devel] 6502 calling convention

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

Hi,

The general rule is: Write some dummy C code and look at the generated
assembly.

Maarten

Gabriele Gorla via sdcc-devel schreef op 2023-11-29 10:40:
> Hello,
> The default behavior on the 6502 (like on the 8051) is to generate
> non-reentrant functions. Function arguments past the first two bytes
> and local variables are placed in an overlay area in general RAM.
> Only the return address ends up on the stack.
> Return value goes in AX and then in the pseudo return register in ZP
> (___SDCC_m6502_retX)
> 
> If the function is declared reentrant (or is variadic) then all
> arguments past the first two bytes end up in the stack.
> The caller cleans up the stack. The return value follow the 
> non-reentrant rule.
> Local variables are also on the stack.
> 
> I don't think Y is preserved across function calls.
> 
> 
> thanks,
> GG
> 
> 
> 
> On Tuesday, November 28, 2023 at 01:29:59 PM PST, Sam Wilson
> <sam...@gm...> wrote:
> 
> 
> 
> 
> 
> Good evening,
> 
> I am looking for information on the calling convention that SDCC uses
> for the 6502. There is a little bit of information in
> sdcc/src/mos6502/main.c, but I'm left wondering,
> 
> * who (caller or callee) is responsible for popping the arguments back
> off the stack?
> * I assume the return address goes on the top of stack after all
> arguments (i.e. have the lowest address in memory), so that a `rts`
> would return from the function
> * If the function returns a value, where does it go
> * Which memory locations, if any, are for local use
> * who (caller or callee) saves Y, if at all?
> 
> I found that the Z80 calling conventions have precise descriptions
> knocking about on the internet. But for the 6502 I'm not sure. If
> there is any documentation on such matters for the 6502, I would be
> interested to see that. In particular, is the calling convention
> compatible with what other compilers like cc65 or gcc6502 do?
> 
> Best regards,
> 
> _______________________________________________
> sdcc-devel mailing list
> sdc...@li...
> https://lists.sourceforge.net/lists/listinfo/sdcc-devel
> 
> 
> _______________________________________________
> sdcc-devel mailing list
> sdc...@li...
> https://lists.sourceforge.net/lists/listinfo/sdcc-devel

Re: [sdcc-devel] 6502 calling convention

[Gabriele G. <go...@ya...>]

Hello,
The default behavior on the 6502 (like on the 8051) is to generate non-reentrant functions. Function arguments past the first two bytes and local variables are placed in an overlay area in general RAM.
Only the return address ends up on the stack.
Return value goes in AX and then in the pseudo return register in ZP (___SDCC_m6502_retX)

If the function is declared reentrant (or is variadic) then all arguments past the first two bytes end up in the stack.
The caller cleans up the stack. The return value follow the non-reentrant rule.
Local variables are also on the stack.

I don't think Y is preserved across function calls.


thanks,
GG



On Tuesday, November 28, 2023 at 01:29:59 PM PST, Sam Wilson <sam...@gm...> wrote: 





Good evening,

I am looking for information on the calling convention that SDCC uses for the 6502. There is a little bit of information in sdcc/src/mos6502/main.c, but I'm left wondering,

* who (caller or callee) is responsible for popping the arguments back off the stack?
* I assume the return address goes on the top of stack after all arguments (i.e. have the lowest address in memory), so that a `rts` would return from the function
* If the function returns a value, where does it go
* Which memory locations, if any, are for local use
* who (caller or callee) saves Y, if at all?

I found that the Z80 calling conventions have precise descriptions knocking about on the internet. But for the 6502 I'm not sure. If there is any documentation on such matters for the 6502, I would be interested to see that. In particular, is the calling convention compatible with what other compilers like cc65 or gcc6502 do?

Best regards,

_______________________________________________
sdcc-devel mailing list
sdc...@li...
https://lists.sourceforge.net/lists/listinfo/sdcc-devel

[sdcc-devel] 6502 calling convention

[Sam W. <sam...@gm...>]

Good evening,

I am looking for information on the calling convention that SDCC uses for
the 6502. There is a little bit of information in sdcc/src/mos6502/main.c,
but I'm left wondering,

* who (caller or callee) is responsible for popping the arguments back off
the stack?
* I assume the return address goes on the top of stack after all arguments
(i.e. have the lowest address in memory), so that a `rts` would return from
the function
* If the function returns a value, where does it go
* Which memory locations, if any, are for local use
* who (caller or callee) saves Y, if at all?

I found that the Z80 calling conventions have precise descriptions knocking
about on the internet. But for the 6502 I'm not sure. If there is any
documentation on such matters for the 6502, I would be interested to see
that. In particular, is the calling convention compatible with what other
compilers like cc65 or gcc6502 do?

Best regards,

Re: [sdcc-devel] (mcs51) asm output style

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

Philipp Klaus Krause schreef op 2023-11-22 11:21:
> Most ports currently use the following style for the assembly they 
> emit:
> 
> TABmnemonic
> TABmnemonicTABop0,SPACEop1
> TABmnemonicTABop0,SPACEop1,SPACEop2
> 
> However, mcs51 uses
> 
> TABmnemonic
> TABmnemonicTABop0,op1
> TABmnemonicTABop0,op1,op2
> 
> When making some changes in mcs51 recently, I introduced some of the
> latter, resulting in inconsistent style, which looks a bit ugly.
> 
> Do we have a preference for the style here? I can fix my changes to
> make the style follow the old one. Or we could convert mcs51 to use
> the style most ports use.

I too prefer consistency.
I would welcome the extra SPACE if it doesn't wreak havoc.

> Philipp
> 
> P.S.: The peephole optimizer needs to be able to deal with either one
> (and more) anyway, due to the --peep-asm option.

Also user defined peephole rules should still work.

Maarten

[sdcc-devel] (mcs51) asm output style

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

Most ports currently use the following style for the assembly they emit:

TABmnemonic
TABmnemonicTABop0,SPACEop1
TABmnemonicTABop0,SPACEop1,SPACEop2

However, mcs51 uses

TABmnemonic
TABmnemonicTABop0,op1
TABmnemonicTABop0,op1,op2

When making some changes in mcs51 recently, I introduced some of the 
latter, resulting in inconsistent style, which looks a bit ugly.

Do we have a preference for the style here? I can fix my changes to make 
the style follow the old one. Or we could convert mcs51 to use the style 
most ports use.

Philipp

P.S.: The peephole optimizer needs to be able to deal with either one 
(and more) anyway, due to the --peep-asm option.

Re: [sdcc-devel] Retargeting for other processor

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

Am 20.11.23 um 07:26 schrieb Mosleh Uddin:
> Hi All,
> Following link provided in the chapter 8.3 of "SDCC Compiler user guide" 
> is broken. Can someone please provide me with working links?
> https://sdcc.sourceforge.net/wiki/index.php/SDCC_internals_and_porting 
> <https://sdcc.sourceforge.net/wiki/index.php/SDCC_internals_and_porting>
> Thanks.

Thanks. I fixed the manual to point at 
https://sourceforge.net/p/sdcc/wiki/Adding%20a%20port/ instead, which is 
much more up-to-date.

A copy of the document pointed to originally can be found at 
https://github.com/roybaer/sdcc-wiki/wiki/SDCC-internals-and-porting

Philipp

[sdcc-devel] Retargeting for other processor

[Mosleh U. <mos...@gm...>]

Hi All,
Following link provided in the chapter 8.3 of "SDCC Compiler user guide" is
broken. Can someone please provide me with working links?

https://sdcc.sourceforge.net/wiki/index.php/SDCC_internals_and_porting
Thanks.

Mosleh

Re: [sdcc-devel] Rough idea for the 4.4.0 release schedule

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

Dear SDCC developers,

IMO, SDCC has stabilized further (bugs got fixed in the last few weeks), 
so we are still on track for an early 2024 4.4.0 release. The only 
roadblock that appeared recently is bug #3675, but I hope we can fix 
that one in time.

So my proposed schedule would still be:

2023-12-11 Soft freeze
2023-12-19 Hard freeze
2023-12-20 RC1
2024-01-03 Release

We still need a release manager.

Philipp

Re: [sdcc-devel] (Not) breaking the mcs51 port

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

Is there some docs on the register allocations ?

My dream would be to have sdcc support a subset of the gcc syntax for
inline asm for automatic register allocations.
As currently, it seems like dark magic to know what is where.

--
Steve Schnepp

Re: [sdcc-devel] (Not) breaking the mcs51 port

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

Am 15.11.23 um 08:36 schrieb Oleg Endo:
> 
> Sounds great.  I'm curious to see how it works out.  It seems right now
> there are a couple of places in the mcs51 codegen which assume that
> a,b,dph,dpl,dptr are not used by the register allocator.  Hence the original
> question. 'dptr' and 'a' are register classes with a single register and
> both are needed to load/store memory variables and 'a' is needed to compute
> stack pointers.  This kind of thing has always been troublesome on e.g. GCC.

Yes, but those problem scan be solved. It was similar when I converted 
the z80 port to use the new register allocator. There a, hl and iy are 
special in the same way a and dptr are in mcs51, but the new register 
allocator can use them.

Philipp

[sdcc-devel] Fwd: Database issue on SourceForge project: sdcc

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

An old database once used by sdcc to track regressions has become a
problem for SF during a database migration. It has grown quite big,
despite apparently not having been updated for a few years.
For details, see sdcc-web/sdcc-ini and sdcc-web/*-php in svn trunk.

Since this hasn't really been used for years, I guess we can just delete 
it? Someone would have to rewrite the affected web pages so they no 
longer try to access the database.

Philipp

> The 11GB database (s599_regtests) associated with the project Small
> Device C Compiler (SDCC) is causing a significant bottleneck.
> https://sdcc.sourceforge.net/regtests.php
> <https://sdcc.sourceforge.net/regtests.php> tries to read from that
> database, but it times out before successfully loading. Given that
> the database is too large to efficiently return data, coupled with
> the fact that the last insert was in 2016, it's clear that this setup
> is not sustainable.

Re: [sdcc-devel] (Not) breaking the mcs51 port

[Oleg E. <ole...@t-...>]

On Wed, 2023-11-15 at 08:03 +0100, Philipp Klaus Krause wrote:
> > 
> > With peepholes, that's what I get at the moment:
> >   	mov	r4,dpl
> >   	mov	r5,dph
> >   	mov	r6,b
> >   	cpl	acc.7
> >   	mov	dpl,r4
> >   	mov	dph,r5
> >   	mov	b,r6
> >   	ret
> > 
> 
> Without peepholes, that was:
> 
> 	mov	r4,dpl
> 	mov	r5,dph
> 	mov	r6,b
> 	mov	r7,a
> 	mov	a,r7
> 	cpl	acc.7
> 	mov	r7,a
> 	mov	dpl, r4
> 	mov	dph, r5
> 	mov	b, r6
> 	mov	a, r7

BTW, in my local version I've been experimenting with hoisting loads and
stores of 'a', i.e. repeatedly reorder 2 instructions with a few peephole
patterns to make them bubble up (very inefficient, yes, but whatever).  This
increases the chances of it discovering more instruction combine
opportunities and also eliminate reg-reg moves.

Cheers,
Oleg

Re: [sdcc-devel] (Not) breaking the mcs51 port

[Oleg E. <ole...@t-...>]

On Wed, 2023-11-15 at 08:03 +0100, Philipp Klaus Krause wrote:
> 
> In the end, the goal would be to get that even before peephole 
> optimization, but using a as part of variables wieder than 8 bits in the 
> register allocator has to be done carefully (it works well for this 
> float unary minus, but gets more complicated for other operations), and 
> would be a second step after the inital converion to the new allocator.
> 

Sounds great.  I'm curious to see how it works out.  It seems right now
there are a couple of places in the mcs51 codegen which assume that
a,b,dph,dpl,dptr are not used by the register allocator.  Hence the original
question. 'dptr' and 'a' are register classes with a single register and
both are needed to load/store memory variables and 'a' is needed to compute
stack pointers.  This kind of thing has always been troublesome on e.g. GCC.

Cheers,
Oleg

Re: [sdcc-devel] (Not) breaking the mcs51 port

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

Am 15.11.23 um 02:29 schrieb Oleg Endo:
> 
> Take The example that you've pointed out ...
> 
> float bleh (float x)
> {
>    return -x;
> }
> 
> With peepholes, that's what I get at the moment:
>   	mov	r4,dpl
>   	mov	r5,dph
>   	mov	r6,b
>   	cpl	acc.7
>   	mov	dpl,r4
>   	mov	dph,r5
>   	mov	b,r6
>   	ret
> 

Without peepholes, that was:

	mov	r4,dpl
	mov	r5,dph
	mov	r6,b
	mov	r7,a
	mov	a,r7
	cpl	acc.7
	mov	r7,a
	mov	dpl, r4
	mov	dph, r5
	mov	b, r6
	mov	a, r7

The new allocator would be able to allocate to b, and since no memory 
access is among these iCodes, also to dptr. The cost function will guide 
it to coalescing. We should get something like:

	mov	r7, a
	mov	a, r7
	cpl	acc.7

Which the peepholeoptimizer then could turn into

	cpl	acc.7

In the end, the goal would be to get that even before peephole 
optimization, but using a as part of variables wieder than 8 bits in the 
register allocator has to be done carefully (it works well for this 
float unary minus, but gets more complicated for other operations), and 
would be a second step after the inital converion to the new allocator.

Philipp

Re: [sdcc-devel] (Not) breaking the mcs51 port

[Oleg E. <ole...@t-...>]

On Tue, 2023-11-14 at 10:54 +0100, Philipp Klaus Krause wrote:
> Am 14.11.23 um 09:44 schrieb Oleg Endo:
> > However, one related side note, because I've noticed it wading through the
> > generated code of SDCC.  The gen code runs after register allocation, from
> > what I understand.  It creates all those operand copies and some of them
> > remain in place.  For single byte/word operands some of them can be caught
> > with (text based) peephole patters.  But multi-byte operands are difficult,
> > especially since some of the variables end up on the stack.
> > 
> 
> Can you give an illustrating example?
> 

Take The example that you've pointed out ...

float bleh (float x)
{
  return -x;
}

With peepholes, that's what I get at the moment:
 	mov	r4,dpl
 	mov	r5,dph
 	mov	r6,b
 	cpl	acc.7
 	mov	dpl,r4
 	mov	dph,r5
 	mov	b,r6
 	ret

The function input arg in [a:b:dph:dpl] is copied into [r7:r6:r5:r4] and
then back into the return value in [a:b:dph:dpl].

The "a -> r7 -> a" chain is eliminated by peepholes (at least in my current
local version, haven't checked with svn trunk).  All the other redundant
moves are not.  I know the "reg tracking" is trying to do something to
eliminate some of it, too.  But my point is, once these reg-reg copies have
been emitted it's difficult to eliminate them afterwards without re-
analyzing the whole thing.

In some cases peepholes can combine operations and free up registers.  Those
registers will not be re-used for anything else ever again.  And variables
allocated to stack slots will also remain on the stack.

I was thinking of adding a new optimization pass to hoist/sink reg defs/uses
to get better insns combine matches with the peephole patterns.  Another
thing that looks interesting on mcs51 is the utilization of "xch a,reg" to
reduce reg-reg copies.  But this changes the output registers of operations
and that change has to be propagated down into the following uses.

Those things are difficult to do with instruction text snippets.  Something
like asmop (but perhaps withmore meta info) for operands and also a data
type to represent instructions (containing its asmops) would be better.

Cheers,
Oleg

Re: [sdcc-devel] (Not) breaking the mcs51 port

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

Am 14.11.23 um 09:44 schrieb Oleg Endo:
> However, one related side note, because I've noticed it wading through the
> generated code of SDCC.  The gen code runs after register allocation, from
> what I understand.  It creates all those operand copies and some of them
> remain in place.  For single byte/word operands some of them can be caught
> with (text based) peephole patters.  But multi-byte operands are difficult,
> especially since some of the variables end up on the stack.
> 

Can you give an illustrating example?

Philipp

Re: [sdcc-devel] (Not) breaking the mcs51 port

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

Am 14.11.23 um 09:44 schrieb Oleg Endo:
> Another thing, for the new register allocator on mcs51, do you plan to make
> DPH/DPL/DPTR, A, B registers allocatable?

Yes. AOP_REG will fully replace AOP_ACC.

Philipp

Re: [sdcc-devel] (Not) breaking the mcs51 port

[Oleg E. <ole...@t-...>]

On Mon, 2023-11-13 at 11:24 +0100, Philipp Klaus Krause wrote:
> Am 13.11.23 um 10:49 schrieb Oleg Endo:
> > 
> > Do you have a more specific example of what you mean?
> 
> E.g. from genUminusFloat in src/mcs51/gen.c:
> 
>    size = AOP_SIZE (op) - 1;
> 
>    while (size--)
>      {
>        aopPut (result, opGet (op, offset, FALSE, FALSE), offset);
>        offset++;
>      }
> 
> This copies part of one operand to another.
> 
> aopPut (result, opGet (op, offset, FALSE, FALSE), offset);
> The opGet creates a string fir the byte of op at offset. aopPut then 
> stores that into result at offset. To do so, aopPut parses that string 
> it got. So information that was there is now being reconstructed from a 
> string without any real need to doit like this.
> 
> Other ports would use a call to genMove_o to copy all at once. Or if you 
> really want to do it byte by byte and in order, cheapMove in the loop.
> 

I think I get it.

However, one related side note, because I've noticed it wading through the
generated code of SDCC.  The gen code runs after register allocation, from
what I understand.  It creates all those operand copies and some of them
remain in place.  For single byte/word operands some of them can be caught
with (text based) peephole patters.  But multi-byte operands are difficult,
especially since some of the variables end up on the stack.

Do you have any plans how to improve on that?

> Anyway, I'll change a bit of that to use asmop * instead of char *, as 
> needed to support aopArg and aopRet now. The rest can be done during the 
> migration to the new register allocator post-4.4.0.
> 

Please let me know how to move on with the peephole stuff after you've got
your things in there.

Another thing, for the new register allocator on mcs51, do you plan to make
DPH/DPL/DPTR, A, B registers allocatable?

Best regards,
Oleg Endo

Re: [sdcc-devel] (Not) breaking the mcs51 port

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

Am 13.11.23 um 10:49 schrieb Oleg Endo:
> 
> Do you have a more specific example of what you mean?

E.g. from genUminusFloat in src/mcs51/gen.c:

   size = AOP_SIZE (op) - 1;

   while (size--)
     {
       aopPut (result, opGet (op, offset, FALSE, FALSE), offset);
       offset++;
     }

This copies part of one operand to another.

aopPut (result, opGet (op, offset, FALSE, FALSE), offset);
The opGet creates a string fir the byte of op at offset. aopPut then 
stores that into result at offset. To do so, aopPut parses that string 
it got. So information that was there is now being reconstructed from a 
string without any real need to doit like this.

Other ports would use a call to genMove_o to copy all at once. Or if you 
really want to do it byte by byte and in order, cheapMove in the loop.

Anyway, I'll change a bit of that to use asmop * instead of char *, as 
needed to support aopArg and aopRet now. The rest can be done during the 
migration to the new register allocator post-4.4.0.

Philipp

Re: [sdcc-devel] (Not) breaking the mcs51 port

[Oleg E. <ole...@t-...>]

On Sun, 2023-11-12 at 17:08 +0100, Philipp Klaus Krause wrote:
> 
> I don't think this is the right moment. Maybe the peephole optimizer 
> stuff (src/*/peep.c) could benefit from C++, but it seems to work well 
> enough using C for other ports for now. If it gets changed, it should 
> probably be changed ofr all ports, and such a big change should probably 
> be done after the 4.4.0 release.
> 
> Formally, the C++ dialect currently used in SDCC is the common subset of 
> C++11 and C++23
> (https://sourceforge.net/p/sdcc/wiki/Language%20dialects%20used%20in%20SDCC/). 

Is there a more detailed definition of what that common subset is?

> That could be changed if C++17 support is widespread on host compilers, 
> and there is an important use case for a C++17 feature, though.
> 

Some of my personal favorites ..

std::optional (C++17)
if constexpr (C++17)
std::filesystem (C++17)
std::clamp (C++17)
std::make_unique (C++14)

C++17 is OK with GCC 8 and MSVC 2019.  GCC 8 is almost not being supported
by major distros anymore.  I guess it's a safe assumption.

Being able to use std or boost containers is a big plus, IMO.  Especially
for code bases that don't have much activity, it makes it easier to jump
into the code and allows for more meaningful occasional contributions.

For example, I had to read the implementation of SDCC's bit-vector code in
order to be able to use it without introducing bugs.  It took a while to
debug my code and in hindsight was an absolute waste of time on something
that should have been trivial.

GCC had a similar discussion several years ago when they switched from C to
C++.  Moreover, your new register allocator requires C++ and boost, too.  I
guess there's a reason for that ;)

Anyway, I'm not suggesting to go all in and rewrite everything with
templates and tuples and auto at once.  But having the code being compiled
as C++ would be a good start and would allow step by step refactorings.

> On the other hand, IMO, code generation (src/*/gen.c) shouldn't use 
> strings (char *, or whatever other representations) as much as mcs51 
> currently does. IMO, at code generation time, the right abstraction for 
> an operand to an instruction or helper function is an asmop * (or a part 
> thereof), not a string. There should be no or nearly no need for parsing 
> and interpreting strings at code generation time.
> 

Do you have a more specific example of what you mean?

BTW, text peepholes have been replaced with "proper RTL" peepholes in GCC
long time ago.  Parsing text operands and numbers over and over again in all
kinds of different formats doesn't seem the way to go (fast / far).  That
is, if there is any plan or desire to add more sophisticated (backend
specific) optimizations to SDCC in the future.

Best regards,
Oleg Endo

Re: [sdcc-devel] (Not) breaking the mcs51 port

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

Am 12.11.23 um 17:06 schrieb Sam Wilson:
>  > Might warrant a 5.0.0?
> 
> In my opinion, if we bump the major version, it will pay to take a 
> serious look at revamping the PIC backends.
> 
> As I recall, they depend on unmaintained gputils which gives rise to 
> clunky architecture. I would like to propose that assembly and linkage 
> is handled by SDCC for the PIC backends.
> 

Well, they are unmaintained, i.e. no one wants to work on them. On the 
other hand, AFAIK, gputils are no longer unmaintained though, I see 
commits in their repo from less than three weeks ago. While I am not 
familiar with the pic stuff, I guess that there are more serious issues 
(i.e. serious open bugs) than the questionof using gputils vs. some 
other assembler/linker/simulator.
Either way, until there is someone who wants to work on pic, there is 
not that much point discussing those ports (unless they become too much 
of a burden, in which case we need to discuss removing them).

Philipp

Re: [sdcc-devel] (Not) breaking the mcs51 port

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

Am 12.11.23 um 04:31 schrieb Oleg Endo:
> 
>>From my own experience working with that codebase recently, I'd highly
> recommend moving it over to c++17 and use standard std containers and string
> representations (other than 'const char*').  The code as it is now is
> frustrating to work with, IMO.

I don't think this is the right moment. Maybe the peephole optimizer 
stuff (src/*/peep.c) could benefit from C++, but it seems to work well 
enough using C for other ports for now. If it gets changed, it should 
probably be changed ofr all ports, and such a big change should probably 
be done after the 4.4.0 release.

Formally, the C++ dialect currently used in SDCC is the common subset of 
C++11 and C++23 
(https://sourceforge.net/p/sdcc/wiki/Language%20dialects%20used%20in%20SDCC/). 
That could be changed if C++17 support is widespread on host compilers, 
and there is an important use case for a C++17 feature, though.

On the other hand, IMO, code generation (src/*/gen.c) shouldn't use 
strings (char *, or whatever other representations) as much as mcs51 
currently does. IMO, at code generation time, the right abstraction for 
an operand to an instruction or helper function is an asmop * (or a part 
thereof), not a string. There should be no or nearly no need for parsing 
and interpreting strings at code generation time.

Philipp

Re: [sdcc-devel] (Not) breaking the mcs51 port

[Sam W. <sam...@gm...>]

> Might warrant a 5.0.0?

In my opinion, if we bump the major version, it will pay to take a serious
look at revamping the PIC backends.

As I recall, they depend on unmaintained gputils which gives rise to clunky
architecture. I would like to propose that assembly and linkage is handled
by SDCC for the PIC backends.



On Sat, 11 Nov 2023 at 19:59, Steve Schnepp <ste...@gm...> wrote:

> Might warrant a 5.0.0?
>
> Multiple nice things:
> * signal high risk changes
> * shows that sdcc is still alive and kicking
> * unlock if we have overdue but subtly breaking changes, such as
> --params-in-bank1
>
> what do you think?
> --
> Steve SCHNEPP
>
>
> On Sat, Nov 11, 2023, 18:15 Philipp Klaus Krause <pk...@sp...> wrote:
>
>> In the next few weeks, I intend to make a few small changes and
>> refactoring in the mcs51 port.
>>
>> The goals are:
>> 0) Prepare for post-4.4.0 new register allocator
>> 1) Have a better base for the peephole optimizer improvments
>> 2) A few optimizations using information from generalized constant
>> propagation.
>>
>> In particular, many helper functions in code generation IMO currently
>> use a too-low or too-high abstraction level (or both). IMO, stuff to
>> work on should typically be an asmop *. Now it is often a string or an
>> operand *.
>>
>> The mcs51 port typically doesn't see too much activity, and has a
>> reputation of being very stable. Changing things comes with a risk of
>> breaking things. I think a good way to mitigate this risk for 4.4.0 is:
>> - The rather long hard freeze from the 4.4.0 release schedule proposal
>> - A relatively long soft freeze before that.
>> I'd suggest to start the soft freeze for 4.4.0 in 1 month.
>>
>> Philipp
>>
>>
>> _______________________________________________
>> sdcc-devel mailing list
>> sdc...@li...
>> https://lists.sourceforge.net/lists/listinfo/sdcc-devel
>>
> _______________________________________________
> sdcc-devel mailing list
> sdc...@li...
> https://lists.sourceforge.net/lists/listinfo/sdcc-devel
>

Re: [sdcc-devel] (Not) breaking the mcs51 port

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

Am 11.11.23 um 20:58 schrieb Steve Schnepp:
> Might warrant a 5.0.0?
> 
> Multiple nice things:
> * signal high risk changes
> * shows that sdcc is still alive and kicking
> * unlock if we have overdue but subtly breaking changes, such as 
> --params-in-bank1
> 
> what do you think?
> -- 

The planned changes are somewhat unusual for the mcs51 port, since it 
hasn't seen big changes for many years, and and also that they are done 
by a non-maintainer (of the port). But other ports in SDCC have seen 
much bigger changes. And if I progress as planned, the mcs51 port will 
see much bigger changes after 4.4.0.

Philipp

Re: [sdcc-devel] (Not) breaking the mcs51 port

[Oleg E. <ole...@t-...>]

On Sat, 2023-11-11 at 18:14 +0100, Philipp Klaus Krause wrote:
> In the next few weeks, I intend to make a few small changes and 
> refactoring in the mcs51 port.
> 
> The goals are:
> 0) Prepare for post-4.4.0 new register allocator
> 1) Have a better base for the peephole optimizer improvments
> 2) A few optimizations using information from generalized constant 
> propagation.
> 
> In particular, many helper functions in code generation IMO currently 
> use a too-low or too-high abstraction level (or both). IMO, stuff to 
> work on should typically be an asmop *. Now it is often a string or an 
> operand *.
> 

>From my own experience working with that codebase recently, I'd highly
recommend moving it over to c++17 and use standard std containers and string
representations (other than 'const char*').  The code as it is now is
frustrating to work with, IMO.

Best regards,
Oleg Endo