aboutsummaryrefslogtreecommitdiff
path: root/notes/numeric_exprs.txt
blob: 8f3d7f993b4469ab56ec323bcb1c923ff3133867 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51

Just like SLUL, infer types of expressions from the target, whenever that is
possible.

    int i = 123
    assert b
    return "abc"

Also, all identifier exprs could have the type inferred from the identifier
declaration. And similarly for fields, function calls, etc.


Arithemtic/Logic Expressions
----------------------------
For arithmetic/logic expressions it gets trickier, since those can:
1) involve different types in different operands and the result
2) some expressions might "temporarily" overflow if computed as the result type

Possible solution with implicit promotion to larger types:
* Promote to int32 if target type is int32 or smaller?
    - But how about floats?
* Promote to float64 if any operand is float
* Promote to int64 otherwise
    - But how about divison, e.g. i=100*(n/m)

Alternative solution:
* Force operands to have the same "major" type? (or some kind of cast)
    - I.e. either all integer, or all float.
* Promote int64 in the abstract machine.
    - Of course, the implementation can use a smaller type if the results
      are the same.
        - But this could make multiplication inefficient.
        - Loading of immediates might also become less efficient.

The compiler can of course optimize this (to use smaller types) if it can
prove that the operation is in range and precision of the smaller type.
(This can also happen if an out-of-range value would cause an error at
a later point in the program. In that case the compiler can perform a range
check first, and then do the operation as the smaller type)


Equality Expressions
--------------------
These can work with mixed signs. In that case, there must be a check for
negative values first.

Mixed-size comparisons can work by promoting to the larger type.

int vs float64 comparisons are tricky, because there are some int64 values
that cannot be represented exactly in a float64 (they get rounded to another
integer value).
# FIXME what to do in that case?