DIV and MOD not in line with Oberon-07 report about oberon-lang

[zaskar9]

There are several, interrelated issues here, which need careful consideration in order to have implementation of Oberon that supports modern hardware (i.e., 64-bit architectures) but is also backwards-compatible with older compilers and existing source code bases.

1. Compliant implementation of DIV and MOD: This issue is probably the easiest to fix. It should suffice to change Sema and CodeGen to compute the values as defined by Oberon.
2. Implicit promotion/conversion: since Oberon-07 only has one float and one integer type, there is no reason to have implicit promotion and conversion is done explicitly. Other versions of Oberon, however, have more types of the same kind. Therefore, having promotion/conversion should at least be an option, in particular, for literals (as there is no standard way to explicitly distinguish different integer and floating-point literals). Having the option to switch promotion/conversion on and off requires a bit more engineering in Sema.
3. Signed vs. unsigned treatment of integers: Honestly, I find this point a bit cumbersome as there is no explicit way to have an unsigned integer, yet sometimes integers are treated as unsigned.
4. (-5) DIV 3 vs. -5 DIV 3 vs. -(5 DIV 3): This issue worries me since it seems to be in direct contradiction to how the official Oberon-07 grammar structures things in terms of operator precedence. According to the grammar, the first two expressions are equivalent in the sense that they produce the same AST, while the third is different.

As a short-term solution, I propose to fix the implementation of DIV and MOD (Point 1).

Points 2 and 3 are more long-term issues. I think the proper solution would be to rewrite Sema and CodeGen to be fully configurable. On the one hand, it should be possible to define the mapping from Oberon types to (new) internal types that are close to the LLVM type system, e.g., INTEGER maps to something like INT32T. On the other hand, type inclusion and the respective promotion/conversions should be optional. Based on that, there could be compiler switches to determine what the compiler does, e.g., -m32 --std=O07 to get the Oberon-07 type system for a 32-bit architecture, i.e., INTEGER maps to INT32T and LONGINT is an alias for INTEGER. In analogy to the data layout of LLVM, there could even be a parameter that lets developers set their own configuration, e.g., --types=l64i32s16d64f32. There could even be a pragma directive that can be used within a module to compile multiple modules with different assumptions about types.

Point 4 is not something I'm currently planning on supporting as I find it completely unintuitive and contrary to how the grammar is structured. If we cannot rely on the AST as a first indication of what the semantics are, then we're on losing grounds in my opinion.

[zaskar9]

I've updated Sema and CodeGen to compute a proper Euclidean division and modulo operation. In Sema, the following C++ code is used.

int64_t Sema::euclidean_mod(int64_t x, int64_t y) {
    int64_t r = x % y;
    r += y & (-(r < 0));
    return r;
}

int64_t Sema::floor_div(int64_t x, int64_t y) {
    int64_t d = x / y;
    int64_t r = x % y;
    return r ? (d - ((x < 0) ^ (y < 0))) : d;
}

Accordingly, CodeGen generates the following LLVM IR.

; euclidean_mod(x = %0, y = %1)
%3 = srem i64 %0, %1
%4 = icmp slt i64 %3, 0
%5 = select i1 %4, i64 %1, i64 0
%6 = add nsw i64 %5, %3

; floor_div(x = %0, y = %1)
%3 = sdiv i64 %0, %1
%4 = mul i64 %3, %1
%5 = sub i64 %0, %4
%6 = icmp eq i64 %5, 0
%7 = xor i64 %1, %0
%8 = ashr i64 %7, 63
%9 = select i1 %6, i64 0, i64 %8
%10 = add i64 %9, %3

Note that the generated code does not use branches and only one (expensive) integer division per operation.

With these changes, the above module Arithmetic17 produces the expected output.

[tenko]

1. That is excellent. Test is now working.
2. There is the BYTE type which is treated as a subrange of INTEGER.
3. I was thinking that maybe there could be an SYSTEM.UINTEGER type where sign extension is not applied in function calls.
4. Agree.