issue-#209 Compiler trap in Real64 op ADR(x)
issue-#209 Compiler trap in Real64 op ADR(x)
a compiler bug, adimetrius have made a fix.
https://community.blackboxframework.org ... f=48&t=258
https://community.blackboxframework.org ... f=48&t=258
Last edited by luowy on Thu Aug 06, 2020 3:32 pm, edited 3 times in total.
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: issue-#209 Compiler traps when Real64 op with SYSTEM.ADR
for a bug fix as proposed by adimetrius see https://redmine.blackboxframework.org/p ... 9e59a688be
- Josef
- Josef
Re: issue-#209 Compiler traps when Real64 op with SYSTEM.ADR
luowy - Why have you voted against this - Is there something wrong with the solution?
Re: issue-#209 Compiler traps when Real64 op with SYSTEM.ADR
well, there are two points;
1, DevCPL486.CheckMemForm used by Float load or store, the operands it accepted is only integer and real form; obviously, the bug comes from the front step: the Pointer form should not come to here;
2, Pointer is a unsigned integer actually, e.g.
r := r0 + S.ADR(x); Post should : ASSERT(r >= r0)
this fix output such code: FILD tread the operand as a signed integer,
if ADR(X) >2G, the resoult will be r< r0;
P.S. because cp language has no unsigned integer, this requirement may be inappropriate,It will break consistency:
e.g. y:=ADR(x); r:=r0+y; VS r:=r0 + ADR(x)
1, DevCPL486.CheckMemForm used by Float load or store, the operands it accepted is only integer and real form;
Code: Select all
FILD – Load Integer
16-bit memory 1101 1111 : mod 000 r/m
FILD m16int DF /0 Push m16int onto the FPU register stack.
32-bit memory 1101 1111 : mod 101 r/m
FILD m32int DB /0 Push m32int onto the FPU register stack.
64-bit memory 1101 1011 : mod 000 r/m
FILD m64int DF /5 Push m64int onto the FPU register stack.
FLD – Load Real
32-bit memory 1101 1001 : mod 000 r/m
FLD m32fp D9 /0 Push m32fp onto the FPU register stack.
64-bit memory 1101 1101 : mod 000 r/m
FLD m64fp DD /0 Push m64fp onto the FPU register stack.
80-bit memory 1101 1011 : mod 101 r/m
FLD m80fp DB /5 Push m80fp onto the FPU register stack.
ST(i) 1101 1001 : 11 000 ST(i)
FLD ST(i) D9 C0+i Push ST(i) onto the FPU register stack.
2, Pointer is a unsigned integer actually, e.g.
r := r0 + S.ADR(x); Post should : ASSERT(r >= r0)
this fix output such code:
Code: Select all
8D 45 F8 LEA EAX, [EBP-8]
50 PUSH EAX
DB 04 24 FILD [ESP]
83 C4 04 ADD ESP, 4
if ADR(X) >2G, the resoult will be r< r0;
P.S. because cp language has no unsigned integer, this requirement may be inappropriate,It will break consistency:
e.g. y:=ADR(x); r:=r0+y; VS r:=r0 + ADR(x)
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: issue-#209 Compiler trap in Real64 op ADR(x)
This is a very good argument, luowy. We will have to look into this issue again.
In the next week I am on vacation and will probably not be able to work on this.
But the voting should be suspended, I think.
- Josef
In the next week I am on vacation and will probably not be able to work on this.
But the voting should be suspended, I think.
- Josef
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: issue-#209 Compiler trap in Real64 op ADR(x)
I have looked at this issue again.
My conclusion so far is that the current solution is not as bad as I thought.
@luowy
1. the alternative proposals for the fix are also in the backend, as far as I understand them. So this argument does not really apply.
2. The "signed"-argument does also not really apply either because it is the very nature of CP that it does not have unsigned numeric types.
Introducing the new concept of an "unsigned" address conversion for this very exotic case does not feel right to me.
@all
For checking the abstract syntax tree constructed by the frontend and passed to the backend it would be
good to have a tool that dumps the tree to a window in readable textual form (with enum constants expanded into names).
Otherwise it is very tedious to debug such issues.
Is there any such tool around?
- Josef
My conclusion so far is that the current solution is not as bad as I thought.
@luowy
1. the alternative proposals for the fix are also in the backend, as far as I understand them. So this argument does not really apply.
2. The "signed"-argument does also not really apply either because it is the very nature of CP that it does not have unsigned numeric types.
Introducing the new concept of an "unsigned" address conversion for this very exotic case does not feel right to me.
@all
For checking the abstract syntax tree constructed by the frontend and passed to the backend it would be
good to have a tool that dumps the tree to a window in readable textual form (with enum constants expanded into names).
Otherwise it is very tedious to debug such issues.
Is there any such tool around?
- Josef
Re: issue-#209 Compiler trap in Real64 op ADR(x)
I have no such tool, I used only three papers, copied all enum names with a pencil, and the builtin post debugger(trap window), HALT(100) at the position which I want to inspect!Josef Templ wrote:Is there any such tool around?
sometimes spend only a minute if the bug near the trap, sometimes will need several hours to find the solution if the bug far away from it...
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: issue-#209 Compiler trap in Real64 op ADR(x)
I would like to come back to the other questions resp. comments
@luowy
1. the alternative proposals for the fix are also in the backend, as far as I understand them. So this argument does not really apply.
2. The "signed"-argument does also not really apply either because it is the very nature of CP that it does not have unsigned numeric types.
Introducing the new concept of an "unsigned" address conversion for this very exotic case does not feel right to me.
- Josef
@luowy
1. the alternative proposals for the fix are also in the backend, as far as I understand them. So this argument does not really apply.
2. The "signed"-argument does also not really apply either because it is the very nature of CP that it does not have unsigned numeric types.
Introducing the new concept of an "unsigned" address conversion for this very exotic case does not feel right to me.
- Josef