On Fri, 13 Feb 2009 16:41:32 -0500, Norman Ramsey wrote:
>> > The offender is almost certainly the 'generic expander'.
> >
> > I tried to make a simpler example which reproduces the same error:
> >
> > *****************************************************************
> >
> > target memsize 8 byteorder little pointersize 32 wordsize 32;
> >
> > export main;
> >
> > foo (bits64 x) {
> > return (%and(x,1::bits64));
> > }
> >
> > foreign "C" main (bits32 argc, "address" bits32 argv) {
> > foo (10::bits64);
> > foreign "C" return (0);
> > }
> >
> > *****************************************************************
> >
> > $ qc-- -globals simple.c--
> > This can't happen: Asked for temporary in space `general-purpose
> > temporaries' with unsupported width 64 Fatal error: exception
> > Impossible.Impossible("Asked for temporary in space `general-purpose
> > temporaries' with unsupported width 64")
> >
> > *****************************************************************
>
> Thanks for the nice clean bug report. Undoubtedly what is happening is
> that the generic expander is asking for a 64-bit temporary to help move
> the literal 10 where 64-bit parameters go. Of course what it *should*
> do is split the 64-bit literal into two 32-bit literals.
>
> Rather than tackle this sort of problem piecemeal, we are hoping to
> replace the generic expander with a new 'tiler', which will have a more
> principled approach to this problem, and in particular we should be able
> to prove that either this problem does not occur or that it is detected
> in advance. The solution to this problem is worth a good chunk of a PhD
> thesis, so it may have to wait until I find a student...
Let me try and understand. The expander decides it needs a temporary for
a 64-bit expression used as a parameter. Ideally, it would get it,
generate code to put the 64-bit value there, and then store it wherever
parameters go. But there seems to be no such thing as a 64-bit temporary
(which I conclude from the error message that says width 64 is
unsupported.)
Is that it?
Anyway, I took my Algol 68 source code and replaced my 8-byte structure
by a 4-byte structure. it all compiled as far as giving me the linker
errors I was expecting (external references that were meaningful under
OS/360 but now have to be changed utterly). It looks as if 8-byte
parameters are not a good idea as C-- is set up now.
Are there other things that are likely to need 8-byte temporaries?
There are several places where I copy a 64-bit value, as in
bits64[H109] = bits64[H107];
but they doesn't seem to have repercussions.
-- hendrik
_______________________________________________
Cminusminus mailing list
[email protected]
https://cminusminus.org/mailman/listinfo/cminusminus
