[M3devel] Grisu vs. NT386

[Jay K]

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/20160725/406596b0/attachment-0001.html>