• State Not Answered
  • Locked Locked
  • Replies 10 replies
  • Subscribers 22 subscribers
  • Views 1618 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

how to specify the mspace

erik malund 

 261      =1  void FramRead(U8 IFRCpage, unsigned char xdata * xdata IFRCstore);
*** WARNING C258 IN LINE 261 OF MCDEFS.H: 'IFRCstore': mspace on parameter ignored

The above should, based on the manual be a pointer in xdata to xdata. Why can I not make the darn thing accept that.

Erik

Parents
  • 0 in reply to Andy Neil

    oops

    twice - and the same goof (no tool)

    anyhow, I am not trying to specify "where function parameters are stored" but what it is. I have, on occasion, run afoul with the "universal mspace" that gives the 3 legged parameter and it riles me that you can not (be allowed to) specify exactly what you mean.

    Erik

Reply
  • 0 in reply to Andy Neil

    oops

    twice - and the same goof (no tool)

    anyhow, I am not trying to specify "where function parameters are stored" but what it is. I have, on occasion, run afoul with the "universal mspace" that gives the 3 legged parameter and it riles me that you can not (be allowed to) specify exactly what you mean.

    Erik

Children
  • 0 in reply to erik malund

    "I am not trying to specify 'where function parameters are stored'"

    But you are - and that's the problem:

    void FramRead(U8 IFRCpage, unsigned char xdata * xdata IFRCstore)
    "xdata * xdata" means "pointer stored in xdata and pointing to xdata"

  • 0 in reply to erik malund

    I think it is dawning on me.

    Before the call the contents of the pointer is sucked to the "parameter passing registers" and, at that time the location of the pointer is defined by the definition of the variable. However, the called function need know where the pointed to data is located (or will go crazy with overhead).

    This, however, does not change the "inconvenience" that you can not define the parameter by the same "modifiers" as the variable you include in the function call. For instance the above is called only with pointers defined by U8XX (a #define abbreviation of unsigned char xdata * xdata) and thus it seems natural to use U8XX in the call as well.

    Oh, well some like the mother, some like the daughter, I'll have to live with this.

    Erik

  • 0 in reply to erik malund

    Imagine drawing a vertical line through the asterisk in a pointer declaration. Modifers to the left of the * apply to the thing pointed to. Modifiers to the right of the * apply to the pointer itself.

     thing pointed to   |  pointer
                    |
unsigned char xdata * xdata IFRCstore
                    |
                    |

    The xdata on the left means that this pointer points to a char in xdata space. This is a perfectly legitimate thing to tell the compiler.

    The xdata in italics, on the right, tries to tell the compiler that the function parameter exists in xdata. But the function parameter exists whereever the compiler needs to put it -- most likely in registers, perhaps in overflow memory which depends on the memory model in use. Attemping to specify this second location makes no sense, since the fact that the thing is a function parameter tells you where it lives.

    For a variable declaration, you may want to specify where the variable lives, in which case the second xdata comes in handy. Function parameters are not variables, though.

  • 0 in reply to Drew Davis

    Drew, I know that BUT I like that parametres for function calls are defined identical to the values they refer to

    so, I can not do
    U8 xdata * xdata phred;
    U8 xdata * xdata ralph;

    and specify a function that only call with ralph and phred as
    ... (U8 xdata * xdata george)

    I DO see the irrelevance of the second xdata but then why not the first (OK, OK one is used inside, the other is not)

    My only beef is that you can not specify a function parameter IDENTICAL to the variables you use for that parameter. It is almost a kind of ENUM of the parameter type.

    I'll live with it OK

    Erik

  • 0 in reply to erik malund

    "My only beef is that you can not specify a function parameter IDENTICAL to the variables you use for that parameter"

    Yes, but a function parameter is not identical to a variable - which is precisely why you can't do it!

    Ho hum!

  • 0 in reply to Andy Neil

    Perhaps it would be useful to make this condition a warning ("mspace specifier for formal parameter ignored"), so that the code can still be compiled. Users that don't care about this particular warning can suppress it, and then happily add the extra keyword.