<div dir="ltr"><div>If I remember correctly, it's returning and case alternatives that are the problem (unarise is relatively new, for a long time you could only use unboxed tuples in returns and case alternatives).  Take your case expression example:<br><br>case e1 of<br>
          (# bndr1, bndr2, ..., bndrN #) -> RHS<br><br></div><div>Now suppose that e1 is a call to a compiled function, and the RHS is byte code.  Normally when this happens we push a stack frame that will capture the values returned by the compiled code, save them on the stack, and pass control to the interpreter.  These are the stg_ctoi_XXX frames in StgMiscClosures.cmm.  <br><br>The problem with unboxed tuples is that we would need an infinite number of these to handle all the possible return conventions for unboxed tuples.<br><br></div><div>Since we can't use pre-compiled stack frames, we would need to use a scheme that involves some separate description of the stack, using a bitmap of some kind.  I think this should be possible, but there isn't an existing stack frame that does the right thing - the closest is RET_BCO, but then you'd have to make another BCO just for the purpose of containing the bitmap to describe the stack layout.  And you somehow have to extract the values that are being returned in registers and save them on the stack too.<br><br></div><div>The other half of the problem is returning an arbitrary unboxed tuple to compiled code, where we would have to arrange that the correct values get put in the correct registers according to the return convention, and here we would need some kind of descriptor and an interpretive loop in Cmm to do the loading of values from the stack into registers.<br><br></div><div>So I think it's possible, but there are quite a lot of fiddly details.<br><br></div><div>Cheers<br></div><div>Simon<br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 25 July 2016 at 11:14, Ömer Sinan Ağacan <span dir="ltr"><<a href="mailto:omeragacan@gmail.com" target="_blank">omeragacan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Simon,<br>
<br>
I was looking at the bytecode compiler to understand what's needed to support<br>
unboxed tuples. It seems like if we generate bytecode after unarise it should be<br>
very easy to support unboxed tuples, because after unarise we don't have any<br>
unboxed tuple binders (all binders have UnaryType). So only places we see<br>
unboxed tuples are:<br>
<br>
    - Return positions. We just push contents of the tuple to the stack.<br>
<br>
    - Case alternatives. The case expression in this case has to have this form:<br>
<br>
        case e1 of<br>
          (# bndr1, bndr2, ..., bndrN #) -> RHS<br>
<br>
      All binders will have unary types again. We just bind ids in the<br>
      environment to their stack locations and compile RHS.<br>
<br>
I think that's it. We also get unboxed sums support for free when we do this<br>
after unarise.<br>
<br>
What do you think about compiling to bytecode from STG? Have you considered that<br>
before? Would that be a problem for GHCi's debugger or any other features?<br>
</blockquote></div><br></div>