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
(16) |
Sep
(18) |
Oct
|
Nov
|
Dec
|
From: Erik P. <epe...@iv...> - 2024-09-20 06:15:01
|
On Thu, 2024-09-19 at 12:40 +0200, Philipp Klaus Krause wrote: > Accordign to the wiki, the compile farm machines building the Windows > snapshots use > > gcc (GCC) 11.2.1 20210728 (Red Hat 11.2.1-1), x86_64−w64−mingw32−gcc > (GCC) 10.3.0 > > and > > gcc (GCC) 6.3.0 i686−w64−mingw32−gcc (GCC) 6.3.0 > > But according to sdcc-cf/packages/build.ming*/Makefile > > we use some GCC 4.9.4. > > Which is correct? Can these versions be snychronized? It seems very > hard > to look into bugs like https://sourceforge.net/p/sdcc/bugs/3686/ and > https://sourceforge.net/p/sdcc/bugs/3714/ when not even knowing the > toolchain used to build, and what might introduce those DLL > dependencies, or where the DLLs might be on the system building the > Windows snapshots. > > Philipp The compiler versions on the wiki page are correct. I've had some difficulty building some newer versions of gcc and mingw32-gcc from source (at least new enough to support the dialect currently needed for SDCC) and have had to settle for pre-built distribution's binaries in some cases. For example, the 6.3.0 versions are from Debian 9. It appears that the x86_64-w64-mingw32-gcc 10.3.0 was successfully built from source; I will try to get its Makefile checked back in. Erik |
From: Philipp K. K. <pk...@sp...> - 2024-09-19 10:40:43
|
Accordign to the wiki, the compile farm machines building the Windows snapshots use gcc (GCC) 11.2.1 20210728 (Red Hat 11.2.1-1), x86_64−w64−mingw32−gcc (GCC) 10.3.0 and gcc (GCC) 6.3.0 i686−w64−mingw32−gcc (GCC) 6.3.0 But according to sdcc-cf/packages/build.ming*/Makefile we use some GCC 4.9.4. Which is correct? Can these versions be snychronized? It seems very hard to look into bugs like https://sourceforge.net/p/sdcc/bugs/3686/ and https://sourceforge.net/p/sdcc/bugs/3714/ when not even knowing the toolchain used to build, and what might introduce those DLL dependencies, or where the DLLs might be on the system building the Windows snapshots. Philipp |
From: Philipp K. K. <pk...@sp...> - 2024-09-10 05:08:13
|
Am 09.09.24 um 18:36 schrieb joel--- via sdcc-devel: > The Window port of sdcc currently relies upon Visual Studio. In that > build it has an additional executable: sdcpp.exe, instead of shell scripts. While there is MSVC infrastructure, it is out of date: https://sourceforge.net/p/sdcc/patches/477/ (if you know MSVC, please have a look at that patch). Our Windows snapshots and releases are built using mingw on a GNU/Linux host, similar to the GNU/Linux snapshots and releases: https://sourceforge.net/p/sdcc/wiki/HOWTO%20Make%20Snapshot%20Builds%20on%20the%20Developer%20Machine/ In that build process,the library is build using the SDCC on the host, and the mingw build is done in addition (in .sdcc_builder/local/${HOSTNAME}.mk enable the extra target using OTHERTARGETS=). It relies on tested versions on the cross-tools (in particular mingw-w64 or ming32). I've also experimented with an SDCC cross-build using native (i.e. from the distribution on the host system) cross-tools in the native branch. It currently builds sdcc, but on my Debian GNU/Linux testing system, the sdcc built that way currently is not reliable when run under wine (I get segfaults). Philipp |
From: Daniel F. <dan...@gm...> - 2024-09-09 21:49:50
|
On Mon, Sep 9, 2024 at 5:39 PM <jo...@ai...> wrote: > > Having it working on UNIX Msys2 would of course be welcome, and I > wouldn't expect it to be difficult given that sdcc has previously > successfully built for Cygwin. > > However, for my use case I do need a MinGW64 build because everything > else in my tool-chain and build system for the users I'm trying to > carter to, is handled using Windows paths not UNIX. > > Moreover, the Msys2 project heavily discourages submissions that are > Msys2 only. Compare the number of Msys2 packages and MinGW packages: > Maybe I have expressed myself incorrectly. When I mentioned MSYS2, I was talking about the MSYS2 project, not the particular MSYS2 environment which came with it. I don't particularly target MSYS2 shell for builds. What I'd like to do is to target the MINGW64 environment for building SDCC (and other tools). Here an explanation is needed: the MSYS2 project comes with a number of shells[1] (or environments) that people can use for their own needs. There is the MINGW64 shell which has a default setup to build 64bit binaries using the mingw-w64 toolchains one can install using pacman. There is also the MSYS2 shell itself which is a very basic shell. It is always active and all other shells inherit from it and add stuff on top of it[1]. IMHO, the MSYS2 shell is not the best option to build stuff and I only use it if other options do not work. > https://github.com/msys2/msys2-packages/ > https://github.com/msys2/MINGW-packages/ > > Msys2 is typically only for packages that absolutely cannot produce a > native Windows build. Currently that category would include SDCC, but it > is quite a limitation when compared to all other packages that have no > problem building for MINGW. Particularly given that there is a native > Windows build powered by Visual Studio. > That said, I never tried the Visual Studio build and I don't know how big (or small, if any) is the effort to fix it and generate a package. IMHO, targeting the MINGW64/MSYS2 environment is a great idea because we can use the POSIX environment to build a completely functional Windows applications and use the awesome pacman system to distribute the package. This makes it really easy for users to install and use SDCC for development. > I don't completely understand how the Visual Studio build compares to > the AutoTools build, but it seems to me that it should be possible to > produce a Windows-native build on AutoTools somehow. Maybe the shortest and painless path to this is to use the MINGW64 shell from MSYS2 project for building the tools and then generating an installer or something for the binaries and other assets produced. This is the approach used by e.g. Inkscape and a number of other software packages [2]. Key point here is that the toolchain produced with MINGW64 from MSYS2 project does not need to be used from the MINGW64 shell. It can be used in the standard cmd.exe shell without problems but it also can be used in the MINGW64 shell itself which is a great environment for developers. I also like the fact that SDCC can be packaged as a pacman package and then installed using pacman. [1]https://www.msys2.org/docs/environments/ [2]https://www.msys2.org/docs/who-is-using-msys2/ > > Joel > > > Best regards, -- Daniel "Let us change our traditional attitude to the construction of programs. Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do." (Donald Knuth) "Yes, technogeeks can be funny, even if only to each other." (http://www.boogieonline.com/revolution/science/humor/)" "Man is driven to create; I know I really love to create things. And while I'm not good at painting, drawing, or music, I can write software." (Yukihiro Matsumoto, a.k.a. ``Matz'') |
From: <jo...@ai...> - 2024-09-09 21:04:41
|
Having it working on UNIX Msys2 would of course be welcome, and I wouldn't expect it to be difficult given that sdcc has previously successfully built for Cygwin. However, for my use case I do need a MinGW64 build because everything else in my tool-chain and build system for the users I'm trying to carter to, is handled using Windows paths not UNIX. Moreover, the Msys2 project heavily discourages submissions that are Msys2 only. Compare the number of Msys2 packages and MinGW packages: https://github.com/msys2/msys2-packages/ https://github.com/msys2/MINGW-packages/ Msys2 is typically only for packages that absolutely cannot produce a native Windows build. Currently that category would include SDCC, but it is quite a limitation when compared to all other packages that have no problem building for MINGW. Particularly given that there is a native Windows build powered by Visual Studio. I don't completely understand how the Visual Studio build compares to the AutoTools build, but it seems to me that it should be possible to produce a Windows-native build on AutoTools somehow. Joel On 2024-09-09 11:23, Daniel Franzini wrote: > IMHO, one can get very high quality builds using MSYS2. It is stable > and highly compatible with the standard POSIX shells like bash. > > It is used to create Windows builds for a number of programs. > > That said, I don't think it is an easy task to just "remove" these > scripts since they play a role in a bigger system to build the entire > SDCC toolchain. This is why I'm in favor of using MSYS/MINGW64 to > build and package SDCC for Windows. It has a number of advantages like > generating native builds, its shell can be integrated into IDEs and > editors (e.g. VSCode), it is far better than Cygwin, we can re-use > large portions of the build and adapt tiny bits where needed. > > I already tried to build SDCC in MSYS2/MINGW64 and I got small errors > that I think I can fix. If I succeed, I will send a patch or > instructions here. > > > Thank you. > > Daniel > > On Mon, Sep 9, 2024 at 1:36 PM <jo...@ai...> wrote: >> >> Hi Daniel, >> >> Thank you for your message. It's been a few weeks since I spent time >> on >> it. Mostly I was just exploring. >> >> I want to create a MingW native build of sdcc, not a fake UNIX build >> as >> you would get with a Cygwin/Msys2 build. >> >> The core issue is that, of course, on Windows you can't just "chmod >> +x" >> a bash script, and have it work just like a real executable." The >> MingW >> build currently fails because the build creates sdcpp from the >> bin/sdcpp.in template, but then when later stages of the Makefile try >> to >> use the freshly minted sdcc executable, this fails trying to call >> system() on a shell script. >> >> The Window port of sdcc currently relies upon Visual Studio. In that >> build it has an additional executable: sdcpp.exe, instead of shell >> scripts. >> >> So I think the solution is to simply remove the sdcpp shell script, >> and >> all the other shell script wrappers in bin/, and have the build >> process >> create executable for these files. >> >> I'm not yet clear on how much effort this would involve. >> >> Thanks >> Joel >> >> >> On 2024-09-09 06:30, Daniel Franzini wrote: >> > I'm willing to help with packaging for MSYS2. Can you please, share >> > what you have tried, what did work and what didn't work.... >> > >> > Which commands did you try to run? What is their output? >> > >> > >> > Also, Philip, is this the right place to carry such >> > interactions/discussions? >> > >> > >> > Thank you >> > >> > On Thu, Aug 15, 2024 at 6:21 PM Joel Holdsworth via sdcc-devel >> > <sdc...@li...> wrote: >> >> >> >> 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 >> >> >> >> >> >> _______________________________________________ >> >> sdcc-devel mailing list >> >> sdc...@li... >> >> https://lists.sourceforge.net/lists/listinfo/sdcc-devel >> > >> > >> > >> > -- >> > Daniel >> > >> > "Let us change our traditional attitude to the construction of >> > programs. Instead of imagining that our main task is to instruct a >> > computer what to do, let us concentrate rather on explaining to human >> > beings what we want a computer to do." (Donald Knuth) >> > >> > "Yes, technogeeks can be funny, even if only to each other." >> > (http://www.boogieonline.com/revolution/science/humor/)" >> > >> > "Man is driven to create; I know I really love to create things. And >> > while I'm not good at painting, drawing, or music, I can write >> > software." (Yukihiro Matsumoto, a.k.a. ``Matz'') >> > >> > >> > _______________________________________________ >> > sdcc-devel mailing list >> > sdc...@li... >> > https://lists.sourceforge.net/lists/listinfo/sdcc-devel |
From: Daniel F. <dan...@gm...> - 2024-09-09 18:23:37
|
IMHO, one can get very high quality builds using MSYS2. It is stable and highly compatible with the standard POSIX shells like bash. It is used to create Windows builds for a number of programs. That said, I don't think it is an easy task to just "remove" these scripts since they play a role in a bigger system to build the entire SDCC toolchain. This is why I'm in favor of using MSYS/MINGW64 to build and package SDCC for Windows. It has a number of advantages like generating native builds, its shell can be integrated into IDEs and editors (e.g. VSCode), it is far better than Cygwin, we can re-use large portions of the build and adapt tiny bits where needed. I already tried to build SDCC in MSYS2/MINGW64 and I got small errors that I think I can fix. If I succeed, I will send a patch or instructions here. Thank you. Daniel On Mon, Sep 9, 2024 at 1:36 PM <jo...@ai...> wrote: > > Hi Daniel, > > Thank you for your message. It's been a few weeks since I spent time on > it. Mostly I was just exploring. > > I want to create a MingW native build of sdcc, not a fake UNIX build as > you would get with a Cygwin/Msys2 build. > > The core issue is that, of course, on Windows you can't just "chmod +x" > a bash script, and have it work just like a real executable." The MingW > build currently fails because the build creates sdcpp from the > bin/sdcpp.in template, but then when later stages of the Makefile try to > use the freshly minted sdcc executable, this fails trying to call > system() on a shell script. > > The Window port of sdcc currently relies upon Visual Studio. In that > build it has an additional executable: sdcpp.exe, instead of shell > scripts. > > So I think the solution is to simply remove the sdcpp shell script, and > all the other shell script wrappers in bin/, and have the build process > create executable for these files. > > I'm not yet clear on how much effort this would involve. > > Thanks > Joel > > > On 2024-09-09 06:30, Daniel Franzini wrote: > > I'm willing to help with packaging for MSYS2. Can you please, share > > what you have tried, what did work and what didn't work.... > > > > Which commands did you try to run? What is their output? > > > > > > Also, Philip, is this the right place to carry such > > interactions/discussions? > > > > > > Thank you > > > > On Thu, Aug 15, 2024 at 6:21 PM Joel Holdsworth via sdcc-devel > > <sdc...@li...> wrote: > >> > >> 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 > >> > >> > >> _______________________________________________ > >> sdcc-devel mailing list > >> sdc...@li... > >> https://lists.sourceforge.net/lists/listinfo/sdcc-devel > > > > > > > > -- > > Daniel > > > > "Let us change our traditional attitude to the construction of > > programs. Instead of imagining that our main task is to instruct a > > computer what to do, let us concentrate rather on explaining to human > > beings what we want a computer to do." (Donald Knuth) > > > > "Yes, technogeeks can be funny, even if only to each other." > > (http://www.boogieonline.com/revolution/science/humor/)" > > > > "Man is driven to create; I know I really love to create things. And > > while I'm not good at painting, drawing, or music, I can write > > software." (Yukihiro Matsumoto, a.k.a. ``Matz'') > > > > > > _______________________________________________ > > sdcc-devel mailing list > > sdc...@li... > > https://lists.sourceforge.net/lists/listinfo/sdcc-devel -- Daniel "Let us change our traditional attitude to the construction of programs. Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do." (Donald Knuth) "Yes, technogeeks can be funny, even if only to each other." (http://www.boogieonline.com/revolution/science/humor/)" "Man is driven to create; I know I really love to create things. And while I'm not good at painting, drawing, or music, I can write software." (Yukihiro Matsumoto, a.k.a. ``Matz'') |
From: <jo...@ai...> - 2024-09-09 16:36:50
|
Hi Daniel, Thank you for your message. It's been a few weeks since I spent time on it. Mostly I was just exploring. I want to create a MingW native build of sdcc, not a fake UNIX build as you would get with a Cygwin/Msys2 build. The core issue is that, of course, on Windows you can't just "chmod +x" a bash script, and have it work just like a real executable." The MingW build currently fails because the build creates sdcpp from the bin/sdcpp.in template, but then when later stages of the Makefile try to use the freshly minted sdcc executable, this fails trying to call system() on a shell script. The Window port of sdcc currently relies upon Visual Studio. In that build it has an additional executable: sdcpp.exe, instead of shell scripts. So I think the solution is to simply remove the sdcpp shell script, and all the other shell script wrappers in bin/, and have the build process create executable for these files. I'm not yet clear on how much effort this would involve. Thanks Joel On 2024-09-09 06:30, Daniel Franzini wrote: > I'm willing to help with packaging for MSYS2. Can you please, share > what you have tried, what did work and what didn't work.... > > Which commands did you try to run? What is their output? > > > Also, Philip, is this the right place to carry such > interactions/discussions? > > > Thank you > > On Thu, Aug 15, 2024 at 6:21 PM Joel Holdsworth via sdcc-devel > <sdc...@li...> wrote: >> >> 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 >> >> >> _______________________________________________ >> sdcc-devel mailing list >> sdc...@li... >> https://lists.sourceforge.net/lists/listinfo/sdcc-devel > > > > -- > Daniel > > "Let us change our traditional attitude to the construction of > programs. Instead of imagining that our main task is to instruct a > computer what to do, let us concentrate rather on explaining to human > beings what we want a computer to do." (Donald Knuth) > > "Yes, technogeeks can be funny, even if only to each other." > (http://www.boogieonline.com/revolution/science/humor/)" > > "Man is driven to create; I know I really love to create things. And > while I'm not good at painting, drawing, or music, I can write > software." (Yukihiro Matsumoto, a.k.a. ``Matz'') > > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel |
From: Daniel F. <dan...@gm...> - 2024-09-09 14:33:04
|
I'm also in favor of adding it. It doesn't hurt in either SVN or Git sides and helps makes things more organized. Daniel On Mon, Sep 9, 2024 at 10:32 AM Atirut Wattanamongkol <ati...@gm...> wrote: > > I'm not very involved with SDCC as an end-user, but I'm hugely in favor of this because I personally use Git and SDCC's Git mirror. > > On Mon, Sep 9, 2024 at 2:15 AM Alex <ale...@gm...> wrote: >> >> My recommendation would be "yes", because of how git-ignore operates. If we decide to ignore files down in the directory tree, then we need more .gitignore files, and that will slowly diverge the mirror. >> >> Alex >> >> >> On Sun, Sep 8, 2024, 6:11 PM Philipp Klaus Krause <pk...@sp...> wrote: >>> >>> We have our svn repo, and an offial git mirror, but no .gitignore. This >>> patch https://sourceforge.net/p/sdcc/patches/477/ includes a .gitignore. >>> What do you think about putting it into svn? >>> >>> 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 > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel -- Daniel "Let us change our traditional attitude to the construction of programs. Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do." (Donald Knuth) "Yes, technogeeks can be funny, even if only to each other." (http://www.boogieonline.com/revolution/science/humor/)" "Man is driven to create; I know I really love to create things. And while I'm not good at painting, drawing, or music, I can write software." (Yukihiro Matsumoto, a.k.a. ``Matz'') |
From: Felix S. <fe...@sa...> - 2024-09-09 14:28:04
|
On Sun, Sep 08, 2024 at 09:15:06PM +0200, Alex wrote: > My recommendation would be "yes", because of how git-ignore operates. If we > decide to ignore files down in the directory tree, then we need more > .gitignore files, and that will slowly diverge the mirror. Hi all. What are you trying to achieve? What is going to diverge? Remember for historic reasons, SDCC has the autogenerated build system under version control, so there are no files that technically need ignoring. If you build SDCC, as in $ mkdir build $ cd build $ ../configure $ make all the build artifacts will end up in "build". This is a direcory, your .gitignore does not know about, and should not. Instead do $ mkdir build $ cd build $ echo \* > .gitignore $ ../configure $ make . Arguably, "configure" should take care of it, but is it worth it? Please send a patch. Remember to adjust the distclean target as well. cheers felix |
From: Atirut W. <ati...@gm...> - 2024-09-09 13:32:38
|
I'm not very involved with SDCC as an end-user, but I'm hugely in favor of this because I personally use Git and SDCC's Git mirror. On Mon, Sep 9, 2024 at 2:15 AM Alex <ale...@gm...> wrote: > My recommendation would be "yes", because of how git-ignore operates. If > we decide to ignore files down in the directory tree, then we need more > .gitignore files, and that will slowly diverge the mirror. > > Alex > > On Sun, Sep 8, 2024, 6:11 PM Philipp Klaus Krause <pk...@sp...> wrote: > >> We have our svn repo, and an offial git mirror, but no .gitignore. This >> patch https://sourceforge.net/p/sdcc/patches/477/ includes a .gitignore. >> What do you think about putting it into svn? >> >> 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 > |
From: Daniel F. <dan...@gm...> - 2024-09-09 13:30:42
|
I'm willing to help with packaging for MSYS2. Can you please, share what you have tried, what did work and what didn't work.... Which commands did you try to run? What is their output? Also, Philip, is this the right place to carry such interactions/discussions? Thank you On Thu, Aug 15, 2024 at 6:21 PM Joel Holdsworth via sdcc-devel <sdc...@li...> wrote: > > 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 > > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel -- Daniel "Let us change our traditional attitude to the construction of programs. Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do." (Donald Knuth) "Yes, technogeeks can be funny, even if only to each other." (http://www.boogieonline.com/revolution/science/humor/)" "Man is driven to create; I know I really love to create things. And while I'm not good at painting, drawing, or music, I can write software." (Yukihiro Matsumoto, a.k.a. ``Matz'') |
From: Alex <ale...@gm...> - 2024-09-08 19:15:25
|
My recommendation would be "yes", because of how git-ignore operates. If we decide to ignore files down in the directory tree, then we need more .gitignore files, and that will slowly diverge the mirror. Alex On Sun, Sep 8, 2024, 6:11 PM Philipp Klaus Krause <pk...@sp...> wrote: > We have our svn repo, and an offial git mirror, but no .gitignore. This > patch https://sourceforge.net/p/sdcc/patches/477/ includes a .gitignore. > What do you think about putting it into svn? > > Philipp > > > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > |
From: Philipp K. K. <pk...@sp...> - 2024-09-08 16:11:05
|
We have our svn repo, and an offial git mirror, but no .gitignore. This patch https://sourceforge.net/p/sdcc/patches/477/ includes a .gitignore. What do you think about putting it into svn? Philipp |
From: Philipp K. K. <pk...@sp...> - 2024-09-04 08:31:11
|
P.S.: You might also want to have a look at https://sourceforge.net/p/sdcc/bugs/3589/ |
From: Philipp K. K. <pk...@sp...> - 2024-09-04 08:28:31
|
Am 15.08.24 um 22:38 schrieb Joel Holdsworth via sdcc-devel: > 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 Dear Joel, thanks for helping make SDCC more available to Windows users. SDCC developers these days are not really familiar with Windows, so it is hard for us to provide those Windows builds, and IMO, the worst bugs discovered after the SDCC 4.4.0 release were related to Windows packaging issues. On the other hand, AFAIK, about half of SDCC users are on Windows. Felix is most familiar with the preprocessor, but he doesn't use Windows, either. Our current Windows releases are built using the snapshot build process: https://sourceforge.net/p/sdcc/wiki/HOWTO%20Make%20Snapshot%20Builds%20on%20the%20Developer%20Machine/ Philipp |
From: Oleg E. <ole...@t-...> - 2024-09-04 06:35:09
|
On Wed, 2024-09-04 at 08:24 +0200, Philipp Klaus Krause wrote: > Am 29.08.24 um 14:25 schrieb Oleg Endo: > > 7) Automatic shortening of mcs51 lcall / ljmp to acall / ajmp. > > I think This would be much harder. For this, the linker needs much more > understanding of the code than for the other features requested so far. > After all, optimizing a lcall / ljmp in the middle of some code into > acall / ajmp changes code size, and thus requires changes in relative > jumps over that place. > Yes, of course linker relaxation can be a tricky thing to do. If the linker does the relaxation, it will require the linker to parse and understand the whole program (to catch cases as you mention above). The alternative is to compile the whole software effectively as a single unit (LTO style) and let the compiler figure out whether ajmp/acall would be in range or not. Best regards, Oleg Endo |
From: Philipp K. K. <pk...@sp...> - 2024-09-04 06:24:18
|
Am 29.08.24 um 14:25 schrieb Oleg Endo: > 7) Automatic shortening of mcs51 lcall / ljmp to acall / ajmp. I think This would be much harder. For this, the linker needs much more understanding of the code than for the other features requested so far. After all, optimizing a lcall / ljmp in the middle of some code into acall / ajmp changes code size, and thus requires changes in relative jumps over that place. Philipp |
From: Oleg E. <ole...@t-...> - 2024-09-03 02:28:40
|
On Mon, 2024-07-15 at 14:22 +0900, Oleg Endo wrote: > > 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. > > Let me quote from the SDCC manual: ----- To create a function that can be called from another bank it requires the keyword __banked. The caller must see this in the prototype of the callee and the callee needs it for a proper return. Called functions within the same bank as the caller do not need the __banked keyword nor do functions in the common area. Beware: SDCC does not know or check if functions are in the same bank. This is your responsibility! ----- When linking your objects you need to tell the linker where to put your segments. To do this you use the following command line option to SDCC: -Wl- b BANK1=0x18000 (See 3.3.5). This sets the virtual start address of this segment. It sets the banknumber to 0x01 and maps the bank to 0x8000 and up. The linker will not check for overflows, again this is your responsibility. ----- >From a user's perspective, this is poor man's tech and not very inviting, to put it mildly. Lots of room for improvement. Perhaps yet another reason why folks choose other commercial compilers over SDCC. Best regards, Oleg Endo |
From: Oleg E. <ole...@t-...> - 2024-08-29 12:25:27
|
On Tue, 2024-07-09 at 11:00 +0900, Oleg Endo wrote: > > 6) Automatic "layout" of the flash space for banked vs. non-banked functions > (and constant .rodata objects). > > As of now, writing larger mcs51 banked software with SDCC is tedious. Need > to specify the code bank number manually for each translation unit. Banks > can't be mixed inside a translation unit, which makes the software source > unnecessarily convoluted. > > 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. > 7) Automatic shortening of mcs51 lcall / ljmp to acall / ajmp. Best regards, Oleg Endo |
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 |