Page 2 of 7
Re: issue-#126 Compiler TRAP for SYSTEM.VAL(LONGINT, intreg)
Posted: Sat Aug 27, 2016 3:56 pm
by Josef Templ
Ivan Denisov wrote:
I agree with X512. The TRAP should be replaced to warning.
I don't know what you and X512 are talking about.
The TRAP is fixed. Isn't this enough?
Re: issue-#126 Compiler TRAP for SYSTEM.VAL(LONGINT, intreg)
Posted: Sat Aug 27, 2016 4:48 pm
by Ivan Denisov
Josef Templ wrote:Ivan Denisov wrote:
I agree with X512. The TRAP should be replaced to warning.
I don't know what you and X512 are talking about.
The TRAP is fixed. Isn't this enough?
Misunderstanding was because the initial discussion was about low-level memory manipulations:
http://community.blackboxframework.org/ ... t=131#p695
But then you switch to some bug in this topic:
http://community.blackboxframework.org/ ... rt=10#p706
For future is better to make separate topic for such cases, because your post was not related with a first one.
Now I tested your version
http://blackboxframework.org/unstable/i ... c1.646.zip
ans see that everything is reasonable.
Re: issue-#126 Compiler TRAP for SYSTEM.VAL(LONGINT, intreg)
Posted: Sat Aug 27, 2016 11:29 pm
by luowy
IMO,it is not complete.
Josef fixed the bug at the beckend by add a 'RETURN' ,that stop the propagation of the error which causing the trap.
but it can only get the error position of the statement, instead of the error expression.
One of features of Oberon compiler beyond most C compiler is the giving error positions of expression instead of line numbers .
Re: issue-#126 Compiler TRAP for SYSTEM.VAL(LONGINT, intreg)
Posted: Sun Aug 28, 2016 3:11 am
by Ivan Denisov
luowy wrote:IMO,it is not complete.
Josef fixed the bug at the beckend by add a 'RETURN' ,that stop the propagation of the error which causing the trap.
but it can only get the error position of the statement, instead of the error expression.
One of features of Oberon compiler beyond most C compiler is the giving error positions of expression instead of line numbers .
I agree. This is not good now, that the error displayed in the beginning of the line.
Re: issue-#126 Compiler TRAP for SYSTEM.VAL(LONGINT, intreg)
Posted: Sun Aug 28, 2016 7:25 am
by Josef Templ
I did not change anything regarding the error position.
This is the standard error reporting behavior of the code generator.
You can make a proposal for a better error position together with its implementation,
but, please, DON'T COMMIT IT.
In general, I would not invest a lot of time into optimization of an error position
that has not been observed for the last 30 years.
- Josef
Re: issue-#126 Compiler TRAP for SYSTEM.VAL(LONGINT, intreg)
Posted: Sun Aug 28, 2016 8:08 am
by Ivan Denisov
Josef Templ wrote:You can make a proposal for a better error position together with its implementation,
but, please, DON'T COMMIT IT.
Why LuoWy fix is not sufficient for you? You did not provide any arguments when rejecting it.
http://community.blackboxframework.org/ ... rt=10#p710
For me as an user it gives better information about the error.
- luowy_fix.png (8.05 KiB) Viewed 14422 times
Re: issue-#126 Compiler TRAP for SYSTEM.VAL(LONGINT, intreg)
Posted: Sun Aug 28, 2016 9:26 am
by Josef Templ
The fix of luowy is in the front end.
This is why it is wrong without considering any details.
This is a TRAP that appears in the backend, i.e. in the code generator.
That's why it needs to be fixed in the code generator.
The fix is of exceptional simplicity and elegance.
It is sad that you don't recognize the simplicity and elegance of the fix.
The fix does not change anything except that it avoids a follow-up error
after detecting an error because something cannot be re-interpreted.
The fix does not change any feature of the code generator.
Why do you waste our time with searching for an alternative for such
a simple and elegant fix.
- Josef
Re: issue-#126 Compiler TRAP for SYSTEM.VAL(LONGINT, intreg)
Posted: Sun Aug 28, 2016 10:52 am
by Ivan Denisov
Josef Templ wrote:The fix is of exceptional simplicity and elegance.
It is sad that you don't recognize the simplicity and elegance of the fix.
The fix does not change anything except that it avoids a follow-up error
after detecting an error because something cannot be re-interpreted.
It can be elegant from inside, but looks ugly outside. It does not show the place of error.
It is strange and sad that you do not see the ugly side of your fix
Re: issue-#126 Compiler TRAP for SYSTEM.VAL(LONGINT, intreg)
Posted: Mon Aug 29, 2016 4:56 am
by Josef Templ
Ivan, I do see the error position. I am not blind.
But I also see the inner workings of the compiler and code generator.
It is the general principle of the compiler that there is no error position
available in the code generator (back-end) for parts of a statement.
Only the start of a statement is known to the code generator.
This is the same behavior for ALL errors generated by the code generator.
Nobody ever complained about that and it is not a problem in practice.
You are inventing problems that don't exist in practice.
In addition, it cannot be changed easily, as far as I see.
Once again, this behavior has nothing to do with my fix.
It is a global design decision of the compiler.
If there is an error position available for the second argument to SYSTEM.VAL
I would of course use it. But changing the overall compiler design for this
is not justified and out of scope of this issue.
Fixing the error in the front end is not possible because it depends on
the code generator, i.e. the various IA32 addressing modes (Reg, Stk, etc.), which
are not known to the parser (front-end).
- Josef
Re: issue-#126 Compiler TRAP for SYSTEM.VAL(LONGINT, intreg)
Posted: Mon Aug 29, 2016 10:52 am
by Ivan Denisov
Josef, if you see all the picture, please explain why there was no RETURN there before?
It is clear that is was done intentionally.
Otherwise it would be:
Code: Select all
PROCEDURE Convert* (VAR x: DevCPL486.Item; f: BYTE; size: INTEGER; hint, stop: SET); (* size >= 0: sysval *)
VAR y: DevCPL486.Item;
BEGIN
ASSERT(x.mode # Con);
IF (size >= 0)
& ((size # x.typ.size) & ((size > 4) OR (x.typ.size > 4))
OR (f IN {Comp, Real64}) & (x.mode IN {Reg, Stk})
OR (f = Int64) & (x.mode = Stk)) THEN DevCPM.err(220)
ELSE
y.mode := Undef; y.form := f; ConvMove(y, x, size >= 0, hint, stop)
END
END Convert;
Instead of:
Code: Select all
PROCEDURE Convert* (VAR x: DevCPL486.Item; f: BYTE; size: INTEGER; hint, stop: SET); (* size >= 0: sysval *)
VAR y: DevCPL486.Item;
BEGIN
ASSERT(x.mode # Con);
IF (size >= 0)
& ((size # x.typ.size) & ((size > 4) OR (x.typ.size > 4))
OR (f IN {Comp, Real64}) & (x.mode IN {Reg, Stk})
OR (f = Int64) & (x.mode = Stk)) THEN DevCPM.err(220) END;
y.mode := Undef; y.form := f; ConvMove(y, x, size >= 0, hint, stop)
END Convert;