[M3devel] NT386 int64/longint

Jay K jay.krell at cornell.edu
Wed Feb 3 21:49:30 CET 2010


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/20100203/d645a2ca/attachment-0001.html>


More information about the M3devel mailing list