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: Oleg E. <ole...@t-...> - 2024-04-10 05:57:23
|
On Tue, 2024-04-09 at 09:00 +0200, Steve Schnepp wrote: > On Tue, Apr 9, 2024, 01:56 Oleg Endo <ole...@t-...> wrote: > > > which will put each function and data item into its own ELF section. Then > > the linker can figure out which sections are used and which ones are not > > used. > > With sdcc, a common way to optimize it is to have as many .c files as items one wants to be pruned. > > I think the stdlib is implemented that way. > That's right. Traditionally it's been like that -- the linker would eliminate whole translation units, if they're determined to be not referenced. For this reason the runtime library implementations usually follow the 1 function per 1 .c file pattern. Depending on the application structure it might make the code difficult to work with if all data variables are split out into single .c files. But yeah, that's the only working thing on SDCC at this time. Best regards, Oleg Endo |
From: Steve S. <ste...@gm...> - 2024-04-09 07:00:43
|
On Tue, Apr 9, 2024, 01:56 Oleg Endo <ole...@t-...> wrote: which will put each function and data item into its own ELF section. Then > the linker can figure out which sections are used and which ones are not > used. > With sdcc, a common way to optimize it is to have as many .c files as items one wants to be pruned. I think the stdlib is implemented that way. Cheers, -- Steve SCHNEPP |
From: Oleg E. <ole...@t-...> - 2024-04-08 23:55:49
|
Hi! On Sun, 2024-04-07 at 08:31 +0800, 月明风清 via sdcc-devel wrote: > I am using SDCC4.2.0 for a pic18 like single-chip-processor, but I found that the SDCC can not distinguish the global variable define in one file , but it was not used at all. > The compiler still allocated RAM location for this kind global variable. > SDCC cannnot do across .c file analysis. How to do with this situation?? > Your assessment is correct. SDCC does not implement this type of optimization. Other compiler tools like GCC have options like -ffunction-sections -fdata-sections which will put each function and data item into its own ELF section. Then the linker can figure out which sections are used and which ones are not used. In addition there is also things like LTO which can be helpful. In case of SDCC, it will likely require the modification of the compiler/assembler/linker tools. Since the compiler only sees one translation unit (.c file) at a time, this optimization has to be eventually implemented by the linking step. Best regards, Oleg Endo |
From: Felix S. <fe...@sa...> - 2024-04-07 08:49:00
|
On Thu, Apr 04, 2024 at 04:16:44AM -0000, Eli Schwartz wrote: > I got this error: [..] > cc1_dummies.cc:316:5: note: type ‘int’ should match type ‘bool’ > 316 | int after_memory_report; > | ^ [..] Thanks for the bug report. I have fixed those in the "flto" branch (on git). Let me know if it works for you, i'll try to push it into svn/trunk.. If you don't like git, you can download a patch here [1], and maybe somewhere here [2]. best wishes felix PS: replies to tickets don't work, CC: sdcc-devel. [1] https://codeberg.org/sdcc/code/commit/64222519792d174eb7ce4524bb0f881cd89d22da.diff [2] https://sourceforge.net/p/sdcc/git-mirror/commit_browser |
From: <445...@qq...> - 2024-04-07 00:31:37
|
Hi, I am using SDCC4.2.0 for a pic18 like single-chip-processor, but I found that the SDCC can not distinguish the global variable define in one file , but it was not used at all. The compiler still allocated RAM location for this kind global variable. SDCC cannnot do across .c file analysis. How to do with this situation?? 月明风清 445...@qq... |
From: Philipp K. K. <pk...@sp...> - 2024-04-06 10:27:29
|
>> Anyway, all this is just my experience and resulting opinion; I am NOT the >> maintainer/owner of SDCC [..] > > Neither am I. Do we even have the concept of an owner or maintainer of SDCC as a whole? We do have maintainers of individual ports, and a maintainer of the simulators. I guess Felix is by now practically the maintainer of the preprocessor. Philipp |
From: Felix S. <fe...@sa...> - 2024-04-05 18:35:21
|
On Fri, Apr 05, 2024 at 07:27:51PM +0200, Ger Hobbelt wrote: > I'm perfectly okay with Codeberg. [..] Thanks for your supportive words. I've just installed cronjob that pushes a couple of times a day. I might end up adding more immediate sync with webhook or so. I do not need it right now -- don't hold your breath. > Anyway, all this is just my experience and resulting opinion; I am NOT the > maintainer/owner of SDCC [..] Neither am I. Whether or not a maintainer will consider a patch presented as a git commit remains entirely up to them. Make it easy. Squash and rebase to trunk. Write a useful commit message, be kind, stay calm... Best wishes felix |
From: Ger H. <ge...@ho...> - 2024-04-05 18:12:53
|
🥳 forked repo with the patches now up on codeberg: https://codeberg.org/GerHobbelt/code same branchnames as mentioned in the tickets. Met vriendelijke groeten / Best regards, Ger Hobbelt -------------------------------------------------- web: http://www.hobbelt.com/ http://www.hebbut.net/ mail: ge...@ho... mobile: +31-6-11 120 978 -------------------------------------------------- On Thu, Apr 4, 2024 at 4:06 PM Felix Salfelder <fe...@sa...> wrote: > On Thu, Apr 04, 2024 at 03:15:06PM +0200, Felix Salfelder wrote: > > On Wed, Apr 03, 2024 at 08:40:46PM -0000, Ger Hobbelt wrote: > > > (And if you find time to migrate out of SF into some git-based realm > :+1: ;-) ) > > > > SDCC is already mirrored to codeberg [1] for the reasons you outlined. > > > > Best wishes > > felix > > > > [1] https://codeberg.org/sdcc/ > > Resending to sdc...@li.... For some other reason my > previous message did not come through, maybe this one does.. > > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > |
From: Ger H. <ge...@ho...> - 2024-04-05 17:28:17
|
I'm perfectly okay with Codeberg. If you check them out quickly, about page and via internet, they sound legit. No red flags for me, at least. Extra points in their favour: they're not USA based or -backed and they're rather more principled about open source than I am. :+1: It still will cost a day to drive to Berlin and back again, so that'll be a B&B and expenses at least, but hey, in Internet terms, they live around the corner from this Dutchie. The drawback is of course their obvious inability to throw money at it like github and microsoft did as they live off support/donations and we all know what that implies: you're not getting rich and you won't make the top entry at Google Search. Which sounds like the equivalent of "retarded" to many, but not to me. Anyway, @Felix: please don't say git fork (+ pull with or without pull request) is a "work-around" for patches ;-)) for fork+pull[req] is much smoother going: patches haven't worked for me for 30+ years, "merge conflicts" (3 way merge) when orchestrated via patch files is, in my continual experience, a nightmare with no sweaty wake-up moment to make it stop. cvs and svn never did well for me either; both worse than the much-appreciated OG (`rcs`, back in the day. good memories with that one.) and SF was always a bit wonky but has, for me at least, become the equivalent of showing some remarkable not-too-recently demised animal to a lady: you know there's gonna be the sound of ewwww! GitLab is a very bad UX for me; it's more expensive than github and has zero(0) features that I appreciate in/on github. Okay, that's exeggering, apologies. They have one(1): private (non-public) repositories. So I'ld rather go with some principled fellows like the codeberg bunch, who've been around for a while already -- I first heard of them around the time github was being paraded in front of Microsoft and some more-principled-than-me folks decided to pick up and leave before the new management would enter with their equivalent of a shiny white toilet sink. I am happy to report git is a huge improvement over rcs (contrary to the others I've used: cvs, svn, perforce, vss, plus a short stint with hg and some stuff I can't even recall the name of any more: mindblock) and the fork + pull/pullreq approach is way easier on the brain when you track repos or otherwise are faced regularly with 3-way merges a.k.a. merge conflicts. When git came out, I jumped on that ship pretty soon after git-for-windows came out. Of course I say this while today I'm tooled up to the nines when it comes to git: I'm largely Windows based as a dev, always been, and the combo TortoiseGit (GUI) plus Beyond Compare (happy commercial customer there for 20-odd years now!) as the merge tool on top of rcs, then git, is keeping it pretty fast and generally low brain load, particularly 3-way merges with git are much easier than with any other rcs I've touched. Plus I've got in-house scripts so I type very few direct git commands any more. Contrast that with me processing patches or even other git toolchains, like I see a lot of peeps do on Linux. nuh-uh. Anyway, all this is just my experience and resulting opinion; I am NOT the maintainer/owner of SDCC and merely a few-lines-today contributor who wants to take SDCC on a local 8-bit MCU R&D ride this year, so the best thing to have and do, is use the kit that the maintainer (Felix) feels (very) comfortable with, for he's got the continued effort to make and little thanks to show for it, so it's his preferences that matter. Sounded on SF like he likes patches, so patchfiles it was to be. I try to influence him above but that's the end of my reach and as anyone can read, shop around and compare: my 30+ years experience isn't necessarily identical to any of yours. About codeberg: thanks for reminding me they are still around; I'm all-in on github, but I emphatically don't like their increasingly caricature big-corp/MS attitude when there's a little scare that might possibly reflect on them thanks to human nature (panic behaviour): they shut down and lock out repos and people at the first hint of trouble and then third-party investigation and recovery for those involved in the aftermath is a shitshow, so I'm not leaving there but I am really interested in survival strategies in case someone overthere decides they feel triggered, so that points me at codeberg again (and a few others of the same cloth, but the others I've ran into are all USA-based and that's not exactly a compliment today. So the summer resolution here is considering donating to the CB guys and copying my main stuff over. Not a solution for my commercial/private repos yet, but we'll see. This won't be solved this week, anyway. Codeberg: As they have different funding and different ethics/principles vs. github, I don't mind if they currently possibly lack a bunch of github features that I like to have, something that I /do/ mind about with gitlab as those are just another commercial party not significantly different from github, ethics/riskwise. Anyway, that's my perspective. I'll shut up exchanging my frank view. :-) Thanks for taking care of SDCC, Met vriendelijke groeten / Best regards, Ger Hobbelt (who used the [i_a] nick back in antiquity on SF and elsewhere.) PS: periodic updates from svn into git are doable, but not easy to get right if you like nice commit histories. I've done it a couple of times but you need a Linux rig with all the tooling and some serious patience to get it right or you end up with weird commit history logs and/or other crap. Not my favorite thing to do. github's on-line web interface option to do this worked well for one-offs but is being dropped or has already dropped from the sky this month (April 2024). The fact that SF didn't make this transition option easy for the SF users from early on when git clearly became the major goto guy for RCS (DVCS) is not giving me a lot of confidence that it is simple and smooth going overthere at SF today. Besides, SVN and GIT think completely differently about branches, etc. making it a one-way street anyway if you want to stay sane. Picking up forks/pullreqs from the likes of me would then require some sort of spitting out patch sequence mechanism (`git diff, git log, git format-patch`), which is exactly what I did for this ticket. Taking that patch-producing burden from the ticket-writing SDCC dev loads extra work onto the maintainer, which is the wrong approach. Either SDCC decides one day to hop over to The Git Side and do git/pulls/pullreqs, or it's patches like today that remain the safest / lowest-cost bet maintainer-side, AFAICT. -------------------------------------------------- web: http://www.hobbelt.com/ http://www.hebbut.net/ mail: ge...@ho... mobile: +31-6-11 120 978 -------------------------------------------------- On Fri, Apr 5, 2024 at 3:49 PM Sam Wilson <sam...@gm...> wrote: > It shouldn't be too hard to simply import SVN history to git and push it > every night to github. > > Then just put a note to the effect of, "we won't accept pull requests > filed against this repository". But of course, we can still fork it there, > run CI/CD pipelines there, etcetera. That opens up the possibility that > someone wants to fork on github (or whatever) it to fix some issue or add a > feature. Such a fork can still be manually applied to the SVN repository. > Is this a viable strategy? > > On Fri, 5 Apr 2024 at 14:28, Felix Salfelder <fe...@sa...> wrote: > >> Apologies, I did not mean to re-open this discussion. >> >> In order to provide a non-experimental git repo, we need a system that >> performs the export. To keep the mirror on SF up to date, a "bot" >> account on SF is required, with the permission to push to it. None of >> this won't run on SF infrastructure, see [0,1]. >> >> cheers >> felix >> >> [0] >> https://sourceforge.net/p/sdcc/mailman/sdcc-devel/thread/05841bfc-2dc0-cd9d-b988-f0c1ccfa4f4c%40spth.de >> [1] https://sourceforge.net/p/forge/site-support/25239/ >> >> >> _______________________________________________ >> 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: Sam W. <sam...@gm...> - 2024-04-05 13:49:08
|
It shouldn't be too hard to simply import SVN history to git and push it every night to github. Then just put a note to the effect of, "we won't accept pull requests filed against this repository". But of course, we can still fork it there, run CI/CD pipelines there, etcetera. That opens up the possibility that someone wants to fork on github (or whatever) it to fix some issue or add a feature. Such a fork can still be manually applied to the SVN repository. Is this a viable strategy? On Fri, 5 Apr 2024 at 14:28, Felix Salfelder <fe...@sa...> wrote: > Apologies, I did not mean to re-open this discussion. > > In order to provide a non-experimental git repo, we need a system that > performs the export. To keep the mirror on SF up to date, a "bot" > account on SF is required, with the permission to push to it. None of > this won't run on SF infrastructure, see [0,1]. > > cheers > felix > > [0] > https://sourceforge.net/p/sdcc/mailman/sdcc-devel/thread/05841bfc-2dc0-cd9d-b988-f0c1ccfa4f4c%40spth.de > [1] https://sourceforge.net/p/forge/site-support/25239/ > > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > |
From: Felix S. <fe...@sa...> - 2024-04-05 13:27:36
|
Apologies, I did not mean to re-open this discussion. In order to provide a non-experimental git repo, we need a system that performs the export. To keep the mirror on SF up to date, a "bot" account on SF is required, with the permission to push to it. None of this won't run on SF infrastructure, see [0,1]. cheers felix [0] https://sourceforge.net/p/sdcc/mailman/sdcc-devel/thread/05841bfc-2dc0-cd9d-b988-f0c1ccfa4f4c%40spth.de [1] https://sourceforge.net/p/forge/site-support/25239/ |
From: Steve S. <ste...@gm...> - 2024-04-05 12:43:24
|
(removing the ticket email address, as it's more relevant to devel@ anyway) While I do not want to start any hosting holy wars, here is my own food for thought. I also promise I won't discuss more than this email unless someone asks something about it :-) I would argue that no-one knows codeberg, even less so about this initiative. If the real purpose is to make it easier for anyone to contribute, I'd argue that the network effect would be much bigger if we leverage github, as imperfect as it may be. My point is more "either move to git on SF.net or directly bite the bullet and move towards github". Using an obscure hosting will just add more obscurity to this already obscure SDCC project ;-). I mean, many use sdcc without knowing it, but contributing to it is rather unappealing for newcomers. That fact may be wanted. Then let's not change anything, SVN is perfectly fine. Or do we want to attract more casual contributors such as me that we might convert to long term ones? For that, one cannot really fight against github, or at least gitlab if you really want to avoid github, because in the end, it's all about the "network effect". Using the mailing lists is something I don't do as much as before, and feels now much less natural to me, especially if that's the only way to interact with other fellow devs. But since I'm interested (while not skilled) I did force myself to it since SF.net isn't exactly unknown either. Not super modern, but not unknown. Yet I won't create yet another account on codeberg, which I don't have a clue on who is owning it, and I won't really bother to be honest. Yet, as said, I might not be the target of wanted contributors. Cheers, -- Steve Schnepp On Fri, Apr 5, 2024 at 1:30 PM Felix Salfelder <fe...@sa...> wrote: > On Fri, Apr 05, 2024 at 12:54:21PM +0200, Steve Schnepp wrote: > > My naive question is "why another git hoster?" can't we leverage the > SF.net > > git repo ? > > I do not have much issues with SF.net hosting outside that it uses SVN > ;-) > > Here's some food for thought. > > Without write permissions you can't use a git repo to share patches. > Codeberg allows private clones as a kind of workaround for this, and has > a "clone repo" button that streamlines the use. > > Also, in order to get in touch with SDCC devs via sf, you need to accept > sf terms and conditions and privacy policy. This is not needed when > using codeberg. > > I would expect the mailing list to accept messages from non-subscribers, > and allows attachments. Note how this will only help contributors > willing and able to deal with patches manually, and also use email. > > cheers > felix > > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > |
From: Felix S. <fe...@sa...> - 2024-04-05 11:30:01
|
On Fri, Apr 05, 2024 at 12:54:21PM +0200, Steve Schnepp wrote: > My naive question is "why another git hoster?" can't we leverage the SF.net > git repo ? > I do not have much issues with SF.net hosting outside that it uses SVN ;-) Here's some food for thought. Without write permissions you can't use a git repo to share patches. Codeberg allows private clones as a kind of workaround for this, and has a "clone repo" button that streamlines the use. Also, in order to get in touch with SDCC devs via sf, you need to accept sf terms and conditions and privacy policy. This is not needed when using codeberg. I would expect the mailing list to accept messages from non-subscribers, and allows attachments. Note how this will only help contributors willing and able to deal with patches manually, and also use email. cheers felix |
From: Steve S. <ste...@gm...> - 2024-04-05 10:55:08
|
My naive question is "why another git hoster?" can't we leverage the SF.net git repo ? I do not have much issues with SF.net hosting outside that it uses SVN ;-) -- Steve Schnepp On Fri, Apr 5, 2024 at 12:32 PM Ger Hobbelt <ge...@ho...> wrote: > Cool! Hadn't found the SDCC codeberg repo on my own, sorry. Didn't pop up > on my Google search radar. :-( > > Anyway, message received. Excellent. > > Cheers, > > Ger > > > On Thu, 4 Apr 2024, 16:06 Felix Salfelder, <fe...@sa...> wrote: > >> On Thu, Apr 04, 2024 at 03:15:06PM +0200, Felix Salfelder wrote: >> > On Wed, Apr 03, 2024 at 08:40:46PM -0000, Ger Hobbelt wrote: >> > > (And if you find time to migrate out of SF into some git-based realm >> :+1: ;-) ) >> > >> > SDCC is already mirrored to codeberg [1] for the reasons you outlined. >> > >> > Best wishes >> > felix >> > >> > [1] https://codeberg.org/sdcc/ >> >> Resending to sdc...@li.... For some other reason my >> previous message did not come through, maybe this one does.. >> >> >> _______________________________________________ >> 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: Ger H. <ge...@ho...> - 2024-04-05 10:32:07
|
Cool! Hadn't found the SDCC codeberg repo on my own, sorry. Didn't pop up on my Google search radar. :-( Anyway, message received. Excellent. Cheers, Ger On Thu, 4 Apr 2024, 16:06 Felix Salfelder, <fe...@sa...> wrote: > On Thu, Apr 04, 2024 at 03:15:06PM +0200, Felix Salfelder wrote: > > On Wed, Apr 03, 2024 at 08:40:46PM -0000, Ger Hobbelt wrote: > > > (And if you find time to migrate out of SF into some git-based realm > :+1: ;-) ) > > > > SDCC is already mirrored to codeberg [1] for the reasons you outlined. > > > > Best wishes > > felix > > > > [1] https://codeberg.org/sdcc/ > > Resending to sdc...@li.... For some other reason my > previous message did not come through, maybe this one does.. > > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > |
From: Felix S. <fe...@sa...> - 2024-04-04 14:05:54
|
On Thu, Apr 04, 2024 at 03:15:06PM +0200, Felix Salfelder wrote: > On Wed, Apr 03, 2024 at 08:40:46PM -0000, Ger Hobbelt wrote: > > (And if you find time to migrate out of SF into some git-based realm :+1: ;-) ) > > SDCC is already mirrored to codeberg [1] for the reasons you outlined. > > Best wishes > felix > > [1] https://codeberg.org/sdcc/ Resending to sdc...@li.... For some other reason my previous message did not come through, maybe this one does.. |
From: Erik P. <epe...@iv...> - 2024-03-12 04:41:38
|
On Mon, 2024-03-11 at 16:04 +0100, Sebastien Lorquet wrote: > > Hello, > > Here it is in the svn book: > https://svnbook.red-bean.com/en/1.5/svn-book.pdf > > page 221: > > use-commit-times > Normally your working copy files have timestamps that reflect the > last time they were > touched by any process, whether your own editor or some svn > subcommand. This is > generally convenient for people developing software, because build > systems often look > at timestamps as a way of deciding which files need to be recompiled. > In other situations, however, it's sometimes nice for the working > copy files to have > timestamps that reflect the last time they were changed in the > repository. The svn ex- > port command always places these “last-commit timestamps” on trees > that it pro- > duces. By setting this config variable to yes, the svn checkout, svn > update, svn > switch, and svn revert commands will also set last-commit timestamps > on files that > they touch. > > Looks like this setting is to be defined in the subversion > configuration file at $HOME/.subversion/config > > Alternatively svn export should be used instead of checkout/update. > > Best regards > > Sebastien Thanks for tracking this down for me. My day job is keeping me quite busy lately, so this is helpful. I'll try to implement this in the snapshot generation / website update process this weekend. Erik > |
From: Sebastien L. <seb...@lo...> - 2024-03-11 15:21:53
|
Hello, Here it is in the svn book: https://svnbook.red-bean.com/en/1.5/svn-book.pdf page 221: use-commit-times Normally your working copy files have timestamps that reflect the last time they were touched by any process, whether your own editor or somesvnsubcommand. This is generally convenient for people developing software, because build systems often look at timestamps as a way of deciding which files need to be recompiled. In other situations, however, it's sometimes nice for the working copy files to have timestamps that reflect the last time they were changed in the repository. Thesvn ex- portcommand always places these “last-commit timestamps” on trees that it pro- duces. By setting this config variable toyes, thesvn checkout,svn update,svn switch, andsvn revertcommands will also set last-commit timestamps on files that they touch. Looks like this setting is to be defined in the subversion configuration file at $HOME/.subversion/config Alternatively svn export should be used instead of checkout/update. Best regards Sebastien Le 09/03/2024 à 10:04, Erik Petrich a écrit : > On Tue, 2024-03-05 at 10:21 +0100, Philipp Klaus Krause wrote: >> Am 05.03.24 um 07:00 schrieb Erik Petrich: >>> Yes, it updates using rsync with the --size-only parameter. >> What is the reason for the --size-only? A normal rsync would trigger >> if >> times or sizes change. Does something not under our control change >> the >> times? >> >> Philipp > I looked into the history hoping to find a comment when the option was > introduced, but the --size-only has been there since Borut's initial > check-in of both files that I've seen it used. > > Looking further, it seems that the default timestamp on files created > during the svn checkout reflect the time they were checked out, rather > than the time they were last committed. In that case, rsync would be > trying to update all the web site files every day since there was a > fresh checkout from svn every day. I think we can change how the > timestamps are set on checkout, but I need to read more of the svn > documentation to understand this better first. > > Erik > > > > > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel |
From: Erik P. <epe...@iv...> - 2024-03-09 09:04:56
|
On Tue, 2024-03-05 at 10:21 +0100, Philipp Klaus Krause wrote: > Am 05.03.24 um 07:00 schrieb Erik Petrich: > > Yes, it updates using rsync with the --size-only parameter. > > What is the reason for the --size-only? A normal rsync would trigger > if > times or sizes change. Does something not under our control change > the > times? > > Philipp I looked into the history hoping to find a comment when the option was introduced, but the --size-only has been there since Borut's initial check-in of both files that I've seen it used. Looking further, it seems that the default timestamp on files created during the svn checkout reflect the time they were checked out, rather than the time they were last committed. In that case, rsync would be trying to update all the web site files every day since there was a fresh checkout from svn every day. I think we can change how the timestamps are set on checkout, but I need to read more of the svn documentation to understand this better first. Erik |
From: Philipp K. K. <pk...@sp...> - 2024-03-05 09:21:30
|
Am 05.03.24 um 07:00 schrieb Erik Petrich: > Yes, it updates using rsync with the --size-only parameter. What is the reason for the --size-only? A normal rsync would trigger if times or sizes change. Does something not under our control change the times? Philipp |
From: Erik P. <epe...@iv...> - 2024-03-05 06:15:45
|
On Mon, 2024-03-04 at 12:18 +0100, Philipp Klaus Krause wrote: > Do we still have the problem of the website updating from svn only > when > the size of files changes? > > I fixed a typo on our starting page 26 hours ago, and the website > still > has the typo. > > Philipp Yes, it updates using rsync with the --size-only parameter. If you want to change just a single character, remember to also add/remove a blank or newline somewhere inconspicuous so that the overall file size also changes. Erik |
From: Philipp K. K. <pk...@sp...> - 2024-03-04 11:18:41
|
Do we still have the problem of the website updating from svn only when the size of files changes? I fixed a typo on our starting page 26 hours ago, and the website still has the typo. Philipp |
From: Steve S. <ste...@gm...> - 2024-02-25 09:21:13
|
I'm wondering how difficult it would be to support the gcc syntax for inline asm. Maybe nor everything at once, or not optimally. I'm actually very interested in the %1 style parameters, in order to avoid coping local vars to specific registers before inline asm code. -- Steve SCHNEPP |
From: Strobl A. <a.s...@aw...> - 2024-02-15 11:09:05
|
These pic16 types I have in use in my projects/devices * PIC18F2550 * PIC18F25J50 * PIC18F2620 * PIC18F2680 * PIC18F2685 * PIC18F4550 * PIC18F4620 * PIC18F4680 * PIC18F67J60 * PIC18F97J60 most current projects are using * PIC18F26K22 * PIC18F46K22 with compiler: sdcc-4.3.2 svn version 14342 (gputils svn 1331) All my pic14 and pic16 code is compiled using sdcc. I have tried to compile a current pic18f46k22 project and uploaded it to chip. A first test shows, the program is still functional. The code size increases with the new patches... Best regards, Toni |
From: Kustaa N. <ea...@ea...> - 2024-02-08 04:27:08
|
I'm using SDCC with PIC18F45K50 for a couple of projects. wbr Kusti On 7.2.2024 15.40, Jonathon Hall wrote: > Hi all, I have been working for some time on getting the pic16 backend > fully working. The first goal is to get all unit tests passing, then > look at optimizing the generated code. > > Is anybody currently using the pic16 backend? I have a few patches > that could use review from other pic16 users. Patches 4-6 here are > not yet merged and could use review: > https://sourceforge.net/p/sdcc/patches/472/ > > 0004 "pic16: CALL/RETURN uses FSR0H, add generic pointer calling > conventions" fixes the register usage model for CALL/RETURN > instructions. FSR0H was not considered "used" for a return > instruction, but it is used when returning a >4 byte value. >4 byte > values are placed on the stack and the address returned in > FSR0H:FSR0L. Since FSR0H was not considered "used", its > initialization could be omitted, which means the returned address was > wrong. > > It also adds the specialized calling conventions used for the generic > pointer functions. I had not actually seen it omit these > initializations but they should be modeled correctly. > > 0005 "pic16 tests: enable stdout to USART" makes it easier to > troubleshoot unit tests by capturing stdout in the logs. The tests > already write assertion failure information to stdout, but that went > nowhere on pic16. > > 0006 "device/lib/pic16: Wait for PIR1.TXIF when writing to USART, not > TXSTA.TRMT" is just an improvement for stdout output to USART, when > troubleshooting some code on a real pic16 I noticed the USART output > was waiting longer than necessary. It was waiting until the prior > byte was fully shifted out of the USART before writing another, when > it really only needs to wait until the transmit register is empty. > > I would appreciate any review / comments on any of these patches! > Just knowing how (or if) the pic16 backend is used by anybody right > now would be helpful too, I intend to keep any working code working > throughout this process. > > Thanks! > Jonathon > > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel |