Page 1 of 1
issue-#42 fixing LONGINT division TRAP
Posted: Mon Apr 27, 2015 10:14 am
by 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
Re: issue-#42 fixing LONGINT division TRAP
Posted: Mon Apr 27, 2015 11:48 am
by 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
René Dorta
interpreted this as
register allocation problem.
René Dorta wrote: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

Re: issue-#42 fixing LONGINT division TRAP
Posted: Mon Apr 27, 2015 12:55 pm
by 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
Re: issue-#42 fixing LONGINT division TRAP
Posted: Fri May 08, 2015 10:15 am
by 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
Re: issue-#42 fixing LONGINT division TRAP
Posted: Sat May 09, 2015 8:53 am
by Zinn
Josef Templ wrote:
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.
Re: issue-#42 fixing LONGINT division TRAP
Posted: Mon May 11, 2015 5:43 am
by 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