From: SourceForge.net <no...@so...> - 2011-05-09 09:13:25
|
Feature Requests item #3299337, was opened at 2011-05-09 10:13 Message generated for change (Tracker Item Submitted) made by u6c87 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=3299337&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: z80 port Group: None Status: Open Priority: 5 Private: No Submitted By: Brian Ruthven (u6c87) Assigned to: Nobody/Anonymous (nobody) Summary: Provide option to intiialise globals directly Initial Comment: I'm probably a bit out on a limb here, but I'm running the Z80 port targetting an all-RAM config (a bit like CP/M does). The gsinit code hurts me a bit, and steals some valuable space. I realise this is required for a program which will ultimately reside in ROM, but it would be nice in my case (and save me around 300 bytes) if globals could be initialised at declaration time using the relevant .db or equivalent assembler directive. My current proposed workaround (although I've not tested it thoroughly yet) is to rearrange the linker segments in my custom crt such that I get _CODE followed by _DATA, then _GSINIT section. Thus, once the call to gsinit is completed, that code is not needed again, so this space is reclaimed by main() for use with the dynamic memory allocator (again, my own), by locating the boundary between _DATA and _GSINIT and overwriting _GSINIT as the program runs. It's a bit clumsy, but once I got my head around the linker, seems possible. An option such as --allocate-globals-directly or equivalent would help avoid this tinkering. Having said that, I wouldn't assign this a high priority unless somebody else thinks it's useful too. I've got my workaround which has the same run-time footprint in memory as if the gsinit section were not there (except the remaining "jp _gsinit" instruction in the crt). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=3299337&group_id=599 |
From: SourceForge.net <no...@so...> - 2011-06-08 09:43:13
|
Feature Requests item #3299337, was opened at 2011-05-09 11:13 Message generated for change (Comment added) made by spth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=3299337&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: None Group: None Status: Open >Priority: 6 Private: No Submitted By: Brian Ruthven (u6c87) Assigned to: Nobody/Anonymous (nobody) Summary: Provide option to intiialise globals directly Initial Comment: I'm probably a bit out on a limb here, but I'm running the Z80 port targetting an all-RAM config (a bit like CP/M does). The gsinit code hurts me a bit, and steals some valuable space. I realise this is required for a program which will ultimately reside in ROM, but it would be nice in my case (and save me around 300 bytes) if globals could be initialised at declaration time using the relevant .db or equivalent assembler directive. My current proposed workaround (although I've not tested it thoroughly yet) is to rearrange the linker segments in my custom crt such that I get _CODE followed by _DATA, then _GSINIT section. Thus, once the call to gsinit is completed, that code is not needed again, so this space is reclaimed by main() for use with the dynamic memory allocator (again, my own), by locating the boundary between _DATA and _GSINIT and overwriting _GSINIT as the program runs. It's a bit clumsy, but once I got my head around the linker, seems possible. An option such as --allocate-globals-directly or equivalent would help avoid this tinkering. Having said that, I wouldn't assign this a high priority unless somebody else thinks it's useful too. I've got my workaround which has the same run-time footprint in memory as if the gsinit section were not there (except the remaining "jp _gsinit" instruction in the crt). ---------------------------------------------------------------------- >Comment By: Philipp Klaus Krause (spth) Date: 2011-06-08 11:43 Message: Increasing priority slightly, since this is a feature is requested by z88dk developers for integration of sdcc in z88dk, too. Removing the Z80 categorization, since this feature is potentially useful on other ports, too. Philipp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=3299337&group_id=599 |
From: SourceForge.net <no...@so...> - 2011-12-05 08:53:53
|
Feature Requests item #3299337, was opened at 2011-05-09 02:13 Message generated for change (Comment added) made by spth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=3299337&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 6 Private: No Submitted By: Brian Ruthven (u6c87) Assigned to: Nobody/Anonymous (nobody) Summary: Provide option to intiialise globals directly Initial Comment: I'm probably a bit out on a limb here, but I'm running the Z80 port targetting an all-RAM config (a bit like CP/M does). The gsinit code hurts me a bit, and steals some valuable space. I realise this is required for a program which will ultimately reside in ROM, but it would be nice in my case (and save me around 300 bytes) if globals could be initialised at declaration time using the relevant .db or equivalent assembler directive. My current proposed workaround (although I've not tested it thoroughly yet) is to rearrange the linker segments in my custom crt such that I get _CODE followed by _DATA, then _GSINIT section. Thus, once the call to gsinit is completed, that code is not needed again, so this space is reclaimed by main() for use with the dynamic memory allocator (again, my own), by locating the boundary between _DATA and _GSINIT and overwriting _GSINIT as the program runs. It's a bit clumsy, but once I got my head around the linker, seems possible. An option such as --allocate-globals-directly or equivalent would help avoid this tinkering. Having said that, I wouldn't assign this a high priority unless somebody else thinks it's useful too. I've got my workaround which has the same run-time footprint in memory as if the gsinit section were not there (except the remaining "jp _gsinit" instruction in the crt). ---------------------------------------------------------------------- >Comment By: Philipp Klaus Krause (spth) Date: 2011-12-05 00:53 Message: This is really a bug in the old register allocator. The new register allocator has a mechanism to avoid this problem in add_operand_conflicts_in_node() in ralloc2.cc. Philipp ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2011-06-08 02:43 Message: Increasing priority slightly, since this is a feature is requested by z88dk developers for integration of sdcc in z88dk, too. Removing the Z80 categorization, since this feature is potentially useful on other ports, too. Philipp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=3299337&group_id=599 |
From: SourceForge.net <no...@so...> - 2011-12-05 08:54:42
|
Feature Requests item #3299337, was opened at 2011-05-09 02:13 Message generated for change (Comment added) made by spth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=3299337&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 6 Private: No Submitted By: Brian Ruthven (u6c87) Assigned to: Nobody/Anonymous (nobody) Summary: Provide option to intiialise globals directly Initial Comment: I'm probably a bit out on a limb here, but I'm running the Z80 port targetting an all-RAM config (a bit like CP/M does). The gsinit code hurts me a bit, and steals some valuable space. I realise this is required for a program which will ultimately reside in ROM, but it would be nice in my case (and save me around 300 bytes) if globals could be initialised at declaration time using the relevant .db or equivalent assembler directive. My current proposed workaround (although I've not tested it thoroughly yet) is to rearrange the linker segments in my custom crt such that I get _CODE followed by _DATA, then _GSINIT section. Thus, once the call to gsinit is completed, that code is not needed again, so this space is reclaimed by main() for use with the dynamic memory allocator (again, my own), by locating the boundary between _DATA and _GSINIT and overwriting _GSINIT as the program runs. It's a bit clumsy, but once I got my head around the linker, seems possible. An option such as --allocate-globals-directly or equivalent would help avoid this tinkering. Having said that, I wouldn't assign this a high priority unless somebody else thinks it's useful too. I've got my workaround which has the same run-time footprint in memory as if the gsinit section were not there (except the remaining "jp _gsinit" instruction in the crt). ---------------------------------------------------------------------- >Comment By: Philipp Klaus Krause (spth) Date: 2011-12-05 00:54 Message: Sorry for the previous comment. It was meant to go to bug #3441816. Philipp ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2011-12-05 00:53 Message: This is really a bug in the old register allocator. The new register allocator has a mechanism to avoid this problem in add_operand_conflicts_in_node() in ralloc2.cc. Philipp ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2011-06-08 02:43 Message: Increasing priority slightly, since this is a feature is requested by z88dk developers for integration of sdcc in z88dk, too. Removing the Z80 categorization, since this feature is potentially useful on other ports, too. Philipp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=3299337&group_id=599 |
From: SourceForge.net <no...@so...> - 2012-11-19 20:06:09
|
Feature Requests item #3299337, was opened at 2011-05-09 02:13 Message generated for change (Comment added) made by pacomix You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=3299337&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 6 Private: No Submitted By: Brian Ruthven (u6c87) Assigned to: Nobody/Anonymous (nobody) Summary: Provide option to intiialise globals directly Initial Comment: I'm probably a bit out on a limb here, but I'm running the Z80 port targetting an all-RAM config (a bit like CP/M does). The gsinit code hurts me a bit, and steals some valuable space. I realise this is required for a program which will ultimately reside in ROM, but it would be nice in my case (and save me around 300 bytes) if globals could be initialised at declaration time using the relevant .db or equivalent assembler directive. My current proposed workaround (although I've not tested it thoroughly yet) is to rearrange the linker segments in my custom crt such that I get _CODE followed by _DATA, then _GSINIT section. Thus, once the call to gsinit is completed, that code is not needed again, so this space is reclaimed by main() for use with the dynamic memory allocator (again, my own), by locating the boundary between _DATA and _GSINIT and overwriting _GSINIT as the program runs. It's a bit clumsy, but once I got my head around the linker, seems possible. An option such as --allocate-globals-directly or equivalent would help avoid this tinkering. Having said that, I wouldn't assign this a high priority unless somebody else thinks it's useful too. I've got my workaround which has the same run-time footprint in memory as if the gsinit section were not there (except the remaining "jp _gsinit" instruction in the crt). ---------------------------------------------------------------------- Comment By: pacomix (pacomix) Date: 2012-11-19 12:06 Message: Or in example it could be VERY useful having this for the z80 port: __data const unsigned char g_MyArray[] = {1,2,3,4,5,6,4,4,6,2,34}; In order allowing the data be placed in the _DATA area instead _CODE. ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2011-12-05 00:54 Message: Sorry for the previous comment. It was meant to go to bug #3441816. Philipp ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2011-12-05 00:53 Message: This is really a bug in the old register allocator. The new register allocator has a mechanism to avoid this problem in add_operand_conflicts_in_node() in ralloc2.cc. Philipp ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2011-06-08 02:43 Message: Increasing priority slightly, since this is a feature is requested by z88dk developers for integration of sdcc in z88dk, too. Removing the Z80 categorization, since this feature is potentially useful on other ports, too. Philipp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=3299337&group_id=599 |
From: SourceForge.net <no...@so...> - 2012-11-19 22:27:35
|
Feature Requests item #3299337, was opened at 2011-05-09 02:13 Message generated for change (Comment added) made by u6c87 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=3299337&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 6 Private: No Submitted By: Brian Ruthven (u6c87) Assigned to: Nobody/Anonymous (nobody) Summary: Provide option to intiialise globals directly Initial Comment: I'm probably a bit out on a limb here, but I'm running the Z80 port targetting an all-RAM config (a bit like CP/M does). The gsinit code hurts me a bit, and steals some valuable space. I realise this is required for a program which will ultimately reside in ROM, but it would be nice in my case (and save me around 300 bytes) if globals could be initialised at declaration time using the relevant .db or equivalent assembler directive. My current proposed workaround (although I've not tested it thoroughly yet) is to rearrange the linker segments in my custom crt such that I get _CODE followed by _DATA, then _GSINIT section. Thus, once the call to gsinit is completed, that code is not needed again, so this space is reclaimed by main() for use with the dynamic memory allocator (again, my own), by locating the boundary between _DATA and _GSINIT and overwriting _GSINIT as the program runs. It's a bit clumsy, but once I got my head around the linker, seems possible. An option such as --allocate-globals-directly or equivalent would help avoid this tinkering. Having said that, I wouldn't assign this a high priority unless somebody else thinks it's useful too. I've got my workaround which has the same run-time footprint in memory as if the gsinit section were not there (except the remaining "jp _gsinit" instruction in the crt). ---------------------------------------------------------------------- >Comment By: Brian Ruthven (u6c87) Date: 2012-11-19 14:27 Message: The target segment is not the issue here - that's a separate bug. In a RAM-only config, it doesn't really matter whether this is in _DATA or _CODE. In a ROM+RAM config, putting this in the _CODE segment automatically enforces the "const" modifier. I think that littering the C code with __data is both untidy, prone to produce non-portable code, and is trying to modify the backend target assembler output. I'd much prefer a compiler option to do this. In fact, it could be argued that we should have a dedicated segment for initialised, unmodifiable code (I'd include hard-coded strings too), say _STATICDATA, which can be either in ROM (default) or placed in the _DATA segment (by means of gsinit code) with a switch. However, that's still not this enhancement request! ---------------------------------------------------------------------- Comment By: pacomix (pacomix) Date: 2012-11-19 12:06 Message: Or in example it could be VERY useful having this for the z80 port: __data const unsigned char g_MyArray[] = {1,2,3,4,5,6,4,4,6,2,34}; In order allowing the data be placed in the _DATA area instead _CODE. ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2011-12-05 00:54 Message: Sorry for the previous comment. It was meant to go to bug #3441816. Philipp ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2011-12-05 00:53 Message: This is really a bug in the old register allocator. The new register allocator has a mechanism to avoid this problem in add_operand_conflicts_in_node() in ralloc2.cc. Philipp ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2011-06-08 02:43 Message: Increasing priority slightly, since this is a feature is requested by z88dk developers for integration of sdcc in z88dk, too. Removing the Z80 categorization, since this feature is potentially useful on other ports, too. Philipp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=3299337&group_id=599 |
From: SourceForge.net <no...@so...> - 2012-11-20 15:15:14
|
Feature Requests item #3299337, was opened at 2011-05-09 02:13 Message generated for change (Comment added) made by spth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=3299337&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 6 Private: No Submitted By: Brian Ruthven (u6c87) Assigned to: Nobody/Anonymous (nobody) Summary: Provide option to intiialise globals directly Initial Comment: I'm probably a bit out on a limb here, but I'm running the Z80 port targetting an all-RAM config (a bit like CP/M does). The gsinit code hurts me a bit, and steals some valuable space. I realise this is required for a program which will ultimately reside in ROM, but it would be nice in my case (and save me around 300 bytes) if globals could be initialised at declaration time using the relevant .db or equivalent assembler directive. My current proposed workaround (although I've not tested it thoroughly yet) is to rearrange the linker segments in my custom crt such that I get _CODE followed by _DATA, then _GSINIT section. Thus, once the call to gsinit is completed, that code is not needed again, so this space is reclaimed by main() for use with the dynamic memory allocator (again, my own), by locating the boundary between _DATA and _GSINIT and overwriting _GSINIT as the program runs. It's a bit clumsy, but once I got my head around the linker, seems possible. An option such as --allocate-globals-directly or equivalent would help avoid this tinkering. Having said that, I wouldn't assign this a high priority unless somebody else thinks it's useful too. I've got my workaround which has the same run-time footprint in memory as if the gsinit section were not there (except the remaining "jp _gsinit" instruction in the crt). ---------------------------------------------------------------------- >Comment By: Philipp Klaus Krause (spth) Date: 2012-11-20 07:15 Message: With the new initialization method for globals, the gsinit code size problem is gone. Still, direct initalization would be a bit more efficient than the ldir copy used now. Philipp ---------------------------------------------------------------------- Comment By: Brian Ruthven (u6c87) Date: 2012-11-19 14:27 Message: The target segment is not the issue here - that's a separate bug. In a RAM-only config, it doesn't really matter whether this is in _DATA or _CODE. In a ROM+RAM config, putting this in the _CODE segment automatically enforces the "const" modifier. I think that littering the C code with __data is both untidy, prone to produce non-portable code, and is trying to modify the backend target assembler output. I'd much prefer a compiler option to do this. In fact, it could be argued that we should have a dedicated segment for initialised, unmodifiable code (I'd include hard-coded strings too), say _STATICDATA, which can be either in ROM (default) or placed in the _DATA segment (by means of gsinit code) with a switch. However, that's still not this enhancement request! ---------------------------------------------------------------------- Comment By: pacomix (pacomix) Date: 2012-11-19 12:06 Message: Or in example it could be VERY useful having this for the z80 port: __data const unsigned char g_MyArray[] = {1,2,3,4,5,6,4,4,6,2,34}; In order allowing the data be placed in the _DATA area instead _CODE. ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2011-12-05 00:54 Message: Sorry for the previous comment. It was meant to go to bug #3441816. Philipp ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2011-12-05 00:53 Message: This is really a bug in the old register allocator. The new register allocator has a mechanism to avoid this problem in add_operand_conflicts_in_node() in ralloc2.cc. Philipp ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2011-06-08 02:43 Message: Increasing priority slightly, since this is a feature is requested by z88dk developers for integration of sdcc in z88dk, too. Removing the Z80 categorization, since this feature is potentially useful on other ports, too. Philipp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=3299337&group_id=599 |