-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
voc code generation for __SETOF macro. #104
Comments
so in august 30 i spent several hours trying to fix code generation, and generate maybe even two lines instead of one, to fix this issue. whatever i tried, i failed, that's why i created this issue to remember and come back to this problem. but came to say that as a temporary solution, i found out that when voc is built with tcc (by exporting CC=tcc) then tcc is able to compile BIT.Mod |
Regarding this (and similar) lines:
Here SET is cast in LONGINT. We remember that SYSTEM.VAL is a memory operation:
And the contents of the upper 4 bytes will be undefined because it's someone else's memory. So the warning is quite reasonable, because it is a potential source of bugs. So I wouldn't change the compiler, I'd just rewrite the source to get rid of such castings. |
thank you, Oleg! meanwhile i changed DES.Mod a little bit, and was able to compile DES.Mod with BIT.Mod (by using tcc): https://github.com/norayr/des/tree/main |
yes, i was driven by a thought that voc should generate proper C code that can be translated by a C compiler. |
Oleg, thank you, i have changed BIT.Mod to compile with voc which uses gcc. |
Oops. I'm so used to LONGINT 64-bit in Component Pascal, that it confused me. Of course the warning is caused by casting ORD(x) to SET. As we recall, the default size of integer calculations in Oberon-2 is of a 16-bit INTEGER, so the result of ORD(x) is 16-bit, and is cast to a 32-bit SET. In this case, it will be sufficient to add a LONG, i.e.
When risc = TRUE it looks like this in C:
There could be a distortion of the value of x here if it were a negative number. Then when multiplying the sign by the higher digits (using LONG) they could become 0FFFFH, but in this case it does not happen because the result of ORD cannot be negative. Well, the result of the logical operation x & 0FFH (even within 16-bit digit capacity) will not be negative either. So I apologize for some possible misunderstanding. |
this is BIT.Mod from Oberon S3:
voc compiles it to BIT.c:
and when it tries to compile the generated C file:
The text was updated successfully, but these errors were encountered: