You can subscribe to this list here.
2000 |
Jan
(1) |
Feb
(56) |
Mar
(65) |
Apr
(18) |
May
(40) |
Jun
(12) |
Jul
(18) |
Aug
(19) |
Sep
(164) |
Oct
(86) |
Nov
(67) |
Dec
(29) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(96) |
Feb
(176) |
Mar
(119) |
Apr
(59) |
May
(181) |
Jun
(193) |
Jul
(140) |
Aug
(180) |
Sep
(182) |
Oct
(322) |
Nov
(263) |
Dec
(187) |
2002 |
Jan
(130) |
Feb
(83) |
Mar
(106) |
Apr
(28) |
May
(39) |
Jun
(46) |
Jul
(78) |
Aug
(107) |
Sep
(66) |
Oct
(33) |
Nov
(58) |
Dec
(53) |
2003 |
Jan
(197) |
Feb
(261) |
Mar
(282) |
Apr
(242) |
May
(218) |
Jun
(107) |
Jul
(108) |
Aug
(78) |
Sep
(129) |
Oct
(181) |
Nov
(139) |
Dec
(108) |
2004 |
Jan
(224) |
Feb
(185) |
Mar
(115) |
Apr
(102) |
May
(98) |
Jun
(103) |
Jul
(124) |
Aug
(88) |
Sep
(124) |
Oct
(100) |
Nov
(74) |
Dec
(79) |
2005 |
Jan
(66) |
Feb
(83) |
Mar
(123) |
Apr
(53) |
May
(109) |
Jun
(46) |
Jul
(126) |
Aug
(78) |
Sep
(61) |
Oct
(43) |
Nov
(213) |
Dec
(93) |
2006 |
Jan
(63) |
Feb
(109) |
Mar
(79) |
Apr
(185) |
May
(283) |
Jun
(179) |
Jul
(147) |
Aug
(156) |
Sep
(114) |
Oct
(173) |
Nov
(137) |
Dec
(148) |
2007 |
Jan
(154) |
Feb
(108) |
Mar
(132) |
Apr
(151) |
May
(241) |
Jun
(94) |
Jul
(109) |
Aug
(50) |
Sep
(62) |
Oct
(128) |
Nov
(90) |
Dec
(74) |
2008 |
Jan
(53) |
Feb
(161) |
Mar
(261) |
Apr
(53) |
May
(87) |
Jun
(44) |
Jul
(73) |
Aug
(67) |
Sep
(54) |
Oct
(37) |
Nov
(72) |
Dec
(53) |
2009 |
Jan
(51) |
Feb
(73) |
Mar
(84) |
Apr
(67) |
May
(59) |
Jun
(31) |
Jul
(78) |
Aug
(45) |
Sep
(90) |
Oct
(56) |
Nov
(69) |
Dec
(51) |
2010 |
Jan
(188) |
Feb
(73) |
Mar
(20) |
Apr
(46) |
May
(91) |
Jun
(24) |
Jul
(115) |
Aug
(135) |
Sep
(132) |
Oct
(90) |
Nov
(92) |
Dec
(58) |
2011 |
Jan
(121) |
Feb
(90) |
Mar
(56) |
Apr
(79) |
May
(98) |
Jun
(109) |
Jul
(104) |
Aug
(113) |
Sep
(234) |
Oct
(143) |
Nov
(160) |
Dec
(93) |
2012 |
Jan
(162) |
Feb
(160) |
Mar
(219) |
Apr
(186) |
May
(135) |
Jun
(360) |
Jul
(138) |
Aug
(72) |
Sep
(130) |
Oct
(146) |
Nov
(64) |
Dec
(137) |
2013 |
Jan
(65) |
Feb
(18) |
Mar
(35) |
Apr
(26) |
May
(108) |
Jun
(34) |
Jul
(16) |
Aug
(11) |
Sep
(61) |
Oct
(4) |
Nov
(23) |
Dec
(24) |
2014 |
Jan
(56) |
Feb
(58) |
Mar
(54) |
Apr
(26) |
May
(3) |
Jun
(31) |
Jul
(13) |
Aug
(13) |
Sep
(7) |
Oct
(26) |
Nov
(65) |
Dec
(54) |
2015 |
Jan
(64) |
Feb
(15) |
Mar
(25) |
Apr
(41) |
May
(22) |
Jun
(62) |
Jul
(26) |
Aug
(17) |
Sep
(35) |
Oct
(33) |
Nov
(37) |
Dec
(17) |
2016 |
Jan
(39) |
Feb
(12) |
Mar
(15) |
Apr
(13) |
May
(41) |
Jun
(76) |
Jul
(53) |
Aug
(38) |
Sep
(31) |
Oct
(11) |
Nov
(9) |
Dec
(19) |
2017 |
Jan
(11) |
Feb
(19) |
Mar
|
Apr
(28) |
May
(61) |
Jun
(9) |
Jul
(9) |
Aug
(14) |
Sep
|
Oct
(63) |
Nov
(43) |
Dec
(21) |
2018 |
Jan
(24) |
Feb
(46) |
Mar
(38) |
Apr
(6) |
May
(14) |
Jun
(10) |
Jul
(12) |
Aug
(12) |
Sep
(29) |
Oct
(9) |
Nov
(17) |
Dec
(22) |
2019 |
Jan
(20) |
Feb
(22) |
Mar
(22) |
Apr
(10) |
May
(2) |
Jun
(7) |
Jul
(5) |
Aug
|
Sep
(5) |
Oct
(13) |
Nov
(8) |
Dec
(11) |
2020 |
Jan
(23) |
Feb
(14) |
Mar
(2) |
Apr
(11) |
May
(14) |
Jun
(48) |
Jul
(111) |
Aug
(26) |
Sep
(6) |
Oct
(22) |
Nov
(7) |
Dec
(26) |
2021 |
Jan
(4) |
Feb
(40) |
Mar
(64) |
Apr
(46) |
May
(18) |
Jun
(20) |
Jul
(11) |
Aug
(40) |
Sep
(16) |
Oct
(15) |
Nov
(46) |
Dec
(10) |
2022 |
Jan
(60) |
Feb
(163) |
Mar
(117) |
Apr
(8) |
May
(22) |
Jun
(13) |
Jul
(5) |
Aug
(1) |
Sep
(20) |
Oct
(4) |
Nov
(13) |
Dec
(16) |
2023 |
Jan
(45) |
Feb
(5) |
Mar
(1) |
Apr
(7) |
May
(128) |
Jun
(41) |
Jul
(40) |
Aug
(52) |
Sep
(20) |
Oct
(18) |
Nov
(40) |
Dec
(52) |
2024 |
Jan
(19) |
Feb
(5) |
Mar
(6) |
Apr
(18) |
May
(5) |
Jun
(20) |
Jul
(58) |
Aug
(15) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Philipp K. K. <pk...@sp...> - 2024-08-22 10:33:07
|
Am 22.08.24 um 11:01 schrieb 月明风清 via sdcc-devel: > I want to know the work in detail. :) Well, the application hasn't been written yet. So we still have the freedom to put tasks into the application that SDCC developers think are useful and that they want to work on. Some rough guidelines: I intend to submit an application to the NLnet NGI0 Commons Fund. * NLnet is based in the EU, and they can fund anyone within the EU, and also projects where the majority of the work is done in the EU. There are some issues with funding developers in certain countries, AFAIK in particular Russia, USA, Iran, North Korea. A potential issue is that AFAIK, NGI0 funding for 2025 an onwards has not yet been officially approved by the EU. * The work should be relevant for modern embedded systems. Retrocomputing stuff is AFAIK outside the scope of NGI0 funding. There might be other, more culturally-oriented funding sources for retrocomputing stuff, but I don't know much about that. There's the "Awesome Foundation" which might fund something such work, but I'm in Germany and they mostly fund work in the US and UK, and do not fund work in Germany. * If funding from NLnet received by a developer is taxable income, and in case it is taxed, how, depends on your local tax laws, and their interpretation. Unfortunately, for many countries, this is simply not known yet. Philipp |
From: <445...@qq...> - 2024-08-22 09:01:20
|
I want to know the work in detail. :) 月明风清 445...@qq... ------------------ Original ------------------ From: "Development chatter about sdcc" <pk...@sp...>; Date: Mon, Aug 5, 2024 06:04 PM To: "Development chatter about sdcc"<sdc...@li...>; Subject: [sdcc-devel] Funding application Dear SDCC developers, I intend to attempt another application for funding for some paid work on SDCC. Are any of you interested in participating? Philipp _______________________________________________ sdcc-devel mailing list sdc...@li... https://lists.sourceforge.net/lists/listinfo/sdcc-devel |
From: Philipp K. K. <pk...@sp...> - 2024-08-21 08:02:23
|
Am 18.08.24 um 08:45 schrieb Philipp Klaus Krause: > Am 18.08.24 um 06:35 schrieb Erik Petrich: >> >> /home/sdcc-builder/build/sdcc-build/orig/sdcc/src/f8/gen.c: In function >> ‘genRightShift’: >> /home/sdcc-builder/build/sdcc-build/orig/sdcc/src/f8/gen.c:5364:7: >> error: a label can only be part of a statement and a declaration is not >> a statement >> […] >> >> Looks like some sort of portability issue with the f8 code that was >> merged in on August 4. > > Thanks for having a look. That's my fault: labels before declarations > are an ISO C23 feature, but SDCC is supposed to be written in ISO C17. I > fixed it today. > > Philipp In case someone was wondering why the snapshots aren't back yet: I found and removed another use of a C23 feature in the f8 port today. That should be the laat one, so I guess 32-bit snapshots will be back tomorrow. Philipp |
From: Philipp K. K. <pk...@sp...> - 2024-08-18 14:37:43
|
My personal impression from the bug reports is that 4.4.0 is quite good, except for Windows-specific issues. And AFAIK, about half our users do use Windows. My original plans for 4.5.0 (mcs51 codegen rewrite for new register allocator) got delayed, so nothing of that will make it to trunk before 4.5.0. So my idea was to try to look into those Windows issues a bit, and see if I can fix some of them (despite not being a Windows user), and fix that code size/speed regression (https://sourceforge.net/p/sdcc/feature-requests/937/) I introduced when fixing a bug recently, so 4.5.0 would be for Windows users what 4.4.0 was for the non-windows users. Once those fixes are in, we could look into a release schedule for 4.5.0, possibly aiming for a release in the first few days of 2025. Philipp |
From: Philipp K. K. <pk...@sp...> - 2024-08-18 06:45:26
|
Am 18.08.24 um 06:35 schrieb Erik Petrich: > > /home/sdcc-builder/build/sdcc-build/orig/sdcc/src/f8/gen.c: In function > ‘genRightShift’: > /home/sdcc-builder/build/sdcc-build/orig/sdcc/src/f8/gen.c:5364:7: > error: a label can only be part of a statement and a declaration is not > a statement > […] > > Looks like some sort of portability issue with the f8 code that was > merged in on August 4. Thanks for having a look. That's my fault: labels before declarations are an ISO C23 feature, but SDCC is supposed to be written in ISO C17. I fixed it today. Philipp |
From: Erik P. <epe...@iv...> - 2024-08-18 04:54:07
|
On Sat, 2024-08-17 at 18:38 +0200, Philipp Klaus Krause wrote: > Accordingto the snapshots page, we haven't had 32-bit GNU/Linux or > Windows Snapshots for two weeks. > > Anyone know more about the issue? > > Philipp /home/sdcc-builder/build/sdcc-build/orig/sdcc/src/f8/gen.c: In function ‘genRightShift’: /home/sdcc-builder/build/sdcc-build/orig/sdcc/src/f8/gen.c:5364:7: error: a label can only be part of a statement and a declaration is not a statement bool xl_dead = regDead (XL_IDX, ic) && (premoved_count ? false : (right->aop->regs[XL_IDX] < 0)); ^ /home/sdcc-builder/build/sdcc-build/orig/sdcc/src/f8/gen.c:5365:7: error: expected expression before ‘_Bool’ bool xh_dead = regDead (XH_IDX, ic) && (right->aop->regs[XH_IDX] < 0 || premoved_count); ^ /home/sdcc-builder/build/sdcc-build/orig/sdcc/src/f8/gen.c:5375:45: error: ‘xh_dead’ undeclared (first use in this function) genMove (shiftop, left->aop, xl_dead, xh_dead, y_dead, false); ^~~~~~~ /home/sdcc-builder/build/sdcc-build/orig/sdcc/src/f8/gen.c:5375:45: note: each undeclared identifier is reported only once for each function it appears in <builtin>: recipe for target 'gen.o' failed make[5]: *** [gen.o] Error 1 make[5]: Target 'all' not remade because of errors. Makefile:57: recipe for target 'f8/port.a' failed make[4]: *** [f8/port.a] Error 2 make[4]: Target 'all' not remade because of errors. Makefile:153: recipe for target 'sdcc-cc' failed make[3]: *** [sdcc-cc] Error 2 make[3]: Target 'sdcc' not remade because of errors. components/sdcc.mk:41: recipe for target 'sdcc-build' failed make[2]: *** [sdcc-build] Error 2 Looks like some sort of portability issue with the f8 code that was merged in on August 4. Erik |
From: Philipp K. K. <pk...@sp...> - 2024-08-17 16:51:08
|
Am 16.08.24 um 12:12 schrieb Oleg Endo: > > On Fri, 2024-08-16 at 17:10 +0800, 月明风清 via sdcc-devel wrote: >> >> Acording to my work requirement, a small 8-bit mcu with 9bit RAM >> addr 13bit ROM addr,without banking. I use SDCC and gputils for >> it. I have tried a lot of. Recently, I did 2 LTO pass in gputils's >> linker: 1) remove unused global variable (initialized or >> uninitialized). 2) Reuse temporary ram variable accross different >> functions. In this pass , I construct the call-graph with main、 >> intterrupt0、interrupt1 as the root. when two functions are in one >> call-graph, they can share compiler allocated global ram >> variables. Great, it works. >> >> > > Wow, congratulations. I wish we had this working for other backends > of SDCC. Regarding the other backend, assuming we use the asxxxx linker: * I hadn't thought about the RAM reuse yet. Obviously this only matters to the ports that actually put local variables into RAM, as opposed to on the stack. But for thisports it could be quite useful. * The linker already can handle dependenices at the module level. And for libraries it can handle multiple modules per file. So we'd only have to get the linker to accept multiple modules per .rel file, and SDCC to split the .rel files into multiple modules. Still will be some work, including testing. Philipp |
From: Philipp K. K. <pk...@sp...> - 2024-08-17 16:40:49
|
Am 16.08.24 um 11:10 schrieb 月明风清 via sdcc-devel: > > Acording to my work requirement, a small 8-bit mcu with 9bit RAM addr > 13bit ROM addr,without banking. > I use SDCC and gputils for it. I have tried a lot of. > Recently, I did 2 LTO pass in gputils's linker: > 1) remove unused global variable (initialized or uninitialized). > 2) Reuse temporary ram variable accross different functions. > In this pass , I construct the call-graph with main、intterrupt0、 > interrupt1 as the root. when two functions are in one call-graph, they > can share compiler allocated global ram variables. > Great, it works. Sounds useful, though the SDCC pic ports are unmaintained. Did you submit your work to upstream gputils, e.g. via https://sourceforge.net/p/gputils/patches/? Philipp |
From: Philipp K. K. <pk...@sp...> - 2024-08-17 16:38:52
|
Accordingto the snapshots page, we haven't had 32-bit GNU/Linux or Windows Snapshots for two weeks. Anyone know more about the issue? Philipp |
From: Oleg E. <ole...@t-...> - 2024-08-16 10:12:56
|
On Fri, 2024-08-16 at 17:10 +0800, 月明风清 via sdcc-devel wrote: > > Acording to my work requirement, a small 8-bit mcu with 9bit RAM addr 13bit ROM addr,without banking. > I use SDCC and gputils for it. I have tried a lot of. > Recently, I did 2 LTO pass in gputils's linker: > 1) remove unused global variable (initialized or uninitialized). > 2) Reuse temporary ram variable accross different functions. > In this pass , I construct the call-graph with main、intterrupt0、interrupt1 as the root. when two functions are in one call-graph, they can share compiler allocated global ram variables. > Great, it works. > > Wow, congratulations. I wish we had this working for other backends of SDCC. Best regards, Oleg Endo |
From: <445...@qq...> - 2024-08-16 09:10:56
|
Acording to my work requirement, a small 8-bit mcu with 9bit RAM addr 13bit ROM addr,without banking. I use SDCC and gputils for it. I have tried a lot of. Recently, I did 2 LTO pass in gputils's linker: 1) remove unused global variable (initialized or uninitialized). 2) Reuse temporary ram variable accross different functions. In this pass , I construct the call-graph with main、intterrupt0、interrupt1 as the root. when two functions are in one call-graph, they can share compiler allocated global ram variables. Great, it works. 月明风清 445...@qq... |
From: Joel H. <jo...@ai...> - 2024-08-15 21:21:11
|
Hi Folks, I'm working on packaging SDCC 4.4.0 for Msys2/MINGW, and I'm having an issue with the build. The current issue I have is in regard to sdcc trying to execute sdcpp.exe during the build. I don't understand how this is meant to work, because bin/sdcpp is a shell script. However, sdcc when executing the preprocessor via sdcc_system(), tries to execute sdcpp.exe via system(), which wouldn't work even if the file name was correct. There must be a solution to this issue, because sdcc has Windows releases already, so can someone help me understand what I'm doing wrong here? Kind Regards Joel Holdsworth |
From: Philipp K. K. <pk...@sp...> - 2024-08-05 10:04:59
|
Dear SDCC developers, I intend to attempt another application for funding for some paid work on SDCC. Are any of you interested in participating? Philipp |
From: Steve S. <ste...@gm...> - 2024-08-02 16:33:34
|
Why not? I mean, it's not like someone will have too much expectations ;-) Therefore, if it doesn't impede any other arch, I don't see any reason not to. Cheers, -- Steve On Fri, Aug 2, 2024, 15:32 Philipp Klaus Krause <pk...@sp...> wrote: > The f8 is still a work in progress; the instruction set won't change > much, but the opcode map will. No hardware implementation exists. There > is Verilog code that can be used to have an f8 on two FPGA boards > (tested, can run simple programs, such as Drhystone and Whetstone). > Currently, the f8 port lives in the f8 branch (apart from uCsim in trunk > having f8 support). > Would it be ok to put the f8 port into trunk soon? > > Philipp > > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > -- Steve SCHNEPP |
From: Philipp K. K. <pk...@sp...> - 2024-08-02 13:32:00
|
The f8 is still a work in progress; the instruction set won't change much, but the opcode map will. No hardware implementation exists. There is Verilog code that can be used to have an f8 on two FPGA boards (tested, can run simple programs, such as Drhystone and Whetstone). Currently, the f8 port lives in the f8 branch (apart from uCsim in trunk having f8 support). Would it be ok to put the f8 port into trunk soon? Philipp |
From: Maarten B. <sou...@ds...> - 2024-07-17 09:05:50
|
Philipp Klaus Krause schreef op 2024-07-17 08:26: > Am 17.07.24 um 01:57 schrieb Small Device C Compiler (SDCC) SVN > repository: >> * device/lib/z80/__itoa.s, >> * device/lib/z80/__ltoa.s, >> * device/lib/z80/__mulsint2slong.s, >> * device/lib/z80/__strreverse.s, >> * device/lib/z80/__uitobcd.s, >> * device/lib/z80/abs.s, >> * device/lib/z80/atomic_flag_test_and_set.s, >> * device/lib/z80/crt0.s, >> * device/lib/z80/divmixed.s, >> * device/lib/z80/divsigned.s, >> * device/lib/z80/divunsigned.s, >> * device/lib/z80/memcpy.s, >> * device/lib/z80/memmove.s, >> * device/lib/z80/modmixed.s, >> * device/lib/z80/modsigned.s, >> * device/lib/z80/modunsigned.s, >> * device/lib/z80/mul.s, >> * device/lib/z80/mulchar.s, >> * device/lib/z80/setjmp.s, >> * device/lib/z80/strcpy.s, >> * device/lib/z80/strlen.s: added .module <name> & .optsdcc -mz80 >> sdcccall(1) >> […] >> * src/z80/main.c (_z80_genAssemblerStart): new, added to emit >> .optsdcc, >> includes calling convention >> * src/z80/mappings.i: added .optsdcc > > This means that we now get an "Internal Version Error" when trying to > link object files compiled with --sdcccall 1 to those compiled with > --sdcccall 0 Correct. > (or objects from asm source files without the explicit .optsdcc). Not correct. When there is no .optsdcc line the check is not performed. > IMO, this is problematic, since it breaks compatibility. In particular, > we previously supported such use-cases: > > test.c: > void f(void) __sdcccall(0); > > void main(void) > { > } > > test1.c: > void f(void) > { > } > > Compiling test.c with -sdcccall 1 (i.e. the default), while compiling > test1.c with --sdcccall 0. That is just plain stupid. I see no reason why SDCC should support that. But for those who really want this, there is already the option --no-optsdcc-in-asm which suppresses the .optsdcc line. > AFAIK, the main use case if libraries partially written in assembler to > the __sdcccalll(0) convention. By just adding __sdcccall(0) to > declarations in headers, these libraries were used in programs that > otherwise use the new default calling convention. > > Philipp Maarten |
From: Philipp K. K. <pk...@sp...> - 2024-07-17 06:27:05
|
Am 17.07.24 um 01:57 schrieb Small Device C Compiler (SDCC) SVN repository: > * device/lib/z80/__itoa.s, > * device/lib/z80/__ltoa.s, > * device/lib/z80/__mulsint2slong.s, > * device/lib/z80/__strreverse.s, > * device/lib/z80/__uitobcd.s, > * device/lib/z80/abs.s, > * device/lib/z80/atomic_flag_test_and_set.s, > * device/lib/z80/crt0.s, > * device/lib/z80/divmixed.s, > * device/lib/z80/divsigned.s, > * device/lib/z80/divunsigned.s, > * device/lib/z80/memcpy.s, > * device/lib/z80/memmove.s, > * device/lib/z80/modmixed.s, > * device/lib/z80/modsigned.s, > * device/lib/z80/modunsigned.s, > * device/lib/z80/mul.s, > * device/lib/z80/mulchar.s, > * device/lib/z80/setjmp.s, > * device/lib/z80/strcpy.s, > * device/lib/z80/strlen.s: added .module <name> & .optsdcc -mz80 sdcccall(1) > […] > * src/z80/main.c (_z80_genAssemblerStart): new, added to emit .optsdcc, > includes calling convention > * src/z80/mappings.i: added .optsdcc This means that we now get an "Internal Version Error" when trying to link object files compiled with --sdcccall 1 to those compiled with --sdcccall 0 (or objects from asm source files without the explicit .optsdcc). IMO, this is problematic, since it breaks compatibility. In particular, we previously supported such use-cases: test.c: void f(void) __sdcccall(0); void main(void) { } test1.c: void f(void) { } Compiling test.c with -sdcccall 1 (i.e. the default), while compiling test1.c with --sdcccall 0. AFAIK, the main use case if libraries partially written in assembler to the __sdcccalll(0) convention. By just adding __sdcccall(0) to declarations in headers, these libraries were used in programs that otherwise use the new default calling convention. Philipp |
From: Oleg E. <ole...@t-...> - 2024-07-15 05:22:44
|
On Sat, 2024-07-13 at 09:54 +0200, Maarten Brock wrote: > Oleg Endo schreef op 2024-07-09 04:00: > > On top of that, the linker doesn't even check for overlapping bank > > sections, > > and doesn't provide any feedback on the utilization of each bank. I've > > patched that in my local branch, which makes it a lot more practical. > > Are you sure? The linker is supposed to check against overlapping bank > sections. Well, some years ago, when I needed that functionality, I wrote a patch for the linker that is included in the SDCC codebase to do exactly that. Last time I checked (about 1 year ago) it still applied. There are several other issues regarding the banked code support which ought to work but are not. I guess nobody has been really using SDCC to make larger mcs51 applications. > And the utilization can be checked in the map file, I believe. > Yes, that's what I'm doing. Best regards, Oleg Endo |
From: Maarten B. <sou...@ds...> - 2024-07-13 07:54:30
|
Oleg Endo schreef op 2024-07-09 04:00: > On top of that, the linker doesn't even check for overlapping bank > sections, > and doesn't provide any feedback on the utilization of each bank. I've > patched that in my local branch, which makes it a lot more practical. Are you sure? The linker is supposed to check against overlapping bank sections. And the utilization can be checked in the map file, I believe. Kind regards, Maarten Brock |
From: Steve S. <ste...@gm...> - 2024-07-09 20:27:21
|
Using standard syntax is always better, indeed. -- Steve SCHNEPP |
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 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: 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: 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: 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 |