1. Forum
  2. Usenet
  3. COMP.COMPILERS.LCC

  • compile time calculations

    From bill rowe@21:1/5 to All on Thu May 6 12:41:09 2021
    I am used to my LCC port handling things like

    void foo(uint16_t){}

    foo(40*40)
    at compile time but something i've done is now leaving it for a run-time multiply.

    The possibly related change is to make my int's 8 bits rather than 16. Could that affect it?

    If I explicitly say foo( (uint16_t)40*40 )
    I do get the compile time calculation so it's clearly related to the int width.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From bill rowe@21:1/5 to jacobnavia on Thu May 6 14:00:23 2021
    On Thursday, May 6, 2021 at 4:57:01 PM UTC-4, jacobnavia wrote:
    Le 06/05/2021 à 21:41, bill rowe a écrit :
    I am used to my LCC port handling things like

    void foo(uint16_t){}

    foo(40*40)
    at compile time but something i've done is now leaving it for a run-time multiply.

    The possibly related change is to make my int's 8 bits rather than 16. Could that affect it?

    If I explicitly say foo( (uint16_t)40*40 )
    I do get the compile time calculation so it's clearly related to the int width.

    You have to add the compile time calculation to simp.c in function
    simplify. There is no ADD+C operation since all is done in integers that
    are wider than a character. But since I do not klnow how you have done
    your stuff, I can't tell you more

    jacob
    @jacob: thanks for the pointer.
    @keith: I was not aware of that. i didn't think there were any fixed limits, only relative.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Keith Thompson@21:1/5 to bill rowe on Thu May 6 13:25:29 2021
    bill rowe <bill.rowe.ottawa@gmail.com> writes:
    I am used to my LCC port handling things like

    void foo(uint16_t){}

    foo(40*40)
    at compile time but something i've done is now leaving it for a run-time multiply.

    The possibly related change is to make my int's 8 bits rather than 16. Could that affect it?

    If I explicitly say foo( (uint16_t)40*40 )
    I do get the compile time calculation so it's clearly related to the int width.

    I don't have an answer to your question, but I'll just mention that the
    C standard requires int to be at least 16 bits.

    There's nothing wrong with a non-conforming C-like implementation if
    that's what you need. I just wanted to make sure you're aware of it.

    (And LCC might have some implicit assumptions built into it, perhaps
    related to the fact that standard C has no arithmetic operations on
    types narrower than int.)

    --
    Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
    Working, but not speaking, for Philips Healthcare
    void Void(void) { Void(); } /* The recursive call of the void */

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jacobnavia@21:1/5 to All on Thu May 6 22:56:59 2021
    Le 06/05/2021 à 21:41, bill rowe a écrit :
    I am used to my LCC port handling things like

    void foo(uint16_t){}

    foo(40*40)
    at compile time but something i've done is now leaving it for a run-time multiply.

    The possibly related change is to make my int's 8 bits rather than 16. Could that affect it?

    If I explicitly say foo( (uint16_t)40*40 )
    I do get the compile time calculation so it's clearly related to the int width.


    You have to add the compile time calculation to simp.c in function
    simplify. There is no ADD+C operation since all is done in integers that
    are wider than a character. But since I do not klnow how you have done
    your stuff, I can't tell you more

    jacob

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From bill rowe@21:1/5 to All on Thu May 6 14:06:16 2021
    C standard requires int to be at least 16 bits.

    There's nothing wrong with a non-conforming C-like implementation if
    that's what you need. I just wanted to make sure you're aware of it.

    (And LCC might have some implicit assumptions built into it, perhaps
    related to the fact that standard C has no arithmetic operations on
    types narrower than int.)

    --
    Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
    Working, but not speaking, for Philips Healthcare
    void Void(void) { Void(); } /* The recursive call of the void */
    Anyway, thanks for pointing that out. I have a working port with 16 bit ints, my 8 bit variant is useful where i'm doing a lot of character-sized work and the compiler-generated promotions add notably to the output.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)