From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lucio De Re To: 9fans@cse.psu.edu Subject: Re: [9fans] Alef PPC code generation problem Message-ID: <20020402142559.F6290@cackle.proxima.alt.za> References: <20020402121506.9816C19995@mail.cse.psu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <20020402121506.9816C19995@mail.cse.psu.edu>; from forsyth@vitanuova.com on Tue, Apr 02, 2002 at 01:11:20PM +0100 Date: Tue, 2 Apr 2002 14:26:00 +0200 Topicbox-Message-UUID: 719609a8-eaca-11e9-9e20-41e7f4b1d025 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