blob: 4bc3d869bbc1d761b27ccb4c62db3c37f4d69511 (
plain) (
blame)
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
|
+ Build the consteval stuff
OPTIMIZATIONS:
+ Use hashmaps or something similar for lookups for types and calls
LOWERING:
Structure handling in lowering could probably be as follows:
Imagine
struct something {
i27 a;
other_struct b;
};
main ()
{
// something s = {...};
i27 s_def = alloc $STRUCT_SIZE;
// i27 a = s.a;
i27 member_a = struct_def + 0;
i27 a << struct_def 0;
// other_struct c = s.b;
i27 c_def = alloc $OTHER_STRUCT_SIZE;
i27 member_b = struct_def + 3;
c_def blit member_b, $OTHER_STRUCT_SIZE; // has to be added to qbt,
// might need to be handled
// like store with constant as
// 'return'. Or can c_def be
// considered an output value
// for blit?
/* calls just dump all registers down I guess, as do returns. No
* implicit conversion to pointer and passed as first argument, ufcs
* does that for us. */
}
+ Might want to add in some kind of suffix for integer types, s for i9 and l for
i27 or something?
+ lowering could check if a function has been lowered and if not, lower it for
us. Should it also check that no abstract data types are used in the final
lowering? Which would mean that even the lowering is allowed to fail, and not
just the actualization phase.
|
