Re: [9fans] Alef PPC code generation problem

Re: [9fans] Alef PPC code generation problem

[forsyth]

>>values.  I wonder at which stage of code generation the faulty
>>conversion code is applied?  It isn't to
>>	quad = e - 4.0 * f;

yes, it is, though: it's the conversion from double to int that is wrong.
it might not generate the set/used warnings--i don't know about that--but
that code in the Alef code generator is wrong to start with.
it assigns to one int (when it should be a double) then loads from another.
it's all my fault, of course, since i wrote it, but i suspect it was left that
way by accident, when i was part way through.  unlike qc (where i got it right)
i never used Alef and thus qal much for floating-point work, and i never subsequently noticed.

Re: [9fans] Alef PPC code generation problem

[Lucio De Re]

On Tue, Apr 02, 2002 at 01:50:13PM +0100, forsyth@vitanuova.com wrote:
>
> >>values.  I wonder at which stage of code generation the faulty
> >>conversion code is applied?  It isn't to
> >>	quad = e - 4.0 * f;
>
> yes, it is, though: it's the conversion from double to int that is wrong.
> it might not generate the set/used warnings--i don't know about that--but
> that code in the Alef code generator is wrong to start with.

Conceded.  I needed the last prod.  I kept looking at it from the
wrong angle (int -> float) altogether.  The reason I didn't catch a
wake up is that I have two versions of the compiler (recall the
flagged section I mailed you?) and as Murphy would have it, I'd pick
the wrong one for the diagnostic I was trying to elicit :-(

OK, let me shoehorn the qc code into qal as closely as I can, see if I
can make this baby rock.

++L

Re: [9fans] Alef PPC code generation problem

[Lucio De Re]

On Tue, Apr 02, 2002 at 01:50:13PM +0100, forsyth@vitanuova.com wrote:

> i never used Alef and thus qal much for floating-point work, and i never subsequently noticed.

OK, I have changed merely the type of the created temporary variable
in /sys/src/alef/q/code.c:256 from TINT to TFLOAT:

	tmp = stknode(builtype[TFLOAT]);

which seems to have eliminated the warnings without replacing them
with invalid instruction types.  Until I find a testbench, this will
have to be deemed untested :-)

++L

Re: [9fans] Alef PPC code generation problem

[Lucio De Re]

On Tue, Apr 02, 2002 at 01:11:20PM +0100, forsyth@vitanuova.com wrote:
>
> i'm confused.  in the example you sent,
> 	t = 13*i;
> neither qal nor qc generates a type upgrade for constant 13;
> it generates an integer multiplication of 13 and i (as shifts and adds, but that's almost
> beside the point), and then converts the result, which is correct.
>
For the record, what caused part of my confusion is that I "fixed" the
problem I encountered compiling /sys/src/alef/lib/port/sin.l:37 by
changing 4*f to 4.0*f.  I thought the constant was at fault.  It is
odd, though:

	quad = e - 4*f;

is the original statement.  Hm.  "quad" and "4" are the only integer
values.  I wonder at which stage of code generation the faulty
conversion code is applied?  It isn't to

	quad = e - 4.0 * f;

(seemingly).

++L

Re: [9fans] Alef PPC code generation problem

[Lucio De Re]

On Tue, Apr 02, 2002 at 01:11:20PM +0100, forsyth@vitanuova.com wrote:
>
> i'm confused.  in the example you sent,
> 	t = 13*i;
> neither qal nor qc generates a type upgrade for constant 13;
> it generates an integer multiplication of 13 and i (as shifts and adds, but that's almost
> beside the point), and then converts the result, which is correct.
>
Oh, that would explain things.  So I got the wrong end of the stick
(why am I not surprised?), I read a simplistic interpretation of the
code where in fact there was additional depth.  It certainly makes
more sense, having had my nose rubbed in it.

> the code generated for the fp conversion by qc looks right to me.
> the code generated by qal (it turns out) has never been correct,
> which is consistent with the source code in qal's code.c looking
> wrong too.

Here I agree.  It is twisted, what both compilers do :-)  No Dijkstra
merit awards to the inventor of that abbreviation.  But it does work
for qc, not qal.  Shall I go ahead with a separate "instruction()"
procedure to deal with the special case(s)?  Or have you got a simpler
suggestion?

++L

Re: [9fans] Alef PPC code generation problem

[forsyth]

