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

[Josef Templ]

Ivan, if you do your 64 bit compiler, you will be able to do a SYSTEM.VAL(LONGINT, integer expression) without any problems
because then an integer register is 64 bits.
Doesn't this show that it is a back-end property?

> We have no much experts in compiler, so I had no choice.
No choice? Except what?
You don't need to be a compiler expert to see that my fix is correct.
This is the nice property that allows me to propose to
add this to a release candidate.

> LuoWy reviewed your solution and reported that it is not sufficient.
Not true. There have not been any reports about problems of my fix.
The error reporting is not part of my fix. Again, my fix only makes the reported error visible
by avoiding a follow-up TRAP.

- Josef

[Ivan Denisov]

Ivan, if you do your 64 bit compiler, you will be able to do a SYSTEM.VAL(LONGINT, integer expression) without any problems
because then an integer register is 64 bits.
Doesn't this show that it is a back-end property?

No, because for INTEGER variable it works without problem. It is just taking some RAM value before variable to fill bytes from 5 to 8.
And also I do not think, that integer register will be 64 bits for 64-bits BlackBox...
Chris provided the link to some interesting notes: http://www.modulaware.com/mdlt/mdlt81.htm

> We have no much experts in compiler, so I had no choice.
No choice? Except what?
You don't need to be a compiler expert to see that my fix is correct.
This is the nice property that allows me to propose to
add this to a release candidate.

I also see that LouWy fix is correct and it gives more information for user.
From the user point of view your fix is worser. So that is the problem.
Now I am not sure that it is correct at all. Because expressions are allowed to be the argument of VAL. So compiler should eat this code and return LONGINT with calculation of result of the expression in first 4 bytes and some "trash" from RAM in other bytes 5-8. That is the correct behavior for VAL.

> LuoWy reviewed your solution and reported that it is not sufficient.
Not true. There have not been any reports about problems of my fix.
The error reporting is not part of my fix. Again, my fix only makes the reported error visible
by avoiding a follow-up TRAP.

I provided the link for this message which I found to be the report. I am providing it again:
http://forum.blackboxframework.org/view ... t=10#p4501
And this is your answer:

The fix of luowy is in the front end.
This is why it is wrong without considering any details...

[Zinn]

Sorry Ivan, I can't understand you. Why do you block Josef’s easy solution.
This solution should be in the final release.
Everything else would delay the final release for another year.
- Helmut

[Josef Templ]

I have improved the error message for SYSTEM.VAL limitations.
It now uses a new error message
261: "unsupported mode or size of second argument of SYSTEM.VAL"

For the diffs see http://redmine.blackboxframework.org/pr ... daa695cd38.
The wording may be improved, of course.
The important feature is the link to the SYSTEM.VAL function in the error message.

An error message now looks like

SYSTEM.VAL.jpg (8.67 KiB) Viewed 8289 times

- Josef

[Josef Templ]

And also I do not think, that integer register will be 64 bits for 64-bits BlackBox...

OK, I don't want to speculate what you are doing in your 64 bit compiler but somebody
might do a 64 bit compiler that uses the X86-64 architecture and according to https://en.wikipedia.org/wiki/X86-64
all general purpose registers are then 64 bits wide.
The details are off-topic. The point is that there may be different architectures indeed and that is why
the CP compiler separates the checks for SYSTEM.VAL into two groups.
Some can be checked in the front-end and some have to be checked in the back-end.
Since this was never a problem it should not be changed now, but I believe I already mentioned this.

Also @luowy: you did not answer my question why the error reporting is so important in the context of this issue
while there are 44 places in the back-end that use the very same error reporting without any discussion.

- Josef

[Ivan Denisov]

The important feature is the link to the SYSTEM.VAL function in the error message.

This message is better than previous.

Everything else would delay the final release for another year.

I agree, that is why I think we should release without this fix at all.

Now it is clear for me that nobody tried LuoWy's fix except me and (maybe) Josef.

Please download this test version with LuoWy fix:
http://blackboxframework.org/unstable/i ... c1.654.zip
Diff:
http://redmine.blackboxframework.org/pr ... 1&type=sbs

And compile this module:

Code: Select all

MODULE  Test;
  IMPORT SYSTEM;
	VAR
	x0: LONGINT; y0: INTEGER;
  x1: BYTE; y1: REAL;
	x2: INTEGER; y2: REAL;
	
BEGIN
x0 := SYSTEM.VAL(LONGINT, y0 * 2);
x1 := SYSTEM.VAL(BYTE, y1 * 2);
x2 := SYSTEM.VAL(INTEGER, y2 * 2);
END  Test.

You will see that it is nice error reporting.

Now read Josef explanation why he do not like this. He claim that bug is dependent on architecture, but I do not think so.
Architecture does not interrupt interpretation of INTEGER as LONGINT. So why it should interrupt interpretation of INTEGER stack as LONGINT ?

There should not be error message at all. It should be compiled code for this. See my explanations above.
We should clearly define the documentation for SYSTEM.VAL first and then return back to the design of the fix.

As a temporary solution we can include both fixes. One with nice error reporting, another with HALT(100) to clear define a problem of the compiler at the current state.

[Zinn]

Everything else would delay the final release for another year.

I agree, that is why I think we should release without this fix at all.

Now it is clear for me that nobody tried LuoWy's fix except me and (maybe) Josef.

Please download this test version with LuoWy fix:
...
You will see that it is nice error reporting.

Now read Josef explanation why he do not like this. He claim that bug is dependent on architecture, but I do not think so.
...

Ivan,
Josef's argument is right. Lowy's correction is at the wrong place. That is the reason why I don't try it.
It is a question of the compiler architecture. The error ocurrs in the backend and not in the frontend. A backend for an other machines as i86 may have not this kind of problem an can execute the statement which the frontend passed. For flexibility in the future there should be no error detection in the frontend about this topic, because the program statement is corrent an may be execute without any problems with another backend.

Please end this discussion and insert Josef's solution to the final release.

- Helmut

[Ivan Denisov]

Why if the "program statement is correct" the back-end compiler should fail?
It is not fails interpreting INTEGER as LONGINT. It just takes the neighboring RAM and put in bytes from 5 to 8. This is very useful in many cases.
It is clear that interpreting INTGER is not so useful... however it is not the reason to fail. There can be zero bytes from 5 to 8 for example.

Even this is possible for current back-end.

Code: Select all

MODULE Test;
IMPORT SYSTEM;
TYPE 
	T = RECORD
		x: BYTE;
	END;
	VAR p: LONGINT; c: T;
BEGIN
	p := SYSTEM.VAL(LONGINT, c);
END Test.

[Zinn]

Why if the "program statement is correct" the back-end compiler should fail?

Because of the complexity. Write
dummy := y0 * 2;
x0 := SYSTEM.VAL(LONGINT, dummy);
and it will work somehow.

But all this discussion doesn't make sense at all, because SYSTEM should not be use in the application program. SYSTEM should used isolate only with great care. The function we speak here about can be programmed easily without SYSTEM.
- Helmut

[Ivan Denisov]

From the complexity point of view we should make not possible to put expressions and functions to the VAL as it is described in P-S-I documentation. There are only few places in BlackBox there this undocumented feature is used. Not hard to repair. It will give benefits in future for communication of front-end and back-end of the compiler.