[M3devel] int64 division?

[Jay K]

Should be ok now.

 

 - Jay

 


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu; m3devel at elegosoft.com
Date: Mon, 15 Feb 2010 08:29:07 +0000
Subject: [M3devel] int64 division?



Tony, there's something wrong with 64bit division.
This program fails on LINUXLIBC6.
I fixed it for NT386 (wrong parameter order) but the two are wildly divergent.
 
 
MODULE Main;
PROCEDURE NotConstL(a: LONGINT): LONGINT =
  BEGIN
    RETURN a;
  END NotConstL;
BEGIN
  <* ASSERT FIRST(LONGINT) = (FIRST(LONGINT) DIV NotConstL(1L)) *>
  <* ASSERT LAST(LONGINT) = (LAST(LONGINT) DIV NotConstL(1L)) *>
END Main.

 
(gdb) x/200i Main_M3
0x804b03e <Main_M3>:    push   %ebp
0x804b03f <Main_M3+1>:  mov    %esp,%ebp
0x804b041 <Main_M3+3>:  push   %ebx
0x804b042 <Main_M3+4>:  sub    $0x14,%esp
0x804b045 <Main_M3+7>:  call   0x804b04a <Main_M3+12>
0x804b04a <Main_M3+12>: pop    %ebx
0x804b04b <Main_M3+13>: add    $0x3a50a,%ebx
0x804b051 <Main_M3+19>: mov    0x8(%ebp),%eax
0x804b054 <Main_M3+22>: xor    $0x1,%eax
0x804b057 <Main_M3+25>: test   %al,%al
0x804b059 <Main_M3+27>: jne    0x804b100 <Main_M3+194>
0x804b05f <Main_M3+33>: sub    $0x8,%esp
0x804b062 <Main_M3+36>: push   $0x0
0x804b064 <Main_M3+38>: push   $0x1
0x804b066 <Main_M3+40>: call   0x804b024 <Main__NotConstL>
0x804b06b <Main_M3+45>: add    $0x10,%esp
0x804b06e <Main_M3+48>: mov    %eax,0xfffffff0(%ebp)
0x804b071 <Main_M3+51>: mov    %edx,0xfffffff4(%ebp)
0x804b074 <Main_M3+54>: mov    0xfffffff0(%ebp),%eax
0x804b077 <Main_M3+57>: mov    0xfffffff4(%ebp),%edx
0x804b07a <Main_M3+60>: push   $0x80000000
0x804b07f <Main_M3+65>: push   $0x0
0x804b081 <Main_M3+67>: push   %edx
0x804b082 <Main_M3+68>: push   %eax
0x804b0d0 <Main_M3+146>:        push   %edx
0x804b0d1 <Main_M3+147>:        push   %eax
0x804b0d2 <Main_M3+148>:        call   0x804bbd4 <m3_divL>
0x804b0d7 <Main_M3+153>:        add    $0x10,%esp

 
Right here this can't be correct.
64bit results are returned in the edx:eax pair, edx
is high, eax low. (32bit results are turned in just eax.)
It looks like m3_divL returned the correct
value but whatever is happening here is trashing the results.
 
 
0x804b0da <Main_M3+156>:        mov    %eax,%edx

 
 
0x804b0dc <Main_M3+158>:        sar    $0x1f,%edx
0x804b0df <Main_M3+161>:        mov    %edx,%ecx
0x804b0e1 <Main_M3+163>:        xor    $0x7fffffff,%ecx
0x804b0e7 <Main_M3+169>:        xor    $0xffffffff,%eax
0x804b0ea <Main_M3+172>:        or     %ecx,%eax
0x804b0ec <Main_M3+174>:        test   %eax,%eax
0x804b0ee <Main_M3+176>:        je     0x804b100 <Main_M3+194>
0x804b0f0 <Main_M3+178>:        sub    $0xc,%esp
0x804b0f3 <Main_M3+181>:        push   $0x140
0x804b0f8 <Main_M3+186>:        call   0x804b10b <_m3_fault>
0x804b0fd <Main_M3+191>:        add    $0x10,%esp
0x804b100 <Main_M3+194>:        mov    0xfffffc74(%ebx),%eax
0x804b106 <Main_M3+200>:        mov    0xfffffffc(%ebp),%ebx
0x804b109 <Main_M3+203>:        leave
0x804b10a <Main_M3+204>:        ret
0x804b10b <_m3_fault>:  push   %ebp
0x804b10c <_m3_fault+1>:        mov    %esp,%ebp
0x804b10e <_m3_fault+3>:        push   %ebx
 
 
I'll dig a bit more.
 
 
 - Jay

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100215/0ec0c244/attachment-0002.html>