From: SourceForge.net <no...@so...> - 2007-05-07 07:39:59
|
Bugs item #1708648, was opened at 2007-04-27 04:28 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1708648&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: linker Group: non bugs Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: memory space exceed management Initial Comment: In looking at source code in linker for mcs51, I noticed that no 8051MX microncontroller is managed. In fact I am working with a 8051MX based microcontroller, which is not public but Philips internal. Then memory spaces are not generic and all Philips reserved. So when the linker works it verifies that code (for my example) doesn't exceed real memory spaces. Due to generic verification, my code is rejected for only memory spaces and not amount of code. I modified source code to accpet these diffrences but probably it could be a good idea to include these diffrences in public source code. please contact me at vin...@nx... ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-05-07 00:39 Message: Logged In: NO Hi, I think it is necessary to patch widely all source code to take into account generic memory mapping. I noticed that address is considered as 16bits wide instead of 24bits wide, in many structures for code and all sorts of RAM (Addr_T type). All output like MAP of MEM file are implentaed as well (4 hexadecimal digits at most). To be very efficient, I think it is a good idea to allow, most inside as possible, all possibilities in address. Then with this topic, reduce possibilities for specific microcontroller (8051, PIC, etc...). This can be preformed by test file as Microchip do with "*.lkr" files. Today, actual implementation is too restrictive for me. For example, at this time it very impossible to store RAM variable at non common address, which is my main problem today. Before doing anything, what do you think about my remarks/statements. Best regards ---------------------------------------------------------------------- Comment By: wek (wek_) Date: 2007-05-04 07:39 Message: Logged In: YES user_id=1201677 Originator: NO Vincent, Couldn't these differences be submitted as a patch, in the respective part of this Tracker? Jan Waclawek ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1708648&group_id=599 |