issue-#126 Compiler TRAP for SYSTEM.VAL(LONGINT, intreg)

[Josef Templ]

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?

[Ivan Denisov]

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.

[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 .

[Ivan Denisov]

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.

[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

[Ivan Denisov]

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 8434 times

[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

[Ivan Denisov]

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

[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

[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;