#79 Register parameter passing


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?


  • Bernhard Held

    Bernhard Held - 2004-06-25

    Logged In: YES

    What about --parms-in-bank1?

  • Stephen

    Stephen - 2004-06-26

    Logged In: YES

    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.

  • Bernhard Held

    Bernhard Held - 2004-06-28

    Logged In: YES

    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.

  • Frieder Ferlemann

    sample code using different parameter passing methods

  • Frieder Ferlemann

    Logged In: YES
    Originator: NO


    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

  • Philipp Klaus Krause

    Logged In: YES
    Originator: NO

    How about letting the user decide? The c standard allows the use of the register storage class specififer for function arguments.

  • Philipp Klaus Krause

    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.



Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks