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-07-04 06:24:51
|
On Tue, 2024-07-02 at 08:54 +0200, Philipp Klaus Krause wrote: > Am 02.07.24 um 05:18 schrieb Oleg Endo: > > I wasn't aware of SDCC participating in the GSoC program. I did actually 2 > > rounds of GSoC back then with GCC. > > > > I'd be great if the half-finished peephole work could be completed. If > > there are any GSoC candidates I might be able co-mentor. > > AFAIR we applied for GSoC once, got rejected, and haven't tried again since. > Regardless of that, I still would like to continue working on upstreaming my mcs51 changes. Maybe I'll have a bit more headroom towards the end of this year ... Best regards, Oleg Endo |
From: Benedikt F. <b.f...@gm...> - 2024-07-03 19:40:57
|
Am 03.07.24 um 21:30 schrieb mhawkins.consultant: > Does uCsim rely on assembler mnemonics? Or object code? > > Still trying to figure out if using z80 as core makes sense. > > > > Michael A Hawkins > Mobile: 203-550-5502 > AFAIK, ucsim runs a binary. In my opinion, sm83 (Gameboy) is a bit closer to pure 8080. Creating a fork of that (or Z80) and merely making the output 8080 compatible sounds like a good proof-of-concept step to me. You can then still change the mnemonics if you want to. -- Benedikt |
From: mhawkins.consultant <mha...@gm...> - 2024-07-03 19:30:58
|
Does uCsim rely on assembler mnemonics? Or object code?Still trying to figure out if using z80 as core makes sense.Michael A HawkinsMobile: 203-550-5502 -------- Original message --------From: dan...@un... Date: 7/3/24 3:15 PM (GMT-05:00) To: Development chatter about sdcc <sdc...@li...> Subject: Re: [sdcc-devel] 8080/8085 support On Tue, 2 Jul 2024, Michael Hawkins wrote:> Because, should I expect to need to contribute to building a simulator> for 8080/85?No, it is included in sdcc already and it includes 8080/8085.Daniel_______________________________________________sdcc-devel mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/sdcc-devel |
From: <dan...@un...> - 2024-07-03 08:19:44
|
On Tue, 2 Jul 2024, Michael Hawkins wrote: > Because, should I expect to need to contribute to building a simulator > for 8080/85? No, it is included in sdcc already and it includes 8080/8085. Daniel |
From: <445...@qq...> - 2024-07-03 03:33:23
|
On Tue, 2024-07-02 at 19:08 +0200, Benedikt Freisen via sdcc-devel wrote: > > I still favor the AspectC++ approach to whole program analysis because > of its simplicity: > > Applied to SDCC, you would basically let the compiler analyze the source > code for each individual translation unit and let it write all the > information (function and variable usage, constant propagation etc.) to > a common database file (XML, JSON or whatever), but skip actual code > generation. I'm not that familiar with the details, but that step sounds essentially very similar to the LTO approach. It doesn't do the full compilation and optimization of each translation unit, but just dumps the internal compiler data structures at some set point. Since SDCC tends to slow down on larger code sizes sooner, I'd rather avoid any fancy interoperable database formats which add a (wasted) data marshaling round trip. > > You then use a specialized make tool to keep re-translating translation > units until the database does not change any further. > > Eventually, you re-translate every translation unit one last time, this > time with global knowledge, and output optimized object files, which can > be linked using the same primitive linker as before. > > I believe that the necessary changes to SDCC would be considerably less > invasive. > Sounds like that would require changing the build system of all the user projects in order to benefit from it. Some folks might not be using makefiles directly at all (e.g. me usually using cmake + ninja and/or make). It might be less invasive on the SDCC side, but more invasive for all users of SDCC, unless the build tools have built-in support for this approach. Best regards, Oleg Endo Sure, there is no simple and perfect solution for optimization cross multiple translation unit(.c file). If we want that it dose not affect the building sequence of SDCC C project,leave all the cross file optimization in link time (maybe include regenerating the .asm/.o file when linking). Best regards, Chunjiang Li ________________ 月明风清 445...@qq... |
From: <lic...@qq...> - 2024-07-03 01:01:24
|
------------------ Original ------------------ From: "Development chatter about sdcc" <ole...@t-...>; Date: Wed, Jul 3, 2024 08:39 AM To: "Development chatter about sdcc"<sdc...@li...>; Subject: Re: [sdcc-devel] About optmize multiple .c file compilation with SDCC On Tue, 2024-07-02 at 19:08 +0200, Benedikt Freisen via sdcc-devel wrote: > > I still favor the AspectC++ approach to whole program analysis because > of its simplicity: > > Applied to SDCC, you would basically let the compiler analyze the source > code for each individual translation unit and let it write all the > information (function and variable usage, constant propagation etc.) to > a common database file (XML, JSON or whatever), but skip actual code > generation. I'm not that familiar with the details, but that step sounds essentially very similar to the LTO approach. It doesn't do the full compilation and optimization of each translation unit, but just dumps the internal compiler data structures at some set point. Since SDCC tends to slow down on larger code sizes sooner, I'd rather avoid any fancy interoperable database formats which add a (wasted) data marshaling round trip. > > You then use a specialized make tool to keep re-translating translation > units until the database does not change any further. > > Eventually, you re-translate every translation unit one last time, this > time with global knowledge, and output optimized object files, which can > be linked using the same primitive linker as before. > > I believe that the necessary changes to SDCC would be considerably less > invasive. > Sounds like that would require changing the build system of all the user projects in order to benefit from it. Some folks might not be using makefiles directly at all (e.g. me usually using cmake + ninja and/or make). It might be less invasive on the SDCC side, but more invasive for all users of SDCC, unless the build tools have built-in support for this approach. Best regards, Oleg Endo Sure, there is no simple and perfect solution for optimization cross multiple translation unit(.c file). If we want that it dose not affect the building sequence of SDCC C project,leave all the cross file optimization in link time (maybe include regenerating the .asm/.o file when linking). Best regards, Chunjiang Li _______________________________________________ sdcc-devel mailing list sdc...@li... https://lists.sourceforge.net/lists/listinfo/sdcc-devel |
From: <lic...@qq...> - 2024-07-03 00:59:28
|
Sure, there is no simple and perfect solution for optimization cross multiple translation unit(.c file). If we want that it dose not affect the building sequence of SDCC C project,leave all the cross file optimization in link time (maybe include regenerating the .asm/.o file when linking). ------------------ Original ------------------ From: "Development chatter about sdcc" <ole...@t-...>; Date: Wed, Jul 3, 2024 08:39 AM To: "Development chatter about sdcc"<sdc...@li...>; Subject: Re: [sdcc-devel] About optmize multiple .c file compilation with SDCC On Tue, 2024-07-02 at 19:08 +0200, Benedikt Freisen via sdcc-devel wrote: > > I still favor the AspectC++ approach to whole program analysis because > of its simplicity: > > Applied to SDCC, you would basically let the compiler analyze the source > code for each individual translation unit and let it write all the > information (function and variable usage, constant propagation etc.) to > a common database file (XML, JSON or whatever), but skip actual code > generation. I'm not that familiar with the details, but that step sounds essentially very similar to the LTO approach. It doesn't do the full compilation and optimization of each translation unit, but just dumps the internal compiler data structures at some set point. Since SDCC tends to slow down on larger code sizes sooner, I'd rather avoid any fancy interoperable database formats which add a (wasted) data marshaling round trip. > > You then use a specialized make tool to keep re-translating translation > units until the database does not change any further. > > Eventually, you re-translate every translation unit one last time, this > time with global knowledge, and output optimized object files, which can > be linked using the same primitive linker as before. > > I believe that the necessary changes to SDCC would be considerably less > invasive. > Sounds like that would require changing the build system of all the user projects in order to benefit from it. Some folks might not be using makefiles directly at all (e.g. me usually using cmake + ninja and/or make). It might be less invasive on the SDCC side, but more invasive for all users of SDCC, unless the build tools have built-in support for this approach. Best regards, Oleg Endo _______________________________________________ sdcc-devel mailing list sdc...@li... https://lists.sourceforge.net/lists/listinfo/sdcc-devel |
From: Oleg E. <ole...@t-...> - 2024-07-03 00:39:47
|
On Tue, 2024-07-02 at 19:08 +0200, Benedikt Freisen via sdcc-devel wrote: > > I still favor the AspectC++ approach to whole program analysis because > of its simplicity: > > Applied to SDCC, you would basically let the compiler analyze the source > code for each individual translation unit and let it write all the > information (function and variable usage, constant propagation etc.) to > a common database file (XML, JSON or whatever), but skip actual code > generation. I'm not that familiar with the details, but that step sounds essentially very similar to the LTO approach. It doesn't do the full compilation and optimization of each translation unit, but just dumps the internal compiler data structures at some set point. Since SDCC tends to slow down on larger code sizes sooner, I'd rather avoid any fancy interoperable database formats which add a (wasted) data marshaling round trip. > > You then use a specialized make tool to keep re-translating translation > units until the database does not change any further. > > Eventually, you re-translate every translation unit one last time, this > time with global knowledge, and output optimized object files, which can > be linked using the same primitive linker as before. > > I believe that the necessary changes to SDCC would be considerably less > invasive. > Sounds like that would require changing the build system of all the user projects in order to benefit from it. Some folks might not be using makefiles directly at all (e.g. me usually using cmake + ninja and/or make). It might be less invasive on the SDCC side, but more invasive for all users of SDCC, unless the build tools have built-in support for this approach. Best regards, Oleg Endo |
From: Michael H. <mha...@gm...> - 2024-07-02 20:40:52
|
"But, as mentioned before, you can probably make your life easier by simply using Zilog's mnemonics and syntax." I think it's a nice idea to just strip the z80 implementation back to 8080 or 8085 and then add the new instructions that the 80C85 had. The down side though, is that existing assembler would not be reusable. I take it that SDCC passes assembler found inside of source files back to the assembler itself. In which case, taking a large 8080/85 assembler file and inserting it into C source files isn't going to work because the mnenomics are z80 and not 8080. Right? -- Michael A Hawkins Stamford, CT 06902 USA Mobile: 203-550-5502 On Tue, 2024-07-02 at 21:30 +0200, Benedikt Freisen via sdcc-devel wrote: > But, as mentioned before, you can probably make your life easier by > simply using Zilog's mnemonics and syntax. |
From: Eric H. <eri...@ya...> - 2024-07-02 19:53:30
|
I would suggest i8080 as name for the port.8080 and 8085 are binary compatible. Eric Am Dienstag, 2. Juli 2024 um 21:19:32 MESZ hat Michael Hawkins <mha...@gm...> Folgendes geschrieben: Is "8080" a valid name for a port? Or perhaps "int80"? Or "intel8080"? And 80C85 would be a command line option/flag to operate under port "intel8080"? Since there is already an assembler but it's not in SDCC at this time, it would seem that doing that would be the first task. I looked at the wiki: https://sourceforge.net/p/sdcc/wiki/Adding%20a%20port/ under "typical parts of a new port" and don't see instructions for doing the assembler task. Where does the assembler exist on the Internet? From where I can begin to get the 8080/85 piece and begin importing into SDCC? -- Michael A Hawkins Stamford, CT 06902 USA Mobile: 203-550-5502 On Tue, 2024-07-02 at 11:25 -0400, Brian wrote: > Michael -- > > Welcome back!! > > 1) The original Small-C published in Dr. Dobb's was for the 8080. > SDCC will work there , too. > https://en.wikipedia.org/wiki/Small-C > > 2) If you need / want to test on hardware, use an "IMSAI 8080 > replica". The IMSAI front panel is implemented by an ESP32 running > z80pack. Fortunately, the power demand is less than one amp, so no > need for the half-farad filter caps (j/k) in the original power > supply!! If you don't have an ADM-3A terminal, you can use its USB- > serial connection instead. > https://thehighnibble.com/imsai8080/#overview > > > all the best, > *brianW > > ----- Original Message ----- > From: "Michael Hawkins" <mha...@gm...> > To: "Development chatter about sdcc" > <sdc...@li...> > Sent: Tuesday, July 2, 2024 6:21:29 AM > Subject: [sdcc-devel] 8080/8085 support > > Hi everyone, > > Years ago, I was considering jumping in to help/do SDCC support for > 8080/8085. Now, I am seriously about to begin doing just that. But > before I do, I would like to understand the testing that is done as > part of your build processes. And, I seem to recall that there was > initial discussion about the limitations of the number of registers > in > the 8080 that would make it unsuitable for C/SDCC. > > So my first questions are: > 1) Is the 8080/85 considered too primitive to be a successful target > for SDCC? Lack of registers? Other whys? > > 2) What does "unit testing" comprise of in the SDCC build > environment? > Is there some dark room somewhere with a stack of old school > computers > running different CPU's that get exercised? Or is "testing" done some > other magical way? In other words, would I need to design a test rig > for the 8080/85 that can be used for testing? > > Cheers, > _______________________________________________ sdcc-devel mailing list sdc...@li... https://lists.sourceforge.net/lists/listinfo/sdcc-devel |
From: Benedikt F. <b.f...@gm...> - 2024-07-02 19:30:36
|
Am 02.07.24 um 21:18 schrieb Michael Hawkins: > Is "8080" a valid name for a port? Or perhaps "int80"? Or "intel8080"? > And 80C85 would be a command line option/flag to operate under port > "intel8080"? > > Since there is already an assembler but it's not in SDCC at this time, > it would seem that doing that would be the first task. > > I looked at the wiki: > https://sourceforge.net/p/sdcc/wiki/Adding%20a%20port/ under "typical > parts of a new port" and don't see instructions for doing the assembler > task. > Where does the assembler exist on the Internet? From where I can begin > to get the 8080/85 piece and begin importing into SDCC? > Intel themselves apparently called the architectures MCS-80 and MCS-85, see https://archive.org/details/Mcs80_85FamilyUsersManual Regarding the ASXXXX assembler, I believe that this is the official website: https://shop-pdp.net/ashtml/asxxxx.php But, as mentioned before, you can probably make your life easier by simply using Zilog's mnemonics and syntax. |
From: Michael H. <mha...@gm...> - 2024-07-02 19:19:01
|
Is "8080" a valid name for a port? Or perhaps "int80"? Or "intel8080"? And 80C85 would be a command line option/flag to operate under port "intel8080"? Since there is already an assembler but it's not in SDCC at this time, it would seem that doing that would be the first task. I looked at the wiki: https://sourceforge.net/p/sdcc/wiki/Adding%20a%20port/ under "typical parts of a new port" and don't see instructions for doing the assembler task. Where does the assembler exist on the Internet? From where I can begin to get the 8080/85 piece and begin importing into SDCC? -- Michael A Hawkins Stamford, CT 06902 USA Mobile: 203-550-5502 On Tue, 2024-07-02 at 11:25 -0400, Brian wrote: > Michael -- > > Welcome back!! > > 1) The original Small-C published in Dr. Dobb's was for the 8080. > SDCC will work there , too. > https://en.wikipedia.org/wiki/Small-C > > 2) If you need / want to test on hardware, use an "IMSAI 8080 > replica". The IMSAI front panel is implemented by an ESP32 running > z80pack. Fortunately, the power demand is less than one amp, so no > need for the half-farad filter caps (j/k) in the original power > supply!! If you don't have an ADM-3A terminal, you can use its USB- > serial connection instead. > https://thehighnibble.com/imsai8080/#overview > > > all the best, > *brianW > > ----- Original Message ----- > From: "Michael Hawkins" <mha...@gm...> > To: "Development chatter about sdcc" > <sdc...@li...> > Sent: Tuesday, July 2, 2024 6:21:29 AM > Subject: [sdcc-devel] 8080/8085 support > > Hi everyone, > > Years ago, I was considering jumping in to help/do SDCC support for > 8080/8085. Now, I am seriously about to begin doing just that. But > before I do, I would like to understand the testing that is done as > part of your build processes. And, I seem to recall that there was > initial discussion about the limitations of the number of registers > in > the 8080 that would make it unsuitable for C/SDCC. > > So my first questions are: > 1) Is the 8080/85 considered too primitive to be a successful target > for SDCC? Lack of registers? Other whys? > > 2) What does "unit testing" comprise of in the SDCC build > environment? > Is there some dark room somewhere with a stack of old school > computers > running different CPU's that get exercised? Or is "testing" done some > other magical way? In other words, would I need to design a test rig > for the 8080/85 that can be used for testing? > > Cheers, > |
From: Benedikt F. <b.f...@gm...> - 2024-07-02 17:09:02
|
Am 02.07.24 um 04:31 schrieb Oleg Endo: > Hi, > > On Thu, 2024-06-27 at 15:25 +0800, 月明风清 via sdcc-devel wrote: >> Hi, all. >> God! It is very much difficult work to do to optimize multiple .C files project compiling with SDCC. >> Can we use a seperate tool to analyze and compose multiple .C files into one .c file (but need remaining the debugging infomation), after the Single .C file generated,using SDCC compile it,then the SDCC can do more optimization such as use one byte to contain multiple bit variable. >> >> Has anyone has some idea about this question? >> > This is more or less what GCC does with LTO. The individual files are > compiled and instead ( or in addition to) the relocatable machine code it > also stores a dump of the compiler's intermediate code (kind of precompiled > code). That is passed to binutils linker and the linker then will invoke > the "linker plugin" which is again GCC itself. Or something like that. > > I think it's a hack to stay compatible with the traditional compilation > model. But that's one way of doing it. > > There's also the https://llvm-mos.org/ project. They're also doing a couple > of whole-program optimizations. For example they solve the problem of how > to optimally allocate function arguments on stack vs. using shared global > variables -- a common problem on 8-bit systems. Maybe you can get some > inspiration from that project. > > Best regards, > Oleg Endo I still favor the AspectC++ approach to whole program analysis because of its simplicity: Applied to SDCC, you would basically let the compiler analyze the source code for each individual translation unit and let it write all the information (function and variable usage, constant propagation etc.) to a common database file (XML, JSON or whatever), but skip actual code generation. You then use a specialized make tool to keep re-translating translation units until the database does not change any further. Eventually, you re-translate every translation unit one last time, this time with global knowledge, and output optimized object files, which can be linked using the same primitive linker as before. I believe that the necessary changes to SDCC would be considerably less invasive. -- Benedikt |
From: Benedikt F. <b.f...@gm...> - 2024-07-02 16:56:06
|
Am 02.07.24 um 15:53 schrieb Basil Hussain: > On 02/07/2024 14:21, Michael Hawkins wrote: >> 2) What does "unit testing" comprise of in the SDCC build environment? >> Is there some dark room somewhere with a stack of old school computers >> running different CPU's that get exercised? Or is "testing" done some >> other magical way? In other words, would I need to design a test rig >> for the 8080/85 that can be used for testing? > > Testing is primarily done against the µCsim simulator, which is > bundled with SDCC. µCsim certainly says it supports simulation of 8080 > and 8085 processors, although I don't know how accurate or complete it > is. Someone else will surely be able to comment on that. > > More information on the testing infrastructure can be found in the Wiki: > https://sourceforge.net/p/sdcc/wiki/Test/ > https://sourceforge.net/p/sdcc/wiki/Regression%20Testing/ > > One other key requirement for SDCC to support a particular processor > would be support by the assembler. If you don't know, SDCC's assembler > is a fork of the ASxxxx cross assembler. Currently, upstream ASxxxx > claims support for 8080/85, but that support almost certainly does not > exist in SDCC, and would need to be ported from upstream. > > Regards, > Basil Hussain AFAIK, a new assembler would only be necessary for the original ugly 8080 syntax. Since the Z80 is an almost perfect superset of the 8080, we could simply use the Z80 assembler and stick with its more comprehensible syntax. For the 8080 backend itself, sm83 could serve as a starting point, because its instruction set appears to be closer to (i.e. less expanded beyond) the 8080. -- Benedikt |
From: Brian <bw...@va...> - 2024-07-02 15:46:07
|
Michael -- Welcome back!! 1) The original Small-C published in Dr. Dobb's was for the 8080. SDCC will work there , too. https://en.wikipedia.org/wiki/Small-C 2) If you need / want to test on hardware, use an "IMSAI 8080 replica". The IMSAI front panel is implemented by an ESP32 running z80pack. Fortunately, the power demand is less than one amp, so no need for the half-farad filter caps (j/k) in the original power supply!! If you don't have an ADM-3A terminal, you can use its USB-serial connection instead. https://thehighnibble.com/imsai8080/#overview all the best, *brianW ----- Original Message ----- From: "Michael Hawkins" <mha...@gm...> To: "Development chatter about sdcc" <sdc...@li...> Sent: Tuesday, July 2, 2024 6:21:29 AM Subject: [sdcc-devel] 8080/8085 support Hi everyone, Years ago, I was considering jumping in to help/do SDCC support for 8080/8085. Now, I am seriously about to begin doing just that. But before I do, I would like to understand the testing that is done as part of your build processes. And, I seem to recall that there was initial discussion about the limitations of the number of registers in the 8080 that would make it unsuitable for C/SDCC. So my first questions are: 1) Is the 8080/85 considered too primitive to be a successful target for SDCC? Lack of registers? Other whys? 2) What does "unit testing" comprise of in the SDCC build environment? Is there some dark room somewhere with a stack of old school computers running different CPU's that get exercised? Or is "testing" done some other magical way? In other words, would I need to design a test rig for the 8080/85 that can be used for testing? Cheers, -- Michael A Hawkins Stamford, CT 06902 USA Mobile: 203-550-5502 _______________________________________________ sdcc-devel mailing list sdc...@li... https://lists.sourceforge.net/lists/listinfo/sdcc-devel |
From: Basil H. <ba...@st...> - 2024-07-02 14:27:26
|
On 02/07/2024 14:21, Michael Hawkins wrote: > 2) What does "unit testing" comprise of in the SDCC build environment? > Is there some dark room somewhere with a stack of old school computers > running different CPU's that get exercised? Or is "testing" done some > other magical way? In other words, would I need to design a test rig > for the 8080/85 that can be used for testing? Testing is primarily done against the µCsim simulator, which is bundled with SDCC. µCsim certainly says it supports simulation of 8080 and 8085 processors, although I don't know how accurate or complete it is. Someone else will surely be able to comment on that. More information on the testing infrastructure can be found in the Wiki: https://sourceforge.net/p/sdcc/wiki/Test/ https://sourceforge.net/p/sdcc/wiki/Regression%20Testing/ One other key requirement for SDCC to support a particular processor would be support by the assembler. If you don't know, SDCC's assembler is a fork of the ASxxxx cross assembler. Currently, upstream ASxxxx claims support for 8080/85, but that support almost certainly does not exist in SDCC, and would need to be ported from upstream. Regards, Basil Hussain |
From: Michael H. <mha...@gm...> - 2024-07-02 14:23:02
|
Hi Philip, OK, that's all good so far. I assume the "simulators" are not bare metal so what are they exactly? Because, should I expect to need to contribute to building a simulator for 8080/85? -- Michael A Hawkins Stamford, CT 06902 USA Mobile: 203-550-5502 On Tue, 2024-07-02 at 15:43 +0200, Philipp Klaus Krause wrote: > and then run on > simulators |
From: Philipp K. K. <pk...@sp...> - 2024-07-02 13:56:29
|
Am 02.07.24 um 15:21 schrieb Michael Hawkins: > So my first questions are: > 1) Is the 8080/85 considered too primitive to be a successful target > for SDCC? Lack of registers? Other whys? I don't think that would be a problem. After all, the 8051 and the Padauk devices aren't that powerful either. > 2) What does "unit testing" comprise of in the SDCC build environment? > Is there some dark room somewhere with a stack of old school computers > running different CPU's that get exercised? Or is "testing" done some > other magical way? In other words, would I need to design a test rig > for the 8080/85 that can be used for testing? We do regression testing. The regression tests can be run locally by sdcc developers (we usually do before making a commit), and are run on the nightly snapshots in the compile farm: Each machine in the farm gets the current sdcc from svn, builds it, and runs the regression tests. The regression tests mostly consist of a few ten thousand small C code samples that are compiled for each architecture, and then run on simulators. Those programs contain assertions, and failures are reported, and can be seen on the snapshots page (https://sdcc.sourceforge.net/snap.php - red dots indicate failures). There's a bit more, in particular some testing of diagnostics (i.e. warnings and errors), where a few smaple programs are compiled and get checked that warnings and erros are emitted for the issues on the correct line numbers. See also https://sourceforge.net/p/sdcc/wiki/Test/ Philipp P.S.: https://sourceforge.net/p/sdcc/wiki/Adding%20a%20port/ might also be helpful here. |
From: Michael H. <mha...@gm...> - 2024-07-02 13:21:36
|
Hi everyone, Years ago, I was considering jumping in to help/do SDCC support for 8080/8085. Now, I am seriously about to begin doing just that. But before I do, I would like to understand the testing that is done as part of your build processes. And, I seem to recall that there was initial discussion about the limitations of the number of registers in the 8080 that would make it unsuitable for C/SDCC. So my first questions are: 1) Is the 8080/85 considered too primitive to be a successful target for SDCC? Lack of registers? Other whys? 2) What does "unit testing" comprise of in the SDCC build environment? Is there some dark room somewhere with a stack of old school computers running different CPU's that get exercised? Or is "testing" done some other magical way? In other words, would I need to design a test rig for the 8080/85 that can be used for testing? Cheers, -- Michael A Hawkins Stamford, CT 06902 USA Mobile: 203-550-5502 |
From: Philipp K. K. <pk...@sp...> - 2024-07-02 06:54:20
|
Am 02.07.24 um 05:18 schrieb Oleg Endo: > I wasn't aware of SDCC participating in the GSoC program. I did actually 2 > rounds of GSoC back then with GCC. > > I'd be great if the half-finished peephole work could be completed. If > there are any GSoC candidates I might be able co-mentor. AFAIR we applied for GSoC once, got rejected, and haven't tried again since. Philipp |
From: Oleg E. <ole...@t-...> - 2024-07-02 03:19:42
|
On Mon, 2024-07-01 at 18:37 +0200, Steve Schnepp wrote: > I saw in the wiki [1] that there's an old wish for a better register allocation in the mcs51 port. > > As I'm also very interested in supporting specific register allocation in asm [2], I'd like to know how I could best tackle it. I don't have ample time to dwell into it, but I might be able to contribute somehow ;-) > > [1] https://sourceforge.net/p/sdcc/wiki/Project%20ideas/ > [2] https://sourceforge.net/p/sdcc/feature-requests/915/ I'd > > -- > Last year until earlier this year I was trying to upstream my work for improved peephole pattern optimizations on mcs51 with Philipp. At that time he mentioned that he'd be moving the mcs51 target to the better register allocation scheme. We got stuck half-way with the peephole stuff though, from what I remember. I wasn't aware of SDCC participating in the GSoC program. I did actually 2 rounds of GSoC back then with GCC. I'd be great if the half-finished peephole work could be completed. If there are any GSoC candidates I might be able co-mentor. Best regards, Oleg Endo |
From: Oleg E. <ole...@t-...> - 2024-07-02 02:31:47
|
Hi, On Thu, 2024-06-27 at 15:25 +0800, 月明风清 via sdcc-devel wrote: > > Hi, all. > God! It is very much difficult work to do to optimize multiple .C files project compiling with SDCC. > Can we use a seperate tool to analyze and compose multiple .C files into one .c file (but need remaining the debugging infomation), after the Single .C file generated,using SDCC compile it,then the SDCC can do more optimization such as use one byte to contain multiple bit variable. > > Has anyone has some idea about this question? > This is more or less what GCC does with LTO. The individual files are compiled and instead ( or in addition to) the relocatable machine code it also stores a dump of the compiler's intermediate code (kind of precompiled code). That is passed to binutils linker and the linker then will invoke the "linker plugin" which is again GCC itself. Or something like that. I think it's a hack to stay compatible with the traditional compilation model. But that's one way of doing it. There's also the https://llvm-mos.org/ project. They're also doing a couple of whole-program optimizations. For example they solve the problem of how to optimally allocate function arguments on stack vs. using shared global variables -- a common problem on 8-bit systems. Maybe you can get some inspiration from that project. Best regards, Oleg Endo |
From: Steve S. <ste...@gm...> - 2024-07-01 16:38:10
|
I saw in the wiki [1] that there's an old wish for a better register allocation in the mcs51 port. As I'm also very interested in supporting specific register allocation in asm [2], I'd like to know how I could best tackle it. I don't have ample time to dwell into it, but I might be able to contribute somehow ;-) [1] https://sourceforge.net/p/sdcc/wiki/Project%20ideas/ [2] https://sourceforge.net/p/sdcc/feature-requests/915/ I'd -- Steve Schnepp "A man is not dead while his name is still spoken." -- T. Pratchett - Going Postal, Chapter 4 prologue |
From: His S. <sha...@gm...> - 2024-06-30 12:19:25
|
There might be a bug in https://sourceforge.net/p/sdcc/code/HEAD/tree/trunk/sdcc/src/pic16/glue.c#l1805 reg is defined as memmap * in ralloc.h, but on this line there's an attempted assignment of reg_info * pointer to it. Everywhere else, where there is a reg variable, it is first defined as reg_info *. Is it as it should be? GCC14 build fails since they've turned the incompatible pointer types warning into an error. -- HisShadow |
From: <445...@qq...> - 2024-06-27 07:25:24
|
Hi, all. God! It is very much difficult work to do to optimize multiple .C files project compiling with SDCC. Can we use a seperate tool to analyze and compose multiple .C files into one .c file (but need remaining the debugging infomation), after the Single .C file generated,using SDCC compile it,then the SDCC can do more optimization such as use one byte to contain multiple bit variable. Has anyone has some idea about this question? Best regards, Chunjiang Li 月明风清 445...@qq... |