issue-#42 fixing LONGINT division TRAP

[Josef Templ]

This issue is about a compiler TRAP that occurs in special situations when dividing LONGINTs.
See http://redmine.blackboxframework.org/issues/42, which also contains a test program.
A proposal for fixing this bug exists in CPC 1.7 rc5.

The fix needs detailed knowledge about the code generation in the compiler and is not easy to understand.
There is no topic branch for this fix yet because it would create a merge conflict with issue-#41.

Luowy and Ivan, can you please comment on your fix in module DevCPC486
so that it is possible to understand what is going on?

Code: Select all

(* largeint support *)
   | div:
      IF y.mode # Reg THEN LoadR(y); rev := ~rev END; (* <<< patch by luowy, 19-Dec-2011 + Ivan Denisov *) 
      IF rev THEN DevCPL486.GenFDOp(FDIVR, y) ELSE DevCPL486.GenFDOp(FDIV, y) END;
      Floor(y, FALSE)

- Josef

[Ivan Denisov]

The bug was found by Robert.

Here we can see that LuoWy suggested to add:

Code: Select all

 IF y.mode # Reg THEN LoadR(y); END;(*<<< add this line *) 

and Aubrey McIntosh suggested to add

Code: Select all

rev := ~rev 

René Dorta interpreted this as register allocation problem.

Robert's source code fragment crashes the compiler; apparently, a register allocation problem has been uncovered.

I just tested this fix and add to the Red build of BlackBox. My contribution to this fix is limited by it's distribution

[Josef Templ]

with the proposed fix for DIV there is an apparent analogy to the MOD instruction now.
This makes the fix very plausible. In addition, the tests show that it works
and there have not been any new reports about compiler TRAPs recently.
So to me it seems to be a very well done fix.

In order to proceed with this fix, I would liek to remember all to cast their vote
on http://forum.blackboxframework.org/view ... ?f=4&t=214.

- Josef

[Josef Templ]

I have prepared the changes for this fix in topic branch issue-#42
as proposed in CPC 1.7 rc5.

By comparing our current version of CPC486 with CPC 1.7 rc5
I noticed a new line of code in DevCPC486.GetReg:
at the end there is an additional

ELSE n := 0

and there is also an empty ELSE in ConvMove

which is not in BB1.6.
Helmut, can you find out to which issue these changes refer?

I guess, they are related to avoiding follow-up errors (traps) after the compiler
has found an error but proceeds with the code generation.

- Josef

[Zinn]

I noticed a new line of code in DevCPC486.GetReg:
at the end there is an additional ELSE n := 0
and there is also an empty ELSE in ConvMove

Josef, first I search in my documentation and I couldn’t find any notes about it.
At the second search thru the different BlackBox sources I found it in Romiras version:

https://github.com/romiras/BlackBox-Component-Framework
BlackBox-Component-Framework-master.zip
30.09.2013

The best way is to delete both ELSE until we find an exsample where we need it.

[Josef Templ]

Thanks for the votes.

@Doug's comment:
The term 'largeint' is used at various places in the compiler.
Probably to distinguish the 64 bit largeint in BB from the 32 bit LONGINT in Oberon.

- Josef