Menu
▾
▴
sdcc-devel
|
From: Steve S. <ste...@gm...> - 2024-07-01 16:38:10
|
I saw in the wiki [1] that there's an old wish for a better register allocation in the mcs51 port. As I'm also very interested in supporting specific register allocation in asm [2], I'd like to know how I could best tackle it. I don't have ample time to dwell into it, but I might be able to contribute somehow ;-) [1] https://sourceforge.net/p/sdcc/wiki/Project%20ideas/ [2] https://sourceforge.net/p/sdcc/feature-requests/915/ I'd -- Steve Schnepp "A man is not dead while his name is still spoken." -- T. Pratchett - Going Postal, Chapter 4 prologue |
|
From: Oleg E. <ole...@t-...> - 2024-07-02 03:19:42
|
On Mon, 2024-07-01 at 18:37 +0200, Steve Schnepp wrote: > I saw in the wiki [1] that there's an old wish for a better register allocation in the mcs51 port. > > As I'm also very interested in supporting specific register allocation in asm [2], I'd like to know how I could best tackle it. I don't have ample time to dwell into it, but I might be able to contribute somehow ;-) > > [1] https://sourceforge.net/p/sdcc/wiki/Project%20ideas/ > [2] https://sourceforge.net/p/sdcc/feature-requests/915/ I'd > > -- > Last year until earlier this year I was trying to upstream my work for improved peephole pattern optimizations on mcs51 with Philipp. At that time he mentioned that he'd be moving the mcs51 target to the better register allocation scheme. We got stuck half-way with the peephole stuff though, from what I remember. I wasn't aware of SDCC participating in the GSoC program. I did actually 2 rounds of GSoC back then with GCC. I'd be great if the half-finished peephole work could be completed. If there are any GSoC candidates I might be able co-mentor. Best regards, Oleg Endo |
|
From: Philipp K. K. <pk...@sp...> - 2024-07-02 06:54:20
|
Am 02.07.24 um 05:18 schrieb Oleg Endo: > I wasn't aware of SDCC participating in the GSoC program. I did actually 2 > rounds of GSoC back then with GCC. > > I'd be great if the half-finished peephole work could be completed. If > there are any GSoC candidates I might be able co-mentor. AFAIR we applied for GSoC once, got rejected, and haven't tried again since. Philipp |
|
From: Philipp K. K. <pk...@sp...> - 2024-07-08 07:00:41
|
Am 02.07.24 um 08:54 schrieb Philipp Klaus Krause: > Am 02.07.24 um 05:18 schrieb Oleg Endo: >> I wasn't aware of SDCC participating in the GSoC program. I did >> actually 2 >> rounds of GSoC back then with GCC. >> >> I'd be great if the half-finished peephole work could be completed. If >> there are any GSoC candidates I might be able co-mentor. > > AFAIR we applied for GSoC once, got rejected, and haven't tried again > since. If there are candidates, we could try GSoc again. I think NLnet funding could also be an alternative (and is less seasonal). Philipp |
|
From: Oleg E. <ole...@t-...> - 2024-07-04 06:24:51
|
On Tue, 2024-07-02 at 08:54 +0200, Philipp Klaus Krause wrote: > Am 02.07.24 um 05:18 schrieb Oleg Endo: > > I wasn't aware of SDCC participating in the GSoC program. I did actually 2 > > rounds of GSoC back then with GCC. > > > > I'd be great if the half-finished peephole work could be completed. If > > there are any GSoC candidates I might be able co-mentor. > > AFAIR we applied for GSoC once, got rejected, and haven't tried again since. > Regardless of that, I still would like to continue working on upstreaming my mcs51 changes. Maybe I'll have a bit more headroom towards the end of this year ... Best regards, Oleg Endo |
|
From: Steve S. <ste...@gm...> - 2024-07-04 06:50:36
|
Are those somewhere online? -- Steve SCHNEPP On Thu, Jul 4, 2024, 08:25 Oleg Endo <ole...@t-...> wrote: > > > On Tue, 2024-07-02 at 08:54 +0200, Philipp Klaus Krause wrote: > > Am 02.07.24 um 05:18 schrieb Oleg Endo: > > > I wasn't aware of SDCC participating in the GSoC program. I did > actually 2 > > > rounds of GSoC back then with GCC. > > > > > > I'd be great if the half-finished peephole work could be completed. If > > > there are any GSoC candidates I might be able co-mentor. > > > > AFAIR we applied for GSoC once, got rejected, and haven't tried again > since. > > > > Regardless of that, I still would like to continue working on upstreaming > my > mcs51 changes. Maybe I'll have a bit more headroom towards the end of this > year ... > > Best regards, > Oleg Endo > > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > |
|
From: Oleg E. <ole...@t-...> - 2024-07-04 07:06:01
|
On Thu, 2024-07-04 at 08:50 +0200, Steve Schnepp wrote: > Are those somewhere online? > > > As far as I remember, I posted the original patch set somewhere in the sourceforge bug tracker. But as we started working on it some of the changes diverged and became unmergeable as of the lastest SDCC version. Best regards, Oleg Endo |
|
From: Philipp K. K. <pk...@sp...> - 2024-07-08 06:59:16
|
Am 04.07.24 um 09:05 schrieb Oleg Endo: > > On Thu, 2024-07-04 at 08:50 +0200, Steve Schnepp wrote: >> Are those somewhere online? >> >> >> > > As far as I remember, I posted the original patch set somewhere in the > sourceforge bug tracker. But as we started working on it some of the > changes diverged and became unmergeable as of the lastest SDCC version. This one? https://sourceforge.net/p/sdcc/patches/466/ |
|
From: Philipp K. K. <pk...@sp...> - 2024-07-08 10:09:56
|
Am 01.07.24 um 18:37 schrieb Steve Schnepp: > I saw in the wiki [1] that there's an old wish for a better register > allocation in the mcs51 port. By now, I think this would be a too-big first project. After all it requires knowledge of the register allocator, of the MCS-51, and virtually all of mcs51 code generation will have to be rewritten. This will likely take a few months to do well. Philipp |
|
From: Oleg E. <ole...@t-...> - 2024-07-08 11:54:15
|
On Mon, 2024-07-08 at 08:59 +0200, Philipp Klaus Krause wrote: > Am 04.07.24 um 09:05 schrieb Oleg Endo: > > > > On Thu, 2024-07-04 at 08:50 +0200, Steve Schnepp wrote: > > > Are those somewhere online? > > > > > > > > > > > > > As far as I remember, I posted the original patch set somewhere in the > > sourceforge bug tracker. But as we started working on it some of the > > changes diverged and became unmergeable as of the lastest SDCC version. > > This one? > https://sourceforge.net/p/sdcc/patches/466/ > Yeah, that one! :) Best regards, Oleg Endo |
|
From: Steve S. <ste...@gm...> - 2024-07-08 12:41:25
|
Nice! I'll have a look. I was also wondering how I could have the first parameter & return value in A instead of DPL, as i have many functions doing a mov a,dpl & mov dpl,a as prolog and epilog. Moving them to "inline" does eliminates it, but I don't really want to do that as then the code is much bigger as those are reused quite often. Cheers, -- Steve Schnepp On Mon, Jul 8, 2024 at 1:54 PM Oleg Endo <ole...@t-...> wrote: > > > On Mon, 2024-07-08 at 08:59 +0200, Philipp Klaus Krause wrote: > > Am 04.07.24 um 09:05 schrieb Oleg Endo: > > > > > > On Thu, 2024-07-04 at 08:50 +0200, Steve Schnepp wrote: > > > > Are those somewhere online? > > > > > > > > > > > > > > > > > > As far as I remember, I posted the original patch set somewhere in the > > > sourceforge bug tracker. But as we started working on it some of the > > > changes diverged and became unmergeable as of the lastest SDCC version. > > > > This one? > > https://sourceforge.net/p/sdcc/patches/466/ > > > > Yeah, that one! :) > > Best regards, > Oleg Endo > > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel |
|
From: Oleg E. <ole...@t-...> - 2024-07-08 13:17:01
|
On Mon, 2024-07-08 at 14:40 +0200, Steve Schnepp wrote: > Nice! I'll have a look. > > I was also wondering how I could have the first parameter & return > value in A instead of DPL, as i have many functions doing a mov a,dpl > & mov dpl,a as prolog and epilog. > Moving them to "inline" does eliminates it, but I don't really want to > do that as then the code is much bigger as those are reused quite > often. > Best thing would be a new redesigned ABI for mcs51. I also think 'a' would be a better place to hold an 8-bit return value, since very often it holds the result of some calculation of memory load. AFAIR we've also briefly scratched the ABI topic back then. All in all, it's a lot of work ... Best regards, Oleg Endo |
|
From: Maarten B. <sou...@ds...> - 2024-07-08 21:11:22
|
Steve Schnepp schreef op 2024-07-08 14:40: > Nice! I'll have a look. > > I was also wondering how I could have the first parameter & return > value in A instead of DPL, as i have many functions doing a mov a,dpl > & mov dpl,a as prolog and epilog. > Moving them to "inline" does eliminates it, but I don't really want to > do that as then the code is much bigger as those are reused quite > often. > > Cheers, > -- > Steve Schnepp Using ACC to pass parameters and return values is a disaster when bank switching is involved. Or when the stack frame must broken down, etc. This really is not a very good idea. But using DPTR is not ideal either. Commercial compilers almost all use r0-r7. Maarten |
|
From: Oleg E. <ole...@t-...> - 2024-07-09 02:38:06
|
On Mon, 2024-07-08 at 22:13 +0200, Maarten Brock wrote:
> Steve Schnepp schreef op 2024-07-08 14:40:
> > Nice! I'll have a look.
> >
> > I was also wondering how I could have the first parameter & return
> > value in A instead of DPL, as i have many functions doing a mov a,dpl
> > & mov dpl,a as prolog and epilog.
> > Moving them to "inline" does eliminates it, but I don't really want to
> > do that as then the code is much bigger as those are reused quite
> > often.
> >
> > Cheers,
> > --
> > Steve Schnepp
>
> Using ACC to pass parameters and return values is a disaster when bank
> switching is involved. Or when the stack frame must broken down, etc.
> This really is not a very good idea. But using DPTR is not ideal either.
> Commercial compilers almost all use r0-r7.
>
This is a very good point! You are right. I dug out my notes on that
matter from a while ago. This is what I arrived at for a possibly improved
mcs51 ABI:
* call clobbered registers:
r0-r3, a, b, dptr, carry flag
* call saved registers:
r4-r7, psw bank select bits
* function arguments and return value:
r0-r3 instead of { dpl, dph, b, a, r4. r5, r6, r7 }
values are stuffed into registers as much as possible, the remaining
go onto the stack.
can pass/return 4x uint8_t, 2x uint16_t or 1x uint32_t directly
in registers
pointers are converted to their corresponding integer base types
(idata = 8 bit, xdata = 16 bit, code = 16/24 bit)
pointers to stack/iram can be passed directly in registers r0, r1
efficiently
dptr register becomes free, can use jmp @a+dptr to do function
pointer calls (especially for noreturn and tailcalls)
for argument forwarding from function to function, return value
and input arguments should be in the same registers.
* bool function return type:
returned in the carry flag (automatically convert to __bit)
however, not sure what's the best way to pass multiple bool / __bit
arguments, or mixed with other types ... packing them into r0~r3 sounds
inefficient. perhaps the current virtual bit register/variable is
the best way.
* banked calls:
currently uses [r2:r1:r0] for function address and [b:a:dph:dpl] for
function arguments. the banked call implementation needs 'a'
register and dptr to do the bank switching.
loading the lower 16-bits of the call address into dptr
is more efficient (single insn)
if the banked call implementation needs to push dptr onto the stack,
it can be done so directly (can't do that with r0,r1,r2 because of
unknown psw bank select bit status)
before the call the current bank select register needs to be saved.
some MCUs can directly push the bank select SFR, others have the
bank select register in XFR (registers in __xdata). for that it will
need to clobber 'a' and 'dptr' for the bank switching implementation.
if the implementation needs to do bit-twiddling on the high-byte,
it’s better to have this in a bit-addressable register
→ pass 24 bit call address in [b:dph:dpl] or [a:dph:dpl]
- can manipulate bis in 'a' or 'b' efficiently
- can load dptr with 16-bit code offset efficiently
- maybe some implementations can use 'jmp @a+dptr' to avoid
ferrying the call address through the stack for 'ret'
when calling a function that has a different "register-bank-use", the
arguments can be moved into the corresponding banked registers easily
(using direct iram address) before making the call.
Best regards,
Oleg Endo
|
|
From: Philipp K. K. <pk...@sp...> - 2024-07-09 05:17:05
|
Am 09.07.24 um 04:37 schrieb Oleg Endo: > > This is a very good point! You are right. I dug out my notes on that > matter from a while ago. This is what I arrived at for a possibly improved > mcs51 ABI: > > > […] I've opened a ticket: https://sourceforge.net/p/sdcc/feature-requests/934/, I suggest you post your notes there, so we will rememeber to have your proposal among the ones we test empirically, once we've reached the point where we can easily do so. Philipp |
|
From: Oleg E. <ole...@t-...> - 2024-07-09 06:39:44
|
On Tue, 2024-07-09 at 07:16 +0200, Philipp Klaus Krause wrote: > Am 09.07.24 um 04:37 schrieb Oleg Endo: > > > > This is a very good point! You are right. I dug out my notes on that > > matter from a while ago. This is what I arrived at for a possibly improved > > mcs51 ABI: > > > > > > […] > > I've opened a ticket: > https://sourceforge.net/p/sdcc/feature-requests/934/, I suggest you post > your notes there, so we will rememeber to have your proposal among the > ones we test empirically, once we've reached the point where we can > easily do so. > > Your link doesn't work .. no idea what's with that, but it's https://sourceforge.net/p/sdcc/feature-requests/934/ I've copy-pasted the contents of my mail there. Sorry, but source forge's ticket UI is terrible and takes me too much time to "format properly". Please also add the other related ticket https://sourceforge.net/p/sdcc/feature-requests/79/ Best regards, Oleg Endo |
|
From: Steve S. <ste...@gm...> - 2024-07-09 14:08:28
|
What does "flexible calling convention in the compiler" mean ?
Not saying practical, but would it be doable to have a fully flexible
calling convention ?
something akin to
__reg(a) char my_add( __reg(a) char first, __reg(r0) char second) {
return first + second;
}
which would obviously generate:
_my_add:
ADDC A, R0
RET
The default being :
__reg(dpl) char my_add(__reg(dpl) char first, __reg(dph) char second) {
return first + second;
}
Having the developer that chooses the appropriate registry, and
failing with an error if not possible.
This would then be reused by calling conventions such as __keil.
It might be easier to ship, as it wouldn't break the ABI right away,
since we don't change the default.
While still having the benefit of high tailoring & performance testing
for incremental improvements.
Cheers,
--
Steve Schnepp
|
|
From: Steve S. <ste...@gm...> - 2024-07-09 14:12:29
|
On Tue, Jul 9, 2024 at 4:07 PM Steve Schnepp <ste...@gm...> wrote: > ... Added my comment to the ticket https://sourceforge.net/p/sdcc/feature-requests/934/ |
|
From: Philipp K. K. <pk...@sp...> - 2024-07-09 19:52:03
|
Am 09.07.24 um 16:07 schrieb Steve Schnepp:
> What does "flexible calling convention in the compiler" mean ?
> Not saying practical, but would it be doable to have a fully flexible
> calling convention ?
>
> something akin to
>
> __reg(a) char my_add( __reg(a) char first, __reg(r0) char second) {
> return first + second;
> }
AFAIR, there was a similar discussion when we worked on calling
conventions for z80. Since the calling convention does not make a
difference inthe abstract machine, it would probably be a good idea to
use C23 attributes instead of inventing new syntax.
But for that we'd need to improve our support of C23 attributes in the
frontend first.
Philipp
|
|
From: Steve S. <ste...@gm...> - 2024-07-09 20:27:21
|
Using standard syntax is always better, indeed. -- Steve SCHNEPP |
Thanks for helping keep SourceForge clean.
X