[M3devel] Grisu vs. NT386

[Jay K]

This should all be fixed now in the NT386 backend. Verification welcome.
Work could be shifted to the frontend for some of this, perhaps.
 - Jay
From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Subject: RE: Grisu vs. NT386
Date: Tue, 26 Jul 2016 06:42:28 +0000




I think I can fix the nested helper call easily enough in the backend.
But note that NT386 is definitely currently broken since the introduction of Grisu.
We might also consider having the frontend always form parameters into temporaries.
Not clear if it should do this as needed for a few known cases, like LONGINT multiplication, or for all integer and float operations on all types, despite most of them not requiring function calls.
Also not clear wrt longer standing helper functions like div/mod.

 - Jay

From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Subject: Grisu vs. NT386
Date: Mon, 25 Jul 2016 07:27:46 +0000




Fyi, Grisu reveals at least two problems in the NT386 backend.In particular, it uses LONGINT, and we don't have much code that does.
The two problem are that NT386: - generates function calls for e.g. 64bit integer muliplication - doesn't like generating function calls within function calls, i.e. VAR a,b: LONGINT; Foo(a * b);
It fails an assert -- when it goes to do the multiply, which is a function call, it asserts that no function call is in progress.
For now I'll change Grisu: VAR a,b,t: LONGINT; t := a * b; Foo(t);
but fixing NT386 shouldn't be difficult.
Really, we should allow for: Foo(Bar(a * b) * b);
.. the thing is, the frontend handles this -- it produces temporaries for function return results: t1 := Bar(a * b); Foo(t1 * a * b);
but it doesn't do so for things like add/subtract/multiply/divide. Perhaps it should.Decent backends, including possibly NT386, will enregister the temporaries and generate good code anyway.
Thoughts?
The alternative is NT386 needs to maintain a stack where it doesn't previously -- a stack of pending function calls.


2) Grisu uses loophole between LONGREAL and LONGINT. This is reasonable, but perhaps not previously seen.NT386 requires loopholes that convert between integers and floats to be using REAL, at least for one direction.This seem merely historical and it should allow LONGREAL, or in particular, it should require no size change.Historically NT386 backend maintained an internal stack, of 32bit sized things -- variables and constants.I extended that to be variably sized, i.e. 32bits or 64bits, but this code wasn't updated. It should be trivial, maybe just relaxing the assertion.

 - Jay
 		 	   		   		 	   		   		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20160728/68757c9b/attachment-0002.html>