Out of cpu registers!

[srod]

The following is a contrived example, but I never noticed this before. Run the following:

Code: Select all

a=10
b=20
c=30
x=a*b+c*(b+a*(a+b))

I'd have though these kind of calculations would have used the stack; although this would slow things down a little I guess!

It just caught me by surprise!

[Derek]

Wow, looks so simple, who'd of thought that would be too complicated.

Like you say, you would think the values would be pushed onto the stack.

[Kaeru Gaman]

I had this message sometimes before.
it helps to precalculate some parts into extra-variables.
I think, with using only a few additional variables it will still be faster than calculating the same thing via stack.

[srod]

I agree.

It just that I always imagined that compilers utilised the stack when performing complex calculations.

[Kaeru Gaman]

perhaps fred wanted to do something new.
I think that is one of the reasons why PB is so much faster....

for > 90% of the calculations there are enough registers.
the gain of performance will appear in every calculation a program does.

[Trond]

GCC will use the stack when there aren't any free registers. PB doesn't do that because it happens so rarely that the user can just use temp variables or restructure the expression.

In your case, this will do it:

Code: Select all

a=10
b=20
c=30
x=c*(b+a*(a+b))+a*b

[Kaeru Gaman]

yup.

even if PB would be expanded to use stack "on demand", I would prefer a compiler-warning,
to decide myself if I like to use the stack or an additional variable.

[GedB]

Part of the PB philosophy. Keep it simple.

I wish that some of the developers on the code I'm developing had recieved a similar error. I have to support calculations on a sinle line that are ten screens wide.

[Derek]

Part of the PB philosophy. Keep it simple.

I wish that some of the developers on the code I'm developing had recieved a similar error. I have to support calculations on a sinle line that are ten screens wide.

You're kidding?

[Trond]

It's not the width, it's the nesting level.

[GedB]

Derek,

I wish I was.

[srod]

Now that I've had a good look at the assembly code generated by PB, yep Trond is right; it's the nesting.

E.g. a*b*c*d*e*f*g*h*i*j will only use one register.

I must admit that PB generates some nice code where expressions are concerned. Better than using reverse polish and the stack.

[Rescator]

I find this error a positive feature, if PB actually tells you that it's too complex to be done using the registers available, then it's probably too complex.
It enforces good coding in my oppinion.
I have never run into this error though, amusing.

EDIT:
However, if I had to do something as messy as that I would do it like this:
x=((a*b)+c)*((b+a)*(a+b))
or similar.

[dell_jockey]

The following is a contrived example, but I never noticed this before. Run the following:

Code: Select all

a=10
b=20
c=30
x=a*b+c*(b+a*(a+b))

I'd have though these kind of calculations would have used the stack; although this would slow things down a little I guess!

It just caught me by surprise!

This is indeed a surprise..... Since 'x' is ultimately defined by variables with constant content, I'd expect an optimizing compiler to use constants substitution and directly insert the assignment 'x = <result>' in the object code. In this specific example, a truly optimizing compiler should not need to create code that calculates the result.

Obviously, there's room for improvement, which is a good thing.....

[srod]

Now that's a different issue completely!