<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
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>