<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
nevermind, it's looking much better now.<BR>
A few more days though.<BR>
<BR>
- Jay<BR> <BR>
<HR id=stopSpelling>
From: jay.krell@cornell.edu<BR>To: m3devel@elegosoft.com<BR>Subject: NT386 int64/longint<BR>Date: Wed, 3 Feb 2010 20:49:30 +0000<BR><BR>
<STYLE>
.ExternalClass .ecxhmmessage P
{padding:0px;}
.ExternalClass body.ecxhmmessage
{font-size:10pt;font-family:Verdana;}
</STYLE>
I've actually been able to compile a fair amount of<BR>code now, and at a very cursory glance, it looks<BR>reasonably correct.<BR>e.g. all of m3core -- including the long/word stuff and Convert.m3.<BR> <BR> <BR>This is using an approach where I "split" operands<BR>and then loop over the parts.<BR>Variables become two variables.<BR>Registers become two registers.<BR>Immediates become two immediates.<BR> <BR> <BR>However I seem unable to get the bookkeeping<BR>within the backend correct.<BR>I had to remove various asserts. Not great.<BR>In some places I believe more asserts are clearly<BR>correct, but yet they fail when I put them in.<BR> <BR> <BR>Some of the asserts are suspicous to me<BR>and further investigation makes me suspicious of<BR>some of the existing code in m3back. But I'm not<BR>very confident here. I'd have to demonstrate incorrect<BR>codegen before making changes.<BR> <BR> <BR>For example the first releaseall in call_indirect seems wrong.<BR>It seems like releaseall should only be called when the virtual<BR>stack must be empty. But it always has depth at least one there.<BR>The second one seems correct.<BR>I think it is also overkill in that it need only release volatile registers.<BR> <BR> <BR>I'm also not sure if the virtual stack should really even be empty there.<BR>Maybe I'm compiling Foo(1 + 2, bar(1 + abc()) + 2).<BR> <BR>Perhaps there are assumptions regarding how the front end works.<BR> <BR>For example I have various add/mult/div making function calls and<BR>that seems to be unexpected.<BR> <BR>I'm also not sure why in_proc_call is limited to two.<BR>And, why that is enforced with an assert instead of a subrange.<BR> <BR> <BR>Perhaps I can model int64/longint mostly as a struct.<BR>I'll look into that.<BR> <BR> <BR>Or maybe I can somewhat "start over" with the current<BR>approach. What is already commited is very safe<BR>and conservative and a useful step, depending<BR>on what the end result is.<BR> <BR> <BR>One of the problems with the current approach is that<BR>if we zero extend a 32bit cardinal, we waste a register for<BR>the upper half zero.<BR> <BR> <BR> - Jay<BR> </body>
</html>