IMCC puzzle
gre...@focusresearch.com
Here is a simple Jako test program, which exercises the assignment syntax:
var int a, b, c;
var num d, e;
var str f, g;
a = 5;
a = b = c = 5;
d = 3.14;
d = e = 3.14;
f = "Howdy";
f = g = "Howdy";
a = b;
a = b = c;
Here it is compiled to IMC:
.sub __MODULE__
.local int a # var int a;
.local int b # var int b;
.local int c # var int c;
.local float d # var num d;
.local float e # var num e;
.local string f # var str f;
.local string g # var str g;
a = 5 # a = 5;
a = 5 # a = 5;
b = 5 # b = 5;
c = 5 # c = 5;
d = 3.14 # d = 3.14;
d = 3.14 # d = 3.14;
e = 3.14 # e = 3.14;
f = "Howdy" # f = "Howdy";
f = "Howdy" # f = "Howdy";
g = "Howdy" # g = "Howdy";
a = b # a = b;
a = c # a = c;
b = c # b = c;
end
.end
And, here is the PASM imcc turns it into:
__MODULE__:
set I2, 5
set I2, 5
set I0, 5
set I1, 5
set N0, 3.14
set N0, 3.14
set N0, 3.14
set S0, "Howdy"
set S0, "Howdy"
set S0, "Howdy"
set I2, I0
set I2, I1
set I0, I1
end
I don't understand how d and e both become N0, nor how both f and g become
S0. a, b, and c all seem to get their own registers. Is there some
optimization going on here since in both cases (num and str), the assigns
are from the same constant table location? Is imcc smart enough to realize
that the above transformation doesn't change the semantics of my program,
or is it perhaps a bug?
Regards,
-- Gregor
Aaron Sherman
> set N0, 3.14
> set N0, 3.14
> set N0, 3.14
> I don't understand how d and e both become N0, nor how both f and g become
> S0. a, b, and c all seem to get their own registers. Is there some
> optimization going on here since in both cases (num and str), the assigns
> are from the same constant table location? Is imcc smart enough to realize
> that the above transformation doesn't change the semantics of my program,
> or is it perhaps a bug?
Looks like the first stages of constant-folding to me, no?
Presumably if d and e were set to different values or had unpredictable
side effects acting on them, this would not happen.
The constant folding may simply not deal with integers yet....
--
Aaron Sherman <a...@ajs.com>
Leopold Toetsch
> On Fri, 2002-12-06 at 10:40, gre...@focusresearch.com wrote:
> Looks like the first stages of constant-folding to me, no?
No, but constant folding is done anyway. Both "3.14" are one constant
loation.
> The constant folding may simply not deal with integers yet....
No, integer constants are intersparsed in the pbc and can't be folded.
leo
Leopold Toetsch
> Leo --
>
> Here is a simple Jako test program, which exercises the assignment syntax:
> Here it is compiled to IMC:
[ Q/A intersparsed in imcc code for clearness ]
>
> .sub __MODULE__
> .local int a # var int a;
> .local int b # var int b;
> .local int c # var int c;
> .local float d # var num d;
> .local float e # var num e;
> .local string f # var str f;
> .local string g # var str g;
> a = 5 # a = 5;
> a = 5 # a = 5;
> b = 5 # b = 5;
> c = 5 # c = 5;
> d = 3.14 # d = 3.14;
> d = 3.14 # d = 3.14;
> I don't understand how d and e both become N0,
d is not read beyond this point, so the register N0 gets reused.
> e = 3.14 # e = 3.14;
> f = "Howdy" # f = "Howdy";
> f = "Howdy" # f = "Howdy";
> g = "Howdy" # g = "Howdy";
> nor how both f and g become
> S0.
Same her, f ist not used RHS so, S0 gets reused.
> a = b # a = b;
> a = c # a = c;
> b = c # b = c;
> a, b, and c all seem to get their own registers.
Yes, these are used so need there own register.
> ... Is there some
> optimization going on here since in both cases (num and str), the assigns
> are from the same constant table location?
No, constant table location doesn't matter.
> Is imcc smart enough to realize
> that the above transformation doesn't change the semantics of my program,
> or is it perhaps a bug?
It's a result of variable lifeness analyses, which is the base for
register allocation and definitely no bug ;-)
> Regards,
>
> -- Gregor
leo