>>What bothers me, in addition to the failed code generation, is the
>>fact that the type upgrade (the right word escapes me presently)
>>for integer constant 13 is generated as object code.  Surely it
>>_is_ possible for the compiler to detect the value and its purpose
>>earlier and convert it at compile rather than at run time?  I am

i'm confused.  in the example you sent,
	t = 13*i;
neither qal nor qc generates a type upgrade for constant 13;
it generates an integer multiplication of 13 and i (as shifts and adds, but that's almost
beside the point), and then converts the result, which is correct.

the code generated for the fp conversion by qc looks right to me.
the code generated by qal (it turns out) has never been correct,
which is consistent with the source code in qal's code.c looking
wrong too.

[9fans] Alef PPC code generation problem

[Lucio De Re]

Let me try to make this as clear as possible.  Please ask for
explanations if anything is not clear, ambiguous or contradictory.

The problem started with the Alef compiler, jazzed up for 3ed
operation, producing diagnostics about internal variables both
"used and not set" and "set and not used".  This is a problem
because it seems (forsyth can confirm this, no doubt) that "set
and not used" means that the corresponding code is deleted from
the output.

Note that this applies _only_ to the Power PC version of the
compiler, in this case running on the Intel-386 platform.

I tracked the problem to the portion of the code generator entrusted
with converting integer constants (in this particular instance)
into floating point values.  The generated code uses an intermediate
"variable" (this has quite a complex internal representation) and
it is this variable and some of the gymnastics it is subjected to
that cause the compiler to perceive it to be schizophrenic: one
copy "set and not used" and another "used and not set".  The
difference lies with some manipulation of an internal element which
is adjusted to allow for the 8-byte/4-byte representation of the
value.

I haven't solved the problem yet.  On the one hand, there are
numerous ways to skin the cat, but given my knowledge of PPC code
generation, none of them are within my abilities.  I would personally
prefer a mechanism that is less crufty than the sliding around of
variable pointers.

I then looked at the equivalent code in the C compiler code generator
and there is enough difference to believe that the C compiler does
the right thing (I'm sure someone would have discovered it if it
didn't!) mostly because the C compiler does not apply (in)sanity
checks like the Alef compiler to internally generated variables.
One of my proposals (I discussed this briefly with forsyth) was to
deal in this fashion with the special case(s).

Lastly, I tried to trigger the problem with a trivial program so that
I could at least inspect the output of various options.  I was hoping
to compare the output with that of the C compiler, see if I could make
them resemble each other:

	#include <alef.h>

	void main () {
		int i;
		float t;

		i = 12;
		t = 13 * i;
		i = t;
	}

compiled:

	qal -dR t.l && ql -o q.t t.q

I'll spare you the output.  I will forever be grateful to the
inventor of the -d option.  I'll document it, to show my gratitude
:-)

A few points.  The last line is deleted by the code generator, for
the reason given above.  I do need it, otherwise the "t = 13 * i;"
line gets deleted and the purpose of the program is lost entirely.

What bothers me, in addition to the failed code generation, is the
fact that the type upgrade (the right word escapes me presently)
for integer constant 13 is generated as object code.  Surely it
_is_ possible for the compiler to detect the value and its purpose
earlier and convert it at compile rather than at run time?  I am
addressing the specific problem we have here, but I believe that
it is the only instance where a problem arises (I could not trigger
misbehaviour when dealing with anything except constants, not that
my tests were exhaustive).  Again, Charles has no doubt a clearer
view of the bigger picture, but I am pretty certain that we have
a problem exclusively in a situation that could be eliminated at
compile time.

Note that the C compiler has the same "problem" (inefficiency may
be a better description) and that it is present across platforms.

Lastly, it is evident that code generation in C and Alef are not
very different.  Has anyone looked into bringing these closer (yes,
I realise that Alef is obsolete, but some of us are stubborn) given
that they produce objects for the same linker/loader?  Nemo, your
students, or would you need a 2ed licence first for each of them?

In summary: I can continue to battle this windmill until I have
enough PPC experience (anyone wants to ship their obsolete RS/6000
to Johannesburg?) to make the Alef PPC compiler behave itself with
the present functionality and/or I can prod the compiler experts
in this community to implement constant type upgrades in the earlier
stages of the compilation.  I probably can translate the C compiler
efforts into Alef equivalents, but I wouldn't count on it.

And a last plea: may I please publish the Alef sources for 3ed as
I have them presently with Bell Labs' "nulla osta"?  As far as I
can see, there are no trade secrets in them, no privileged knowledge.
I will do my best to keep it from becoming something the Labs will
need to support.

++L