[M3devel] NT386 int64/longint

[Jay K]

nevermind, it's looking much better now.

A few more days though.

 

 - Jay
 


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Subject: NT386 int64/longint
Date: Wed, 3 Feb 2010 20:49:30 +0000



I've actually been able to compile a fair amount of
code now, and at a very cursory glance, it looks
reasonably correct.
e.g. all of m3core -- including the long/word stuff and Convert.m3.
 
 
This is using an approach where I "split" operands
and then loop over the parts.
Variables become two variables.
Registers become two registers.
Immediates become two immediates.
 
 
However I seem unable to get the bookkeeping
within the backend correct.
I had to remove various asserts. Not great.
In some places I believe more asserts are clearly
correct, but yet they fail when I put them in.
 
 
Some of the asserts are suspicous to me
and further investigation makes me suspicious of
some of the existing code in m3back. But I'm not
very confident here. I'd have to demonstrate incorrect
codegen before making changes.
 
 
For example the first releaseall in call_indirect seems wrong.
It seems like releaseall should only be called when the virtual
stack must be empty. But it always has depth at least one there.
The second one seems correct.
I think it is also overkill in that it need only release volatile registers.
 
 
I'm also not sure if the virtual stack should really even be empty there.
Maybe I'm compiling Foo(1 + 2, bar(1 + abc()) + 2).
 
Perhaps there are assumptions regarding how the front end works.
 
For example I have various add/mult/div making function calls and
that seems to be unexpected.
 
I'm also not sure why in_proc_call is limited to two.
And, why that is enforced with an assert instead of a subrange.
 
 
Perhaps I can model int64/longint mostly as a struct.
I'll look into that.
 
 
Or maybe I can somewhat "start over" with the current
approach. What is already commited is very safe
and conservative and a useful step, depending
on what the end result is.
 
 
One of the problems with the current approach is that
if we zero extend a 32bit cardinal, we waste a register for
the upper half zero.
 
 
 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100205/a850c101/attachment-0002.html>