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)

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)

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)

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)

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)