<div dir="ltr">On Mon, Aug 25, 2008 at 6:08 AM, Matthew Fluet <span dir="ltr">&lt;<a href="mailto:fluet@tti-c.org">fluet@tti-c.org</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Fri, 22 Aug 2008, Wesley W. Terpstra wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Anyway, since MLton does a lot of symbol accessing, and since &#39;call&#39; is<br>
expensive to get to work (we&#39;d have to save %esp, restore it to the C stack,<br>
call, pop, restore %esp, ...), I think the only real option is to load the<br>
offset of the GOT into %ebx at MLton_jumpToSML time (while I can still<br>
easily use %esp) and make %ebx unavailable for use as a general purpose<br>
register. Yes this sucks for performance, but PIC code on i386 is always<br>
slower.<br>
</blockquote>
<br></div>
Seems reasonable. Since the MLton_jumpToSML code is generated assembly, you can do the &#39;pop %ebx&#39; without another &#39;call&#39;.</blockquote><div><br>The reason I used a &#39;call&#39; as opposed to &#39;pop&#39; is because _GLOBAL_OFFSET_TABLE_ is calculated relative to the instruction where it&#39;s used. If I did the pop then addl %ebx would need some symbol arithmetic which doesn&#39;t fit nicely into the Immediate abstraction. I figured the extra one instruction was a small price to pay. :-)<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Mimic the uses of &#39;reserveEsp&#39; in x86-generate-transfers.fun. You&#39;ll want to remove %ebx from the list of available registers for intra-procedural (inter-block) transfers (the &#39;transferRegs&#39; value). &nbsp;You&#39;ll also want to assume that %ebx is reserved at the beginning of each block (the &#39;blockAssumes&#39; function).<br>
</blockquote><div><br>Your reply comes too late. Do an &#39;svn update&#39;. ;-) But thanks.<br></div></div></div>