From mboxrd@z Thu Jan  1 00:00:00 1970
From: Lucio De Re <lucio@proxima.alt.za>
To: 9fans mailing list <9fans@cse.psu.edu>
Message-ID: <20020402134114.Z6290@cackle.proxima.alt.za>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [9fans] Alef PPC code generation problem
Date: Tue,  2 Apr 2002 13:41:16 +0200
Topicbox-Message-UUID: 718dc37e-eaca-11e9-9e20-41e7f4b1d025

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