From: SourceForge.net <no...@so...> - 2010-05-21 14:31:29
|
Feature Requests item #979838, was opened at 2004-06-25 18:26 Message generated for change (Comment added) made by spth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=979838&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: 5 Private: No Submitted By: Stephen (easyplan) Assigned to: Nobody/Anonymous (nobody) Summary: Register parameter passing Initial Comment: First, well done on a great product, to all those who have worked on the compiler. I have used Keil and HiTech compilers for an 8052, and both use the registers to pass parameters to functions. My project which compiles using the Keil compiler is 96 bytes short of data when compiled using SDCC because most of the parameters are passed in data space. Have you considered using the registers to pass parameters as part of the optimisation of data space? or allowing this as an option? ---------------------------------------------------------------------- >Comment By: Philipp Krause (spth) Date: 2010-05-21 16:31 Message: While the standard allows to use the storage class specifier it doesn't allow passing the argument in a different way depending on it's presence. Philipp ---------------------------------------------------------------------- Comment By: Philipp Krause (spth) Date: 2008-03-20 14:38 Message: Logged In: YES user_id=564030 Originator: NO How about letting the user decide? The c standard allows the use of the register storage class specififer for function arguments. ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2007-06-29 14:00 Message: Logged In: YES user_id=589052 Originator: NO Hi, I also see SDCC at a disadvantage versus other compilers because of SDCC's parameter passing via DPTR. Access to DPL needs one byte more than access to register R0..R7 or A. This adds up... In the functions within the appended file ("parameters.c") the caller prepares, the callee accesses, the callee sets up return value, and caller stores the returned value... For small function bodies the disadvantage of using DPTR can be substantial (more than 40% longer code in the constructed sample code.) This parameter passing (and returning) scheme is probably noticeably better adapted to the 8051? a) 1 byte: A b) 2 byte: R6(LSB), R7(MSB) c) 2 byte: DPTR (xdata/code pointer) d) 3 byte: B,DPTR (generic pointer) e) 4 byte: R4(LSB)..R7(MSB) The advantage of a) is evident. (13 versus 20 bytes in the constructed example) Point b) probably does not (yet) fall into the category which Bernhard mentioned (parameters eating up register space). (24 versus 35 bytes in the constructed example) Point c) and d) is currently in use and well adapted to pointers. Point e) is (for more complex functions) in the category which Bernhard mentioned. Yet it would be (3 byte) shorter to put R4..R7 out of the way than it is to move DPTR,B,A out of the way. (And one doesn't have to (whereas DPTR,B,A would usually have to be saved if the parameter is to be used later)). (37 versus 54 bytes in the constructed example) File Added: parameters.c ---------------------------------------------------------------------- Comment By: Bernhard Held (bernhardheld) Date: 2004-06-28 09:00 Message: Logged In: YES user_id=203539 At the moment the register allocator is not clever enough to efficiently deal with parameters in registers. In general the benefit from register parameters is often overestimated. It certainly makes sense on CPUs with plenty of large registers. On a 8051 tiny functions will look much better. But in larger or complex functions you'll often find that the registers must be saved immediately after the entrance code. In many cases it's better to let the register allocator decide which variables should be kept in registers. It would be a big performance drawback, if e.g. an automatic variable used as a loop counter is located on the stack, because the parameters eat up all the register space. ---------------------------------------------------------------------- Comment By: Stephen (easyplan) Date: 2004-06-26 10:56 Message: Logged In: YES user_id=1071031 I didn't know about that option. Helps with data optimisation, but I see the libraries need to be re-compiled. Would it not make sense to use the active register bank to pass some of the parameters because often the parameters are being used in the registers. They are copied into bank 1 to be passed as parameters, and then the called function moves them back into registers to use. ---------------------------------------------------------------------- Comment By: Bernhard Held (bernhardheld) Date: 2004-06-25 18:31 Message: Logged In: YES user_id=203539 What about --parms-in-bank1? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=979838&group_id=599 